Open GApps builds the installable zips, and the GPLv3 exception decides who owns them

A dash separated target carries platform, API level and variant

The Makefile is the whole interface. A target is a dash separated string, and the file splits it into platform, API level and optional variant before handing those values to scripts/build_gapps.sh. Asking for arm-23 gives the ARM package on that API level, which the project notes as Android 6.0, and adding a third field selects a variant:

make arm-23

make arm-23-stock

The variant vocabulary is fixed in one variable: super, stock, full, mini, micro, nano, pico, aroma, tvstock and tvmini. Each architecture also carries a floor, and a target below it is refused: arm and x86 start at 19, arm64 and x86_64 start at 21. The API list runs 19 through 32, which is where you confirm whether a given Android release is offered at all.

The source tree arrives as submodules measured in gigabytes

A build starts with the repository and its submodules, and the submodule step is the expensive one. The clone uses an SSH URL, which is why the project asks for a GitHub account with SSH authentication configured before you start:

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

After cloning, the source script pulls the original APKs as provided upstream, and the project warns that these repositories are very large, in the order of gigabytes. Two arguments change that cost:

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

--shallow fetches only the latest snapshot of the APKs, leaving their history behind, which cuts both disk use and data transferred. Passing an architecture limits the fetch to arm, arm64, x86 or x86_64, with one caveat spelled out: fallback architectures are fetched too. The same command also updates the sources to their most recent version later.

Build, cache, out and log are four separate roots

The stated prerequisites are short and both concern your machine. The Android build tools must be installed and set up in your PATH, and users on Ubuntu are pointed at a packaged set of build tools maintained outside the project. Nothing else is automated for you: the toolchain is a condition of building, not a step inside it. The layout is equally plain. scripts/ holds the build system, build_gapps.sh is the script the Makefile invokes, and four roots are defined by name: build/, cache/, out/ and log/. The root also holds scripts you will not meet in any tutorial, such as get_speechfiles.sh and show_apksignature.sh.

Source APKs are added one file or a marked beta set

Two scripts handle everything that happens after a build touches the source archive. add_sourceapp.sh puts updated source APKs into it, takes more than one file at a time, and accepts a list of paths that should be marked as beta so a release can ship some packages flagged and others not:

./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 the contributor path, running with no argument to publish for every architecture or with one or more architecture arguments to publish for a subset. report_sources.sh prints the inventory of what is locally available, and its advanced form takes filters and switches in one expression:

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

That covers sdk, architecture lists, hash, size ceilings and floors in megabytes, and toggles for beta packages, help text, leanback and signatures.

Prebuilt package support runs on forums, not the issue tracker

If you use the prebuilt packages rather than building, the repository sets expectations early. The project asks you not to file GitHub issues for problems with those packages: the issue tracker is used only for issues concerning the scripts themselves. Questions go to the wiki FAQ, and if that does not answer them, to an XDA Q&A thread or a Gitter chat, with a separate XDA development thread for reporting bugs in the prebuilt packages. Two artifacts are requested before anyone looks at a problem: the Open GApps installer debug log, and a logcat as well when the symptom is force closures. The repository does not document how to install a zip, so the install question is answered outside the code you cloned.

The zip exception is a compiler analogy with a condition attached

The licensing is built on an analogy the project spells out: Open GApps is to an installable zip what the GNU Compiler Collection is to a compiled program. The project itself is GPLv3 with an addendum called the Open GApps installable zip exception. The zip it produces is an assorted product whose components keep their various licenses, and the installer scripts inside it are still GPLv3. The exception then grants a choice: the author of an installable zip picks the license for that end product themselves, provided any changes to the project used to create it are published under GPLv3 together with the zip. So a fork can ship its own build under its own terms, and what comes back to the project is any change to the scripts, not the package.

Prebuilt packages are personal use only and no tag exists to pin

Two limits are easy to walk into. First, the prebuilt packages from opengapps.org are made available for personal use only and are not allowed to be mirrored to the public by anyone other than opengapps.org, so hosting them elsewhere is outside what the project permits. Second, the repository has no GitHub releases at all, which means there is no tag to pin a build to and no version number to quote when you report a problem. The default branch is master and its last push is dated August 12, 2026, so commit activity is current even though no published artifact is versioned. Two scripts in the root, get_speechfiles.sh and show_apksignature.sh, carry no documented usage on the project page, so their arguments have to be read out of the source before you run them.

Editorial conclusion

Use Open GApps when you need a zip built for a specific architecture and API level, or when you have to add a source APK yourself. Do not use it as a redistribution source for the prebuilt packages, and check the API list in the Makefile before assuming a given Android release is covered.

Frequently asked questions

Official sources

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