OpenGapps not working for bullhead

[ghost]

I made another build of aosp 7.0.0_r6, after i downloaded from the master branch and gave -g option to execute-all.sh. without flashing gapps i'm able to see google's project-fi, when i flash opengapps (haven't tried other gapps) my bullhead just bootloops, i'm leaving a logcat, it might be helpful.

logcat_bootloop_1.txt

[anestisb]

Since smali/baksmali is not supporting yet Android N I'm not sure how the opengapps folks are generating the Google apks. As far as I remember they were extracting & de-optimizing bytecode from factory images with apktool/baksmali, which effectively means they have issues to resolve.

Also the official website mentions that the whole Android N support is at beta stage.

In short note, unless you have evidence that opengapps are working for Nougat, I'm not going to spend time chasing compatibility issues that might be unrelated to vendor blobs produced by my set of scripts.

The reason I've introduced the "gplay" config group is because I've been approached by lot of people to add binary blobs used by play services and are not mandatory for a running AOSP based system. GApps support is beyond the scope of this project. I just keep things simple & functional for people who want to build on the top of good default.

I've already seen forks expanding the configuration files to also include some of the GApps as part of the vendor extraction process. Not sure if they work, but maybe you can give it a try.

[ghost]

Okay, i will try them, i used opengapps 7.0 time ago with my bullhead and they worked flawlessly, maybe other gapps should work? If yes what? Meanwhile i tried banks's gapps and the result is that the build boots, but no google app installed..

[anestisb]

Alrighty, I'll do some digging then if you had them work in the past. Btw 7.0.0_r6 tag is for Angler, 7.0.0_r4 is for bullhead. Not sure if any bits matter for this use case, although I recommend you switch just in case.

[nychitman1]

FWIW, the reason OpenGapps works is because they are using the pre-deodexed gapps from the Android One device image. @mrbanks

[ghost]

Yes for some reason I am guessing the Google apks aren't really liking the new deodexing method. I am guessing due to the new APK Signature Scheme v2 introduced in Android 7.0 Nougat. Deodexing should be ok for normal vendor apks.

[anestisb]

I don't see how OpenGapps are connected (at least from the perspective of the runtime) with the new "deodexing" method used by this project for the vendor blobs. We're talking for two complete different set of bytecode resources which happen to be assembled via different methods. As long as the ART runtime is happy with the bytecode generated from the new "deodex" method they should be ok for using with AOSP.

Also regarding the new signature scheme. This set of scripts is stripping the signature metadata from all repaired APK files. As such the AOSP build chain ensures re-signing with the platform keys and automatically picking up the supported signature scheme.

Now I'm trying to follow some of your steps regarding the OpenGapps thing and lots of bits don't make much sense to me:

• OpenGapps try to maintain the Google signature for the APKs (check META-INF/CERT.RSA to confirm). However all the vendor extracted bytecode APKs are signed with the platform key. As such if there is a signature protection level at GApp manifests (IPC between bytecode signed with same cert), which from what I remember is a lot, it cannot work by design. So not sure how things are supposed to work here. Maybe some folks familiar with GApps internals can help.
• Cherry picked installations from OpenGapps archive are failing with INSTALL_PARSE_FAILED_NO_CERTIFICATES error returned from package manager. The logcat mentions that APK is signed using APK Signature Scheme V2, but no such signature was found. How did you manage to make them work against a Nougat Nexus device as you mentioned?
• If you try to flash OpenGapps from recovery, how are you dealing with dm-verity signatures corruption. Are you disabling enforcing for your AOSP builds or modifying part of the generated makefiles? If not then device should not boot at all after pushing changes to /system.

[ghost]

I don't really know, i tried flashing them with CypherOS 3.0 beta build for bullhead (https://www.androidfilehost.com/?fid=24651430732237827) and they worked just fine, the device booted and no crash or something.

I haven't modified nothing from the makefiles, nor disabled enforcing yet, by flashing them in recovery the device just stands on 'android' writing with:

[NDK] bindNDKSensors: Sensor server is unavailable. Waiting for service AtCmdFwd... AtCmdFwd service not published, waiting... retryCnt : (counter)

that just spams the entire logcat since its start. Nothing more.

[anestisb]

Did some digging with Open GApps so answering my questions:

1. Regarding the different signatures for platform bytecode & Open GApps bytecode. Open GApps installations script is quite aggressive since it removes lot of files/packages under /system prior to installing the GCore & GApps. This effectively means that GApp packages are self-contained in terms of relying bytecode and thus should work as is despite the current state of /system.
2. Recent GApps builds do not appear to be affected of the Signature Scheme version issue.
3. dm-verity needs to be turned off both for /system & /vendor since installation script modifies files in both partitions when flashing post build.

I've managed to install & work Open GApps Nano package under both Angler & Bullhead without any problems by following these steps:

• Generate vendor blobs with -g flag
• Make a userdebug build so that dm-verity can be disabled
• Flash device and boot for first time
• Disable dm-verity over adb
• Reboot to recovery
• Flash Open GApps Nano package via adb sideload
• Reboot as normal to system
• Manually modify Google Play Services permissions from settings since they're not auto assigned
• Enroll a google account & work as normal

So the biggest problem with GApps is procedural and not technical. Things will be much easier if GApps are integrated into build process since all previous bits can be handled in an automated way via a few changes. Unfortunately I can't do any further testing from that angle since the Open Gapps source code is really huge and I don't have space to waste in my SSD build envs.

As such from my perspective there is no issue here. There aren't much I can do to help the process with GApps rather than keep the gplay configs compatible. So let me know if some specific package from configs is creating any issues.

[ghost]

Just tried your steps, and effectively the issue does not persists, thank you so much man