[GAPPS][DAILY] Open GApps for Android; All Android Versions & Devices

Search This thread

MastahF

Inactive Recognized Developer
Feb 10, 2015
811
2,345
The Hague
github.com
Xiaomi Mi 11
Questions? Use Q&A!
Please read the FAQ before reporting any bugs or errors!
If you post in the main thread not having read the FAQ or error message itself, not included a debug log when reporting a malfuction or reporting a Force Closure without a logcat, your post will be ignored by the developers!
Not because we are evil, but because the same questions keep popping up over and over again and too often we get a "X doesn't work, plz fix" without any clue what is happening. We don't have telepathic connection to your device and all the time unnecessarily wasted on this can't be spend on development of Open GApps itself.

The Latest builds of Open GApps for Android can easily be downloaded from the:


I work on this project for FREE and putting in a lot of hours into it. While not mandatory, donations encourage me to continue to further pursue this project and I'd deeply appreciate them, if you feel generous.
Donate to The Open GApps Project


Are you a ROM developer and want to hotlink to the latest Open GApps package? Then check this wiki entry for details.
Please don't publicly mirror the prebuilt packages without explicit consent of @MastahF, to ensure that users will always be directed to the very latest version and the source code of the project.


About The Open GApps Project
Open GApps is a Google Apps package completely developed by writing buildscripts which allow for the automated creation of new up-to-date packages automatically.
The development process is completely open-source (GPLv3) and the goal is to have multiple contributors involved, to secure and reinforce the sustainability of Open GApps development.
Builds are generated every (European) night automatically (if there are any changes) and uploaded to GitHub.

Official AROMA Open GApps package is developed in collaboration with long-time LP-AROMA-developer @raulx222 and has a dedicated XDA thread
For any questions about the AROMA installer development, please refer to that thread. Of course, general support questions can also be asked in our own Q&A thread.

Official Open GApps For Stock support is developed in collaboration with @Rapper_skull and has a dedicated XDA thread
For any questions about the GApps for Stock development, please refer to that thread. Of course, general support questions can also be asked in our own Q&A thread.

The x86 package branch of the package is focused on Zenfone support and is maintained by @deadman96385 of the famous Zenfone GApps packages and has its own topic for x86 related questions

For those that cook their own ROM, an AOSP-build mechanism for Open GApps has been developed by @blystad and can be found at GitHub, remember that you should not bundle any pre-packaged Google Apps with any ROMs you want to distribute further though.

To gather all the various APKs that are necessary for the packages our master of the APK Universe @MNBooZe has written a tool called APKCrawler that scrape these from the internet, e.g. from APKMirror, it can be found at GitHub too.

Characteristic of Open GApps:

  • Some highlights about the characteristics of the Open GApps packages:
  • All platforms and and all Android versions are supported
  • DPI-optimized support for all Google packages (unlike other GApps)
  • Frequently updated Google Apps: The pre-built OpenGApps.org packages are updated every (European) night (if there are any updated Google Apps available)
  • Strong compression, allowing for relatively small downloads of even the most complete packages
  • Automatic backup: It is not necessary to re-flash Google Apps when you flash a ROM update. Most ROMs support this (addon.d) function
  • The installer checks your device’s capabilities, like the system partition size. It will notify you, before making any changes, if it finds any problems
  • Several package variations, from a Google Super Package (includes all applications that ever shipped on a Google device), to a Stock package that equals the set of applications found on the most current and complete Nexus, to smaller, minimalist packages and an AROMA package that allows graphically selection of what to install
  • A special ‘for Stock ROM’ installation mode that allows to update the Google Apps on Stock ROMs that conform to the original Google Nexus filesystem structure
  • All package installations can be customized to your individual preferences using our Advanced Features and Options

The idea behind this project:
I believe a big source of the problem for many GApps packages to stay up-to-date (or not be forfeited) is the lack of time for developers to do labour-intensive repetive every time a new google-app apk is released.
That is why I have taken it upto myself to write some Linux shell scripts to automate the packaging and to share these efforts with the world with the goal to create a team to continue this package together under the name Open GApps.


This project should not be managed by a person, but by a team, so volunteers willing to help are more than welcome!

Open GApps installer uses open source third-party tools, like busybox and xzdec, compiled by @YashdSaraf; See his busybox thread for more info.
Open GApps is originally based on the now discontinued PA GApps package of @TKruzze and @osm0sis
 

Attachments

  • open.png
    open.png
    74 KB · Views: 261,628
  • banner.jpg
    banner.jpg
    75.8 KB · Views: 60,281
  • roundedbanner.png
    roundedbanner.png
    240 KB · Views: 720,849
Last edited:

Rapper_skull

Senior Member
Apr 21, 2011
282
161
Naples
Hi, @provolinoo suggested me to take a look at this topic.
I made my own GApps, derived from PA GApps by TKruzze and without knowing I solved some problems that the people that were trying to continue the PA GApps are having.
I completely removed the sizes.prop file and now I measure the sizes of the apps on the fly using unzip. I took a look at your scripts and they're really useful, and reminded me that the APKs need to be zipaligned, which I forgot.
Maybe we can join your scripts, my changes, and a fast internet connection to bring PA GApps back to life.
If you're interested here's the link to my topic, please take a look at it: http://forum.xda-developers.com/android/general/alpha-gapps-stock-t3093389
 
Last edited:

hellowasif

Senior Member
Nov 18, 2011
115
834
Lahore
plus.google.com
Well i wanted to say thankyou so much for such wonderful work you did, Before this i was maintaining the PA-Gapps Packages PA Gapps 4.4.4 and PA-Gapps 5.X everything was going great and i must say i learned a lot by maintaining these Gapps packages and that was very wonderful experience but i was only updating Gapps and Libs, But than i realized that they weren't as perfect as the original gapps packages because the original Gapps package uses two important files which were size and libs list which the packages uses and they were the most important part of PA-Gapps. I tried to update these two files manually but they were two time consuming so i decided to drop this project due to lack of resources but by these scripts it will very easy to create Gapps Packages so i wanted to say thankyou again
 

MastahF

Inactive Recognized Developer
Feb 10, 2015
811
2,345
The Hague
github.com
Xiaomi Mi 11
Hi, @provolinoo suggested me to take a look at this topic.
I made my own GApps, derived from PA GApps by TKruzze and without knowing I solved some problems that the people that were trying to continue the PA GApps are having.
I completely removed the sizes.prop file and now I measure the sizes of the apps on the fly using unzip. I took a look at your scripts and they're really useful, and reminded me that the APKs need to be zipaligned, which I forgot.
Maybe we can join your scripts, my changes, and a fast internet connection to bring PA GApps back to life.
If you're interested here's the link to my topic, please take a look at it: http://forum.xda-developers.com/android/general/alpha-gapps-stock-t3093389

Hey, I looked at your work. Some things are indeed good improvements and I will try to incorporate them into my work if you don't mind.
I also looked at your sizes.prop solution, but honestly I don't like it that much, because although the calculation will be very exact, I don't think it is a good idea to unzip large files and pipe all this data through on our small little phones ;). I prefer to keep the sizes.prop estimations on the generating-side rather than on the execution-side.

I really would like you to be involved in the project, somebody else also already PMed on the forum, wanting to be involved. I described which tasks and roles are very welcome to be fulfilled within a joint team effort.
 

Rapper_skull

Senior Member
Apr 21, 2011
282
161
Naples
Hey, I looked at your work. Some things are indeed good improvements and I will try to incorporate them into my work if you don't mind.
I also looked at your sizes.prop solution, but honestly I don't like it that much, because although the calculation will be very exact, I don't think it is a good idea to unzip large files and pipe all this data through on our small little phones ;). I prefer to keep the sizes.prop estimations on the generating-side rather than on the execution-side.

I really would like you to be involved in the project, somebody else also already PMed on the forum, wanting to be involved. I described which tasks and roles are very welcome to be fulfilled within a joint team effort.
Thank you for your appreciation. The files however are not extracted but I used "unzip -l" that lists the content of the archive with the file sizes. Keep me informed about this project.
 

MastahF

Inactive Recognized Developer
Feb 10, 2015
811
2,345
The Hague
github.com
Xiaomi Mi 11
Well i wanted to say thankyou so much for such wonderful work you did, Before this i was maintaining the PA-Gapps Packages PA Gapps 4.4.4 and PA-Gapps 5.X everything was going great and i must say i learned a lot by maintaining these Gapps packages and that was very wonderful experience but i was only updating Gapps and Libs, But than i realized that they weren't as perfect as the original gapps packages because the original Gapps package uses two important files which were size and libs list which the packages uses and they were the most important part of PA-Gapps. I tried to update these two files manually but they were two time consuming so i decided to drop this project due to lack of resources but by these scripts it will very easy to create Gapps Packages so i wanted to say thankyou again

Hi hellowasif,

would you be interested in collaborating then together with other people in a team to bring back PA Gapps using these scripts?
 

MastahF

Inactive Recognized Developer
Feb 10, 2015
811
2,345
The Hague
github.com
Xiaomi Mi 11
Thank you for your appreciation. The files however are not extracted but I used "unzip -l" that lists the content of the archive with the file sizes. Keep me informed about this project.

Ah, then i misread your code, I will take a look at it then again. Anyhow, since the files in the package are static, I think at moment of generation is a good moment to get the file sizes ;)

I have btw a question for you, a problem I was not able to resolve myself yet, even though trying a lot.
When creating the .zip-package to be signed and afterwards flashed, I am at the moment not using any compression (but use the -Z store flag).
If I use *any* kind of compression, the package refuses to flash at my phone (GT-i9300) with the message error executing update binary error.
I tried a lot of combinations, like using a different zip-application, compressing only the files outside META-INF etcetera, but nothing seems to work.
So my question is: how do you generate and sign your zip file? On which platform? With which application? With which parameters?
 

Rapper_skull

Senior Member
Apr 21, 2011
282
161
Naples
Ah, then i misread your code, I will take a look at it then again. Anyhow, since the files in the package are static, I think at moment of generation is a good moment to get the file sizes ;)

I have btw a question for you, a problem I was not able to resolve myself yet, even though trying a lot.
When creating the .zip-package to be signed and afterwards flashed, I am at the moment not using any compression (but use the -Z store flag).
If I use *any* kind of compression, the package refuses to flash at my phone (GT-i9300) with the message error executing update binary error.
I tried a lot of combinations, like using a different zip-application, compressing only the files outside META-INF etcetera, but nothing seems to work.
So my question is: how do you generate and sign your zip file? On which platform? With which application? With which parameters?
You will maybe laugh at my reply, but I simply use WinRAR, on Windows, with maximum compression. I do not yet sign the ZIPs because I wanted to generate my own private key instead of using the generic test-key. What you can try to do is update your recovery (if it's not updated) to see if the problem is solved.
 
  • Like
Reactions: jameskim13

DJAlik

Member
Sep 27, 2007
46
5
Minneapolis
dowloaded your GitHub project and ran through the scripts to create the signed zip file. So far everything is running smoothly. Did a full wipe. Great Job!

Question I have. Do you know why the com.android.vending is still installed in the user space (/data/app) vs system space?
 
  • Like
Reactions: duanwu and sajju73

MastahF

Inactive Recognized Developer
Feb 10, 2015
811
2,345
The Hague
github.com
Xiaomi Mi 11
dowloaded your GitHub project and ran through the scripts to create the signed zip file. So far everything is running smoothly. Did a full wipe. Great Job!

Question I have. Do you know why the com.android.vending is still installed in the user space (/data/app) vs system space?

Thank you for your feedback, at the moment I was extracting the Play Store from a Nexus Image under the cryptic name of Phonesky.
I only found out just now that this Phonesky is the same as android.vending (the Play store) and updated this.

Chrome doesn't seem to be working. It crashes every time I try to run it.

Also thank you for your feedback. Using your feedback I discovered some nasty typos in my script which were breaking Chrome and Talkback.
I fixed those and will be uploading a new package later today. The fixes are already on github.
 

MastahF

Inactive Recognized Developer
Feb 10, 2015
811
2,345
The Hague
github.com
Xiaomi Mi 11
Yes that will be wonderful to work as a team and you count me in. :highfive:

Nice :)
Very happy to hear that! Tomorrow I will be heading for an island for a week, for holidays, so lucky for me, but unlucky for those interested in updates :).
After that holiday I will set-up the basic infrastructure for the team.

I also thought about how to make packages for older android versions and I came up with the following solution that I will be then implementing next week:

*Within the SourceAPKs folder we will put some meta-data or an overlay that specifies the minimal SDK/API version that the package requires
*I will update the scripts in such a way that you can target various android versions, including such a sdk/api version.
*When building for a target, the highest version of the APK that still support that sdk/api version will be selected
*A seperate output directory will be created for each target
*All scripts will be executed from a single Makefile

E.g., the directory structure will look like:
SourceAPKs/18/com.google.android.apps.maps-9.8.1-908101124-minAPI18.apk
SourceAPKs/14/com.google.android.apps.books-3.3.41-30341-minAPI14.apk
Scripts/extract_sources.sh
Output/4.4/pa_unsigned.zip
Output/5.0/pa_unsigned.zip
Output/pa_gapps-4.4-20150504.zip
Output/pa_gapps-5.0-20150504.zip
Makefile

If anybody has any feedback on these ideas, you are welcome! :)
 

Rapper_skull

Senior Member
Apr 21, 2011
282
161
Naples
Nice :)
Very happy to hear that! Tomorrow I will be heading for an island for a week, for holidays, so lucky for me, but unlucky for those interested in updates :).
After that holiday I will set-up the basic infrastructure for the team.

I also thought about how to make packages for older android versions and I came up with the following solution that I will be then implementing next week:

*Within the SourceAPKs folder we will put some meta-data or an overlay that specifies the minimal SDK/API version that the package requires
*I will update the scripts in such a way that you can target various android versions, including such a sdk/api version.
*When building for a target, the highest version of the APK that still support that sdk/api version will be selected
*A seperate output directory will be created for each target
*All scripts will be executed from a single Makefile

E.g., the directory structure will look like:
SourceAPKs/18/com.google.android.apps.maps-9.8.1-908101124-minAPI18.apk
SourceAPKs/14/com.google.android.apps.books-3.3.41-30341-minAPI14.apk
Scripts/extract_sources.sh
Output/4.4/pa_unsigned.zip
Output/5.0/pa_unsigned.zip
Output/pa_gapps-4.4-20150504.zip
Output/pa_gapps-5.0-20150504.zip
Makefile

If anybody has any feedback on these ideas, you are welcome! :)
The idea of automating all the process is certainly good, but we have to keep in mind that things changes really fast. For example in an update Google can add a library to an application that previously didn't have one. We have to check if there's a lib folder inside the APK instead of assuming that all the APKs that now don't have libs will never have them. Also the idea of various app versions is very good, but also error prone. Maybe we can just put all the APKs in one folder and use the filename to determinate the app name and the minAPI (if we don't want to make a step further and read directly from the AndroidManifest.xml, using aapt).
 

DJAlik

Member
Sep 27, 2007
46
5
Minneapolis
Thank you for your feedback, at the moment I was extracting the Play Store from a Nexus Image under the cryptic name of Phonesky.
I only found out just now that this Phonesky is the same as android.vending (the Play store) and updated this.



Also thank you for your feedback. Using your feedback I discovered some nasty typos in my script which were breaking Chrome and Talkback.
I fixed those and will be uploading a new package later today. The fixes are already on github.

latest commit:

$ sh make_package.sh
rm: missing operand
 

MastahF

Inactive Recognized Developer
Feb 10, 2015
811
2,345
The Hague
github.com
Xiaomi Mi 11
The idea of automating all the process is certainly good, but we have to keep in mind that things changes really fast. For example in an update Google can add a library to an application that previously didn't have one. We have to check if there's a lib folder inside the APK instead of assuming that all the APKs that now don't have libs will never have them. Also the idea of various app versions is very good, but also error prone. Maybe we can just put all the APKs in one folder and use the filename to determinate the app name and the minAPI (if we don't want to make a step further and read directly from the AndroidManifest.xml, using aapt).

Very good comments. I have been looking into the possibility of using aapt. With 'aapt d badging file.apk' I will be able to retrieve the API information and app/packagename from any apk.
Using this information I could make an add-script or an 'add-directory' that would scan any new apks and archives them automatically in a storage. This could help to maintain overview, and to automatically discard older versions of the app if the api-level is not changed. It could also allow for adminstation of x86 and arm64 packages in the tree.
So a 'storage' filetree could become in that case like:
/arm/packagename/api14/maps2.apk
/x86/packagename/api11/maps1.apk
/x86/packagename/api14/maps2.apk

My goal is also to indeed in the future to (more) automatically process the existence of a 'lib' and automatically incorporate into the output process. For this I will have (as within my goals set out for next week) to upgrade the process of generating the output folder. Because at this very moment the scripts still assume availability of (most of the) outputfolders to be there already.
 

Rapper_skull

Senior Member
Apr 21, 2011
282
161
Naples
Very good comments. I have been looking into the possibility of using aapt. With 'aapt d badging file.apk' I will be able to retrieve the API information and app/packagename from any apk.
Using this information I could make an add-script or an 'add-directory' that would scan any new apks and archives them automatically in a storage. This could help to maintain overview, and to automatically discard older versions of the app if the api-level is not changed. It could also allow for adminstation of x86 and arm64 packages in the tree.
So a 'storage' filetree could become in that case like:
/arm/packagename/api14/maps2.apk
/x86/packagename/api11/maps1.apk
/x86/packagename/api14/maps2.apk

My goal is also to indeed in the future to (more) automatically process the existence of a 'lib' and automatically incorporate into the output process. For this I will have (as within my goals set out for next week) to upgrade the process of generating the output folder. Because at this very moment the scripts still assume availability of (most of the) outputfolders to be there already.
Exactly, in this way it would be possible to easily maintain arm64 and x86 packages too. The scripting is not complicated, it just requires some time. If you want I can contribute too (I had some experience with shell scripting). If the final scripts are not too long or complicated we can plan a Windows port too, if some future team member is not used to Linux.
We can also try to contact AP to request an RSS feed for new APKs on APKMirror.

EDIT: It seems that adding /feed to any URL will give you the corresponding RSS feed. Good to know.
 
Last edited:

DJAlik

Member
Sep 27, 2007
46
5
Minneapolis
Exactly, in this way it would be possible to easily maintain arm64 and x86 packages too. The scripting is not complicated, it just requires some time. If you want I can contribute too (I had some experience with shell scripting). If the final scripts are not too long or complicated we can plan a Windows port too, if some future team member is not used to Linux.
We can also try to contact AP to request an RSS feed for new APKs on APKMirror.

I've been using Cygwin on Windows and the scripts work great.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 4
    Thanks for this new build and the ongoing effort to bring OpenGApps to R!

    I'm using the stock build with LineageOS 18.1 and things are working nicely so far. To be honest, I don't have a car to test Android Auto, atm. However, the stub behaved as supposed - as soon as I tried to use AA settings etc., I was sent to Play Store to update the app, and as soon as it was updated, the functionality was there.

    One thing only: I believe I might have found a glitch in the installation logic for the Android Auto Stub. Wondering why the stub wasn't installed even though I excluded the "full" Android Auto in gapps-config, I realized that the string "androidautostub" contains "androidauto". So, the logic in the installer script

    Bash:
    # If we're installing androidauto AND androidautostub we MUST REMOVE androidautostub from $gapps_list (since it's not required)
    if ( contains "$gapps_list" "androidautostub" ) && ( contains "$gapps_list" "androidauto" ); then
      gapps_list=${gapps_list/androidautostub}
    fi

    that tries to exclude that both the full app and the stub are installed at the same time, _always_ excludes the androidautostub package from gapps_list , because it _always_ finds the string "androidauto" within "androidautostub".

    When I renamed the stub package to "androidautstub" to avoid "androidauto" within this string, the installer behaved as supposed and installed the stub when the full androidauto package was excluded.

    (My first idea would have been to rename the "androidauto" package to "androidautofull", so that a more specific check for this full package becomes possible, but then I realized that this would break backward compatibility with every existing gapps-config that tries to either in- or exclude androidauto...)

    Thanks, that's a great insight and an error on my end.

    I've renamed androidautostub to gearheadstub, thus we wouldn't have any collisions anymore (gearhead is just another name for Android Auto, so for now this seems fitting).

    I'm rebuilding the packages ATM, so a new test build is coming soon.
    2
    Anyone know the protocol for updating from the test version of Android 11 GApps to the official release when that finally gets added? Would this require re-flashing your current ROM or wiping data? Or should you just be able to adb sideload on top of your current working ROM and GApps?
    Just sideload the Gapps should be enough.
    2
    Hi everyone.

    As mentioned, I've made a new quick test build for ARM64 only, nano and stock packages.

    I *hope* that Android Auto is fixed by the inclusion of the stub APK, which is now present in nano+ packages. Installer script should ignore it if the normal Android Auto APK is present in the package instead.

    Also this build should have proper webview - trichrome - chrome packages, so hopefully this will work as well.

    I'll test it myself later but would love someone to check.

    https://sourceforge.net/projects/opengapps/files/arm64/test/20210513/ here's the link, please report any issues you've found.
    Thanks for this new build and the ongoing effort to bring OpenGApps to R!

    I'm using the stock build with LineageOS 18.1 and things are working nicely so far. To be honest, I don't have a car to test Android Auto, atm. However, the stub behaved as supposed - as soon as I tried to use AA settings etc., I was sent to Play Store to update the app, and as soon as it was updated, the functionality was there.

    One thing only: I believe I might have found a glitch in the installation logic for the Android Auto Stub. Wondering why the stub wasn't installed even though I excluded the "full" Android Auto in gapps-config, I realized that the string "androidautostub" contains "androidauto". So, the logic in the installer script

    Bash:
    # If we're installing androidauto AND androidautostub we MUST REMOVE androidautostub from $gapps_list (since it's not required)
    if ( contains "$gapps_list" "androidautostub" ) && ( contains "$gapps_list" "androidauto" ); then
      gapps_list=${gapps_list/androidautostub}
    fi

    that tries to exclude that both the full app and the stub are installed at the same time, _always_ excludes the androidautostub package from gapps_list , because it _always_ finds the string "androidauto" within "androidautostub".

    When I renamed the stub package to "androidautstub" to avoid "androidauto" within this string, the installer behaved as supposed and installed the stub when the full androidauto package was excluded.

    (My first idea would have been to rename the "androidauto" package to "androidautofull", so that a more specific check for this full package becomes possible, but then I realized that this would break backward compatibility with every existing gapps-config that tries to either in- or exclude androidauto...)
    2
    Hi,

    Thanks for the work ! Do you have an idea when the "arm" version could be out ?

    Thk.
    Stop asking about an ETA for a release in general. It will be released when it's ready to be released.
    1
    Will the next OGApps test builds for A11 include again all packages like the ones released in january? 🤔
    That would be great. ✌️
  • 829
    Questions? Use Q&A!
    Please read the FAQ before reporting any bugs or errors!
    If you post in the main thread not having read the FAQ or error message itself, not included a debug log when reporting a malfuction or reporting a Force Closure without a logcat, your post will be ignored by the developers!
    Not because we are evil, but because the same questions keep popping up over and over again and too often we get a "X doesn't work, plz fix" without any clue what is happening. We don't have telepathic connection to your device and all the time unnecessarily wasted on this can't be spend on development of Open GApps itself.

    The Latest builds of Open GApps for Android can easily be downloaded from the:


    I work on this project for FREE and putting in a lot of hours into it. While not mandatory, donations encourage me to continue to further pursue this project and I'd deeply appreciate them, if you feel generous.
    Donate to The Open GApps Project


    Are you a ROM developer and want to hotlink to the latest Open GApps package? Then check this wiki entry for details.
    Please don't publicly mirror the prebuilt packages without explicit consent of @MastahF, to ensure that users will always be directed to the very latest version and the source code of the project.


    About The Open GApps Project
    Open GApps is a Google Apps package completely developed by writing buildscripts which allow for the automated creation of new up-to-date packages automatically.
    The development process is completely open-source (GPLv3) and the goal is to have multiple contributors involved, to secure and reinforce the sustainability of Open GApps development.
    Builds are generated every (European) night automatically (if there are any changes) and uploaded to GitHub.

    Official AROMA Open GApps package is developed in collaboration with long-time LP-AROMA-developer @raulx222 and has a dedicated XDA thread
    For any questions about the AROMA installer development, please refer to that thread. Of course, general support questions can also be asked in our own Q&A thread.

    Official Open GApps For Stock support is developed in collaboration with @Rapper_skull and has a dedicated XDA thread
    For any questions about the GApps for Stock development, please refer to that thread. Of course, general support questions can also be asked in our own Q&A thread.

    The x86 package branch of the package is focused on Zenfone support and is maintained by @deadman96385 of the famous Zenfone GApps packages and has its own topic for x86 related questions

    For those that cook their own ROM, an AOSP-build mechanism for Open GApps has been developed by @blystad and can be found at GitHub, remember that you should not bundle any pre-packaged Google Apps with any ROMs you want to distribute further though.

    To gather all the various APKs that are necessary for the packages our master of the APK Universe @MNBooZe has written a tool called APKCrawler that scrape these from the internet, e.g. from APKMirror, it can be found at GitHub too.

    Characteristic of Open GApps:

    • Some highlights about the characteristics of the Open GApps packages:
    • All platforms and and all Android versions are supported
    • DPI-optimized support for all Google packages (unlike other GApps)
    • Frequently updated Google Apps: The pre-built OpenGApps.org packages are updated every (European) night (if there are any updated Google Apps available)
    • Strong compression, allowing for relatively small downloads of even the most complete packages
    • Automatic backup: It is not necessary to re-flash Google Apps when you flash a ROM update. Most ROMs support this (addon.d) function
    • The installer checks your device’s capabilities, like the system partition size. It will notify you, before making any changes, if it finds any problems
    • Several package variations, from a Google Super Package (includes all applications that ever shipped on a Google device), to a Stock package that equals the set of applications found on the most current and complete Nexus, to smaller, minimalist packages and an AROMA package that allows graphically selection of what to install
    • A special ‘for Stock ROM’ installation mode that allows to update the Google Apps on Stock ROMs that conform to the original Google Nexus filesystem structure
    • All package installations can be customized to your individual preferences using our Advanced Features and Options

    The idea behind this project:
    I believe a big source of the problem for many GApps packages to stay up-to-date (or not be forfeited) is the lack of time for developers to do labour-intensive repetive every time a new google-app apk is released.
    That is why I have taken it upto myself to write some Linux shell scripts to automate the packaging and to share these efforts with the world with the goal to create a team to continue this package together under the name Open GApps.


    This project should not be managed by a person, but by a team, so volunteers willing to help are more than welcome!

    Open GApps installer uses open source third-party tools, like busybox and xzdec, compiled by @YashdSaraf; See his busybox thread for more info.
    Open GApps is originally based on the now discontinued PA GApps package of @TKruzze and @osm0sis
    25
    Tomorrow there will be 7.0 builds
    Small update concerning Nougat: everything is almost in place, only HotWord Enrollment is not de-odexable yet.
    So tomorrow there will be 7.0 builds, ready for when the first source and custom ROMs will drop.
    Of course beta-quality because they cannot be tested yet, so be careful.
    There are some minor changes, Google changed their keyboard stuff, so there will be no swypelibs possible anymore.
    Google VR Services is backported to all Android versions (so all the way from 4.4 to 6.0) but ofc not yet known how well it will work.
    Also there are some new 7.0 core apps for Google's Shared Android Services (com.google.android.ext.shared; com.google.android.ext.services)
    Trusted Face's unlock has also some major changes, it seems the pittpatt suff is not necessary anymore for 7.0.

    That's it for now
    25
    For those who hadn't spotted it yet: we can celebrate 1 year of Open GApps :)
    http://opengapps.org/blog/post/2016/05/09/open-gapps-first-anniversary/
    23
    Sorry to drop in but needed to clean up some unnecessary posts that were burying more legitimate posts to the thread.

    Going into someone's thread and demanding they make you something is not only just plain rude, it goes against everything XDA is about. Numerous people suggested a way for you to remove the gapps and you chose to ignore them. The dev isn't going to make an uninstaller just for you. You could also always use root explorer and remove the apps that way too. Anywho, there won't be an uninstaller made so no need to continue this conversation.

    Thread Cleaned
    23
    A very small update on the latest Open GApps development focus: Recently most effort went to the APKCrawler project.
    We wanted to mature our playstorecrawler scripts and with the help of @therealssj, who is expert on the Play Store protocol, we were able to make a fully functional crawler for the Play Store (next to our regular crawling of websites like apkmirror). That means we (read: @MNBooZe) are able to fetch APKs for all dpis and all architecture straight from the Google source and greatly helps to have as complete as possible packages for every device available.