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

Search This thread

MastahF

Inactive Recognized Developer
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: 262,529
  • banner.jpg
    banner.jpg
    75.8 KB · Views: 61,169
  • roundedbanner.png
    roundedbanner.png
    240 KB · Views: 721,735
Last edited:

Rapper_skull

Senior Member
Apr 21, 2011
518
397
Naples
Xiaomi Mi Mix 2S
Realme GT 2 Pro
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://xdaforums.com/android/general/alpha-gapps-stock-t3093389
 
Last edited:
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
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://xdaforums.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
518
397
Naples
Xiaomi Mi Mix 2S
Realme GT 2 Pro
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
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
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
518
397
Naples
Xiaomi Mi Mix 2S
Realme GT 2 Pro
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
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
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
518
397
Naples
Xiaomi Mi Mix 2S
Realme GT 2 Pro
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
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
518
397
Naples
Xiaomi Mi Mix 2S
Realme GT 2 Pro
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.
  • 836
    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
    36
    Is it possible to get a test version of the arm version aswell?
    I run arm/arm64 builds of pico, nano and stock for testing.

    Once they are tested a bit and seem stable, I upload them to MediaFire.
    MediaFire - Link

    Android 12 builds are in the SDK31 folder.
    The 20211218 builds include some permission updates.​

    ---

    Last week I ran SDK32 builds to test on LineageOS.
    LineageOS is merging 12.1.0_r1 into the 19.0 branch instead of creating a 19.1 branch.
    LineageOS Gerrit - Topic 12L - Link
    Edit: I just checked and see they decided to bump up to 19.1 a few days ago.​

    Note:
    Now that Android 12L is official, the release props still show as 12 not 12.1 or 12L.
    The build tag was bumped to 12.1.0 and the boot image is now SDK32 but, the kernel version is still showing as 12.0.0
    The boot image was SDK31 on the 12L preview release.​

    The only way to determine if you are running 12 or 12L is by checking the SDK level.
    SDK31 = Android 12
    SDK32 = Android 12L

    The initial 12L OpenGApps test builds were blind builds and untested.
    I did not have a device/rom to test them on. 🙃

    I few days later I was able to test them on a Pixel C, Lineage 19.0 SDK32 build.
    Since it is a tablet, it utilized the large screen layout of SDK32.​

    The 12L pico and nano builds seem to be safe.

    The 12L stock build had issues with Pixel launcher so, I would suggest not using it for now.
    Unless you are using a gapps config script to customize the install.

    Android 12L (SDK32) test builds are currently on gDrive.
    gDrive - Link


    Everyone is welcome to give them a try.

    Cheers all. :cowboy:

    Edit:
    See additional posts.
    Post # 7,316
    Post # 7,319
    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