Open GApps: building your own Google Apps packages for Android

What Open GApps actually solves, and for whom

The repository is the main source tree of the Open GApps Project. It is not the download page and it is not the flashable zip. It is the set of scripts and make rules that turn original APK sources into an installable Google Apps package. The README is explicit about this split: pre-built packages live at opengapps.org and are hosted on SourceForge, while this repository is for building your own version.

The audience follows from that. If you are flashing a custom ROM and just need Google Apps, the README sends you to the website. If you are maintaining a build, testing a variant, or packaging for an architecture and Android release that the website does not cover, the source tree is the relevant artifact. The README also draws a support boundary: GitHub issues are only for problems with the Open GApps Project scripts themselves, not for problems with the pre-built packages, which belong on the XDA development thread.

How the Makefile turns a platform and API level into a package

The mechanism is visible in the Makefile. It defines APIS as 19 through 32, PLATFORMS as arm, arm64, x86 and x86_64, and VARIANTS as super, stock, full, mini, micro, nano, pico, aroma, tvstock and tvmini. Each platform has a floor: LOWEST_API_arm and LOWEST_API_x86 are 19, while LOWEST_API_arm64 and LOWEST_API_x86_64 are 21.

The make-gapps macro creates one target per platform and API combination, and the target name encodes the parameters separated by hyphens. The rule parses the target name into platform, api and variant, checks the API against the platform floor, and then calls scripts/build_gapps.sh. If you name a variant, it builds that one. If you omit the variant, the rule loops over every entry in VARIANTS and builds each in turn. That is the whole data flow: make target in, build_gapps.sh invocation out, with the minimum API guard preventing combinations the platform does not support.

The build also defines BUILDDIR, CACHEDIR, OUTDIR and LOGDIR under the top directory, so outputs and logs are separated from the sources. The Makefile header carries the GPLv3 notice and the standard warranty disclaimer.

Installing the sources and running a first build

The README assumes a GitHub account with SSH authentication configured, because the clone command uses the SSH URL rather than HTTPS. To initialize the source tree, clone the main repository.

git clone [email protected]:opengapps/opengapps.git

Then fetch the APK sources. The README warns that these repositories are very large, in the order of GiBs, so this step is the expensive one. The script takes an optional --shallow flag and an optional architecture argument.

./download_sources.sh [--shallow] [arch]

The README states that --shallow fetches only the latest snapshot of the APKs, avoiding their history, which reduces both disk use and transferred data. The arch argument accepts arm, arm64, x86 or x86_64 and limits the fetch to that architecture, though fallback architectures are fetched too. The same command updates existing sources to their most recent version later.

Before building, the Android build tools must be installed and present in $PATH. The README points Ubuntu users to @mfonville's Android build tools page. With that in place, a full build across all platforms and Android releases is just make. To build one combination, put the platform and API level together with a hyphen, and optionally a variant after another hyphen.

make arm-23
make arm-23-stock

The first command builds every variant for ARM on API 23; the second builds only the stock variant. If the API is below the platform floor, the Makefile guard rejects the combination rather than attempting a build.

Managing sources, uploading them and reporting what you have

Three helper scripts cover the day-to-day work around the source archive. add_sourceapp.sh adds updated APKs, accepts more than one file at once, and has a beta marker so specific apps can be flagged as beta.

./add_sourceapp.sh [/path/to/the/files/you/want/to/add.apk]* [beta] [/apps/that/should/be/marked/as/beta.apk...]*

upload_sources.sh is for contributors and uploads updated sources. Called without arguments it covers every architecture; with arguments it uploads a subset.

./upload_sources.sh [archs]*

report_sources.sh gives an overview of the locally available sources, and the README shows it accepts extra arguments for more advanced queries. The documented grammar includes sdk, archs, arch-sdk, hash, max*mb, min*mb, nobeta, nohelp, noleanback and nosig.

./report_sources.sh ( ([sdk] [archs]*) || [arch-sdk] ) && [hash] || [max*mb] || [min*mb] || [nobeta] || [nohelp] || [noleanback] || [nosig]

That grammar is dense and the README does not walk through worked examples for each flag, so expect to read the script itself before relying on the filters. There is also get_speechfiles.sh and show_apksignature.sh at the top level, plus a HOWTO-get-repo-history.txt file, but the README does not describe what any of them do.

Where Open GApps is the wrong tool

The clearest limitation is scope. The README states plainly that problems with the pre-built packages should not be filed as GitHub issues here. If your zip came from opengapps.org, this repository's issue tracker is not the place for it, and the source tree will not help you debug a flash failure on a device.

The second limitation is cost. Downloading the APK sources is measured in gigabytes, and the README only offers --shallow and the architecture argument as mitigations. On a slow link or a small disk, the source path is impractical compared with downloading a pre-built zip.

The third is the API ceiling. The Makefile lists APIS up to 32, which corresponds to Android 12L, and PLATFORMS covers four architectures. Nothing in the README claims coverage beyond that list, and the Makefile guard will reject an API below the platform floor. If you need a package for a release outside those numbers, the repository as given does not provide it. Finally, the README does not document rollback or uninstall behaviour for a built zip, so recovery from a bad flash is not something the README answers.

How it differs from other Google Apps providers

MindTheGapps, NikGapps and BiTGApps are named in search queries alongside Open GApps, but the README only describes Open GApps itself, so a feature-by-feature comparison would be invention. What can be compared is the delivery model visible in this repository.

Open GApps ships a build system. You clone a source tree, pull APK sources with download_sources.sh, and run make against a platform and API target. The output is a zip you produced, and the repository exposes source management scripts (add_sourceapp.sh, upload_sources.sh, report_sources.sh) for people who maintain that archive. The pre-built path is separate: it lives at opengapps.org and on SourceForge.

That is a different shape from a project that only publishes ready-made zips. The trade-off is control against effort. Building gives you a specific architecture, API level and variant combination, at the cost of a multi-gigabyte source fetch and a working Android build toolchain. If neither of those costs is acceptable, the pre-built route is the one the README recommends anyway.

Licence terms and what they mean for a zip you build

The README describes the licence as GPLv3 with an addendum called the Open GApps installable zip exception, and compares the arrangement to the GNU Compiler Collection. The project itself is the compiler and is GPLv3. The installable zip is an assorted product whose components keep their own licences; the installer scripts inside it remain GPLv3.

The practical consequence stated in the README is that the author of an installable zip can choose the licence for that end product, provided that any changes made to the version of the Open GApps Project used to create the zip are published under GPLv3 alongside the zip. The individual components keep their respective terms regardless.

There is a separate rule for the pre-built packages. The README says they are made available for personal use only and are not allowed to be mirrored publicly anywhere other than OpenGApps.org. That restriction applies to the pre-built zips, not to the build scripts. This is a summary of what the README states, not legal advice; the LICENSE file and the addendum are the authoritative text.

Editorial conclusion

Adopt Open GApps if you need a self-built Google Apps zip for a specific architecture and API level, and you accept that download_sources.sh pulls gigabytes of APK history. Do not adopt it if you only want to flash a ready-made package: the README points you to opengapps.org, where the pre-built zips are hosted on SourceForge. Before building, check that your platform and API combination is covered by the Makefile's APIS and PLATFORMS lists and that Android build tools are in your $PATH.

Frequently asked questions

Official sources

1. Issues
2. opengapps/opengapps on GitHub
3. Project website
4. README