• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

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

Search This thread
Black Screen in Setup Wizard

A clean install LineageOS 18.1 Xiaomi Mi 6 (sagit) + Open GApps Stock user reported here in the LOS sub:

"Older Open GApps packages still don't seem to work completely right, the one from 11-05-2021 gives me a black screen when I choose to recover a backup...."
***

I am on android 10 and both 12th and 13th still crash on installation screen.

Setup wizard when trying to go to google account screen it never makes it, it crashes.
Rom lineage 10.1, gaps pico 05/11/210 and clean install.
***
 
  • Like
Reactions: Nezorflame

ipdev

Recognized Contributor
Feb 14, 2016
1,668
1
2,442
Google Nexus 10
Nexus 7 (2013)
Hi all. :)

Long story short.

Looking for opinions on reversing the order of (or improving) the abi check.
OpenGApps - Github - Installer Script Line 1665 - Link

Reversing it (checking for cpu.abi first) should fix the wrong architecture being found on some devices.
Code:
device_architecture="$(get_prop "ro.product.cpu.abi")";
  if [[ -z $device_architecture ]]; then
    device_architecture="$(get_prop "ro.product.cpu.abilist")";
  fi;
I prefer looking for the newer prop first but, maybe this time it would be better looking for the older value first?

I have not tried it yet but, it should fix the architecture mismatch I recently ran into on my Poco F1.
The custom rom (used ro.product.cpu.abi) did not set ro.product.cpu.abilist in any of the prop files so OpenGApps set it from TWRP's default.prop.
Not sure if this affect other devices or not. :unsure:
First time I ran into it and I have wiped, formatted and flashed my Poco F1 many times.
Not sure why this only showed up now.


I am using the official TWRP for the Device from twrp.me
TWRP for Xiaomi Pocophone F1 - twrp.me - WebSite - Link
Code:
beryllium:/ # for i in $(find / -name 'default.prop' 2> /dev/null); do echo $i && cat $i | grep 'cpu.abi'; done;
/default.prop
# ro.product.cpu.abi and ro.product.cpu.abi2 are obsolete,
# use ro.product.cpu.abilist instead.
ro.product.cpu.abi=arm64-v8a
ro.product.cpu.abilist=armeabi-v7a,armeabi
ro.product.cpu.abilist32=armeabi-v7a,armeabi
ro.product.cpu.abilist64=
beryllium:/ #

Thoughts on including one of these values. 🙃
  • ro.vendor.product.cpu.abilist
  • ro.odm.product.cpu.abilist
  • ro.system.product.cpu.abilist
Code:
ro.vendor.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi
ro.odm.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi
ro.system.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi

Cheers all. :cowboy:

Edit:
Dec. 15 2021 - Links to the PR and commit for reference.


OpenGApps - GitHub - Commit - Link
OpenGApps - GitHub - Pull request [# 944] - Link
 
Last edited:
  • Like
Reactions: curiousrom

Nezorflame

Senior Member
While I'm researching the reported issue, quick update to the A12 test package (only has apps updated to their SDK31 variant), package installer as well so apps should install fine.
Don't expect any serious work on A12 for now until we fix more important issues, but since it's already in a more or less working state, feel free to report anything you find so that I fix it when I have time.
ARM64 nano variant only for now: SourceForge
 

Nezorflame

Senior Member
Hi all. :)

Long story short.

Looking for opinions on reversing the order of (or improving) the abi check.
OpenGApps - Github - Installer Script Line 1665 - Link

Reversing it (checking for cpu.abi first) should fix the wrong architecture being found on some devices.
Code:
device_architecture="$(get_prop "ro.product.cpu.abi")";
  if [[ -z $device_architecture ]]; then
    device_architecture="$(get_prop "ro.product.cpu.abilist")";
  fi;
I prefer looking for the newer prop first but, maybe this time it would be better looking for the older value first?

I have not tried it yet but, it should fix the architecture mismatch I recently ran into on my Poco F1.
The custom rom (used ro.product.cpu.abi) did not set ro.product.cpu.abilist in any of the prop files so OpenGApps set it from TWRP's default.prop.
Not sure if this affect other devices or not. :unsure:
First time I ran into it and I have wiped, formatted and flashed my Poco F1 many times.
Not sure why this only showed up now.


I am using the official TWRP for the Device from twrp.me
TWRP for Xiaomi Pocophone F1 - twrp.me - WebSite - Link
Code:
beryllium:/ # for i in $(find / -name 'default.prop' 2> /dev/null); do echo $i && cat $i | grep 'cpu.abi'; done;
/default.prop
# ro.product.cpu.abi and ro.product.cpu.abi2 are obsolete,
# use ro.product.cpu.abilist instead.
ro.product.cpu.abi=arm64-v8a
ro.product.cpu.abilist=armeabi-v7a,armeabi
ro.product.cpu.abilist32=armeabi-v7a,armeabi
ro.product.cpu.abilist64=
beryllium:/ #

Thoughts on including one of these values. 🙃
  • ro.vendor.product.cpu.abilist
  • ro.odm.product.cpu.abilist
  • ro.system.product.cpu.abilist
Code:
ro.vendor.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi
ro.odm.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi
ro.system.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi

Cheers all. :cowboy:
@osm0sis @mfonville WDYT?
I personally agree with this (and this is something @Nikhil suggested as well), so if there are no objections, might add this check.

BTW @ipdev feel free to post this kind of feedback/discussion on our Github as well, might be easier to communicate there.

Update: see https://github.com/opengapps/opengapps/pull/942 with this change.
 
Last edited:

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
14,912
33,758
Halifax
GT-i9250
Google Nexus 4

ronpaul-happening.gif
 
Testing Open GApps Packages Before Releasing Them


@Nezorflame - That's good. :cool: 👍

Next step, maybe be inspired by an other thing that MindTheGapps does: release new packages only once in a while after they are tested by actual humans.

If you look here and here the last 3 MindTheGapps-11 releases were on:

Mar 28, 2021

Apr 12, 2021

Sep 20, 2021 - That's the most recent @ the present.

Play Store and Play Services automatically update themselves in the background regardless of the user's update settings in Play Store so there is no reason to churn out daily untested releases and the apps are updated when you login Play Store: either manually or auto-updated if you choose so.

Broken Open GApps Builds Again!

The era of publishing untested rolling releases of Open GApps is over.

Google is moving the goal posts all the time and that breaks stuff.

Better a monthly thoroughly tested release instead.

That's better for the reputation of Open GApps & also for the users instead of wasting their time with broken builds.
***
 

ipdev

Recognized Contributor
Feb 14, 2016
1,668
1
2,442
Google Nexus 10
Nexus 7 (2013)
Testing Open GApps Packages Before Releasing Them



@Nezorflame - That's good. :cool: 👍

Next step, maybe be inspired by an other thing that MindTheGapps does: release new packages only once in a while after they are tested by actual humans.

If you look here and here the last 3 MindTheGapps-11 releases were on:

Mar 28, 2021

Apr 12, 2021

Sep 20, 2021 - That's the most recent @ the present.

Play Store and Play Services automatically update themselves in the background regardless of the user's update settings in Play Store so there is no reason to churn out daily untested releases and the apps are updated when you login Play Store: either manually or auto-updated if you choose so.
Just to note.

MTG is not perfect either. ;)

Their installer script was broken.
[ROM][UNOFFICIAL][LineageOS][18.1/19.0][dragon] -> 2021-11-17 - xdaThread - Link
Four months to incorporate the PR to fix it. :(

Cheers. :cowboy:
 
  • Like
Reactions: ipdev

Magendanz

Senior Member
Mar 25, 2008
836
806
Issaquah, WA
www.Vote4Chad.com
I'm so excited to finally have Android 11 stock builds, but am seeing a WebView problem on the Galaxy Tab A 8.0 (SM-T290, ARM64) that seems related to issues #820 and #804. Setup cannot progress past attempting Google Play Services sign-in and skipping setup results in the same problem when logging into the Play Store or Chrome, showing only a black screen and the navigation bar. If I check WebView Implementation in Developer Options, it shows None.

Can anyone recommend a workaround for this? Previously, we just needed to match versions for Chrome and Trichrome, but they both seem to currently be 81.0.4044.138.
So, I did ultimately find a workaround: Adding WebViewGoogle to the gapps-config.txt allowed me to get through the Setup Wizard and Google Play Services sign-in. WebView implementation shows as "Android System WebView 94.0.4606.71" (which I assume it got from my underlying GSI) and everything seems to be working fine now.

Shouldn't it be installing WebViewStub for Android 7.0+, though?
 
  • Like
Reactions: curiousrom

Md Husain

Member
Aug 11, 2019
18
3
Madaripur
www.facebook.com
Hello,

In the open_gapps_logs file, there is a line, Google Pixel Features | false

Screenshot_20211122-114640_HTML_Viewer.png


So actually which devices it will support on?

Is it possible to force this features to support, making Google Pixel Features | true ?
 

myxal

Senior Member
Sep 5, 2011
115
16
Cheers.
TL;DR: Can any developer tell me if it's okay for a ROM developer to provide android version info only via the ro.vendor.build.version.* properties? (Ie. without the ro.build.version.* properties, which the opengapps installer is currently looking for).

I have a Nexus 4 which I'm keeping alive with CarbonROM (8.0, Android 10). Since one build about 6 months ago, opengapps stopped being installable, always complaining about insufficient android version. The version detected by opengapps installer would be 5.1.1 - which - I'm guessing - is the version of android the recovery is using.

After tinkering with the installer script to find out what's going on, I concluded that the properties that the installer is checking (ro.build.version.release and ro.build.version.sdk) are not present in any property file shipped by CarbonROM in the current build. I now have noticed however, there are ro.vendor.build.version.release and ro.vendor.build.version.sdk properties under /system/vendor/build.prop. Is this some new normal? Does opengapps need to fix the installer, or is this a broken ROM build?
 
  • Like
Reactions: ipdev

ipdev

Recognized Contributor
Feb 14, 2016
1,668
1
2,442
Google Nexus 10
Nexus 7 (2013)
Cheers.
TL;DR: Can any developer tell me if it's okay for a ROM developer to provide android version info only via the ro.vendor.build.version.* properties? (Ie. without the ro.build.version.* properties, which the opengapps installer is currently looking for).

I have a Nexus 4 which I'm keeping alive with CarbonROM (8.0, Android 10). Since one build about 6 months ago, opengapps stopped being installable, always complaining about insufficient android version. The version detected by opengapps installer would be 5.1.1 - which - I'm guessing - is the version of android the recovery is using.

After tinkering with the installer script to find out what's going on, I concluded that the properties that the installer is checking (ro.build.version.release and ro.build.version.sdk) are not present in any property file shipped by CarbonROM in the current build. I now have noticed however, there are ro.vendor.build.version.release and ro.vendor.build.version.sdk properties under /system/vendor/build.prop. Is this some new normal? Does opengapps need to fix the installer, or is this a broken ROM build?
Nice investigating and a good question. :)

The OpenGApps scripts can be a little confusing.

To clarify.
The installer script uses the SDK level.
Code:
# Get ROM SDK version
rom_build_sdk="$(get_prop "ro.build.version.sdk")"
[GitHub] - Installer script lines 1635-1636 - Link

The value found is compared to the OpenGApps build ($req_android_sdk) that you are trying to install.
Code:
# Check to make certain user has proper version ROM Installed
if [ ! "$rom_build_sdk" = "$req_android_sdk" ]; then
[GitHub] - Installer script lines 1651-1652 - Link

--

I checked CarbonROM 8 for mako.
Extracted and mounted the system image.

The system build prop does contain ro.build.version.sdk.

Part of the system/build.prop
Code:
# begin common build properties
# autogenerated by build/make/tools/buildinfo_common.sh
ro.system.build.date=Sat Nov 20 05:22:56 CET 2021
ro.system.build.date.utc=1637382176
ro.system.build.fingerprint=google/occam/mako:5.1.1/LMY48T/2237560:user/release-keys
ro.system.build.id=QQ3A.200805.001
ro.system.build.tags=release-keys
ro.system.build.type=user
ro.system.build.version.incremental=033719fce0
ro.system.build.version.release=10
ro.system.build.version.sdk=29
ro.product.system.brand=google
ro.product.system.device=mako
ro.product.system.manufacturer=LGE
ro.product.system.model=Nexus 4
ro.product.system.name=occam
# end common build properties
# begin build properties
# autogenerated by buildinfo.sh
ro.build.id=QQ3A.200805.001
[email protected]
ro.build.version.incremental=033719fce0
ro.build.version.sdk=29
ro.build.version.preview_sdk=0
ro.build.version.preview_sdk_fingerprint=REL
ro.build.version.codename=REL
ro.build.version.all_codenames=REL
ro.build.version.release=10
ro.build.version.security_patch=2021-11-05
ro.build.version.base_os=
ro.build.version.min_supported_target_sdk=23
ro.build.date=Sat Nov 20 05:22:56 CET 2021
ro.build.date.utc=1637382176
ro.build.type=user
ro.build.user=carbon
ro.build.host=saturn.carbonrom.org
ro.build.tags=release-keys
ro.build.flavor=carbon_mako-user
# ro.product.cpu.abi and ro.product.cpu.abi2 are obsolete,
# use ro.product.cpu.abilist instead.
ro.product.cpu.abi=armeabi-v7a
ro.product.cpu.abi2=armeabi
ro.product.cpu.abilist=armeabi-v7a,armeabi
ro.product.cpu.abilist32=armeabi-v7a,armeabi
ro.product.cpu.abilist64=
ro.product.locale=en-US
ro.wifi.channels=
# ro.build.product is obsolete; use ro.product.device
ro.build.product=mako
# Do not try to parse description or thumbprint
ro.build.description=occam-user 5.1.1 LMY48T 2237560 release-keys
ro.carbon.device=mako
# end build properties

Not sure why SDK29 is not found for you. :unsure:

Cheers. :cowboy:

PS.
I charged mine up and will test once I (re)partition it. ;)
 

myxal

Senior Member
Sep 5, 2011
115
16
Thanks for taking a look at this.

I checked CarbonROM 8 for mako.
Extracted and mounted the system image.

The system build prop does contain ro.build.version.sdk.
Interesting. 🤔 I only checked the system partition (didn't have a linux box ready) after installing CarbonROM with TWRP, and manually resizing the partition (via adb shell):
Code:
# e2fsck -fy <system partition>
# resize2fs <system partition>
# e2fsck -fy <system partition>

I just installed the ROM again, without resizing or checking the partition - that file exists but is empty.

My /system/addon.d only has "50-hosts" and "70-gapps" in it, and none of those touch the file AFAICT. Is there anything else that might be touching the system partition after the image is written to the partition? (aside from CarbonROM's own installer, which I'm just about to check)
 

myxal

Senior Member
Sep 5, 2011
115
16
I think I see what's going on...
  • CarbonROM ROM's system partition image is sized to 1.2 GiB.
  • The image of the system partition itself does not contain the build.prop file - it's part of the zip archive as a dedicated file.
  • The 1.2G partition size is not enough for opengapps nano, which I wish to use.
  • opengapps' addon.d script backs up opengapps and restores it after a new CarbonROM system image is recorded on the partition. Crucially, this happens before I have a chance to manually resize the partition to fit opengapps (my system partition is 2 GiB)
  • (My guess) The system.build prop should be copied after the addon.d scripts are executed.
  • However, restoring the opengapps backup onto the not-yet-resized system partition exhausts all free space, so when the installer tries to copy build.prop file, it only manages to create the directory entry, but doesn't copy any data. (How the **** is this not detected as an error is beyond me.)
My question for opengapps would be - does the opengapps backup contain anything that's not in the installer? (I would just nuke the system partition before installing CarbonROM and installing opengapps as "new")

I used to have an addon.d script to do the resize automagically during ROM installation years ago, but recall it not working for some reason. I found and will try this one to see if it works.

EDIT: I got the script working (the payload version from here), and was a bit surprised - the filesystem was grown, and the gapps script executed with errors on chcon (couldn't change context), so actually I ended with a filesystem filled less than it was before. (0.8 GB vs 1.2 GB). Nevertheles, build.prop was copied successfully and opengapps installation worked without issues.
 
Last edited:

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
14,912
33,758
Halifax
GT-i9250
Google Nexus 4
Bootloop here with open_gapps-arm64-11.0-nano-20211203.zip

Went back to 20211125 that works
In before curiousrom! 😆

Reported it to the team. 👍

Any in between those working?

Edit: Also some logs of the bootloop and GApps install would be nice to help narrow it down.
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 3
    Re: OnePlus One - Open GApps Pico Insufficient Space - GogleTTS

    Sure, see attached. Note: this is the log I get when having installed the Jan. 10 version of OpenGApps pico and then trying to upgrade to the Jan. 15 version.

    Would you also need the file open_gapps_debug_logs.tar.gz?

    Thanks for the log & infos. :cool: 👍

    No need for the "open_gapps_debug_logs.tar.gz" in this case.

    So if I understand it correctly, then there's no harm in skipping the googletts package during installation of OpenGApps. And I can still install and update the application via the Play Store -- right?

    Yes but there is no point in doing it in your case because updates to your open_gapps-arm-11.0-pico-20220110 package, including for GoogleTTS, will be downloaded to the /data/ partition which does not have the same size limitation as the system partition where the ROM + Open GApps was installed.

    That would be helpful for a new clean install.

    I never understood why GoogleTTS is included in Pico which is the Open GApps minimal installation package. ¯\_(ツ)_/¯

    That app is not essential & can be installed later @ any time by the user if he wants it.
    ***
    2
    Also, builds are still paused since 20211221? Intentional, or something broke and nobody noticed yet?

    I noticed and was glad that the crazy machine churning out daily untested builds was finally stopped.

    Better 1 good build a month and stick with it if no issues are reported IMO.
    ***
    1
    look at #7219

    OpenGApps UNOFFICIAL - MediaFire - Link
    The Android 12 versions are in the SDK31 folder.

    But be aware that this is a REAL EARLY release.
    I would not take them for any device in production
    1

    setupwizarddefault-x86_64 is accessing a deleted field isCarrierAp of apex package android.net.wifi​


    setupwizarddefault-x86_64 is accessing a deleted field isCarrierAp of android.net.wifi.ScanResult and crashes. Since this package (com.android.wifi) is apex so it will be updated by Google automatically and EVERY x86_64 Android 11 device with openGApps installed will crash (bootloop) by this issue after com.android.wifi is updated by oepnGApps itself.
    FYI, This field is removed in this commit: https://cs.android.com/android/_/an...fi/+/c50556db869a1caefab533c64ab640a6ba1ae934

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: java.lang.RuntimeException: Unable to create application com.google.android.setupwizard.SetupWizardApplication: java.lang.RuntimeException: java.lang.NoSuchFieldException: No field isCarrierAp in class Landroid/net/wifi/ScanResult; (declaration of 'android.net.wifi.ScanResult' appears in /apex/com.android.wifi/javalib/framework-wifi.jar)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6724)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at android.app.ActivityThread.access$1300(ActivityThread.java:237)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1913)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:106)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at android.os.Looper.loop(Looper.java:223)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7664)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: Caused by: java.lang.RuntimeException: java.lang.NoSuchFieldException: No field isCarrierAp in class Landroid/net/wifi/ScanResult; (declaration of 'android.net.wifi.ScanResult' appears in /apex/com.android.wifi/javalib/framework-wifi.jar)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at mm.a(PG:318)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at lr.l(PG:292)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at lr.a(PG:206)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at lr.<init>(PG:112)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at mc.a(PG:141)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at mc.d(PG:50)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at mc.b(PG:79)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at ate.a(PG:36)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at aqz.a(PG:31)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at com.google.android.setupwizard.SetupWizardApplication.onCreate(PG:11)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1192)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6719)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: ... 8 more

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: Caused by: java.lang.NoSuchFieldException: No field isCarrierAp in class Landroid/net/wifi/ScanResult; (declaration of 'android.net.wifi.ScanResult' appears in /apex/com.android.wifi/javalib/framework-wifi.jar)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at java.lang.Class.getDeclaredField(Native Method)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: at mm.a(PG:316)

    11-25 17:52:43.284 14145 14145 E AndroidRuntime: ... 19 more
    1
    Is it about "AOSP on IA Emulator" on a computer?
    Yes, in the android emulator, with a system-image as provided by the SDK Manager, from google (original post edited as per your request)
  • 831
    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.