AOSP build passed, stuck on Android logo on boot, priv-app permissions whitelisting errors
ConradGyllenhaal opened this issue · 14 comments
Only issues related to the code of The Open GApps Project scripts themselves
If you have found an issue with a pre-built OpenGApps.org package please use the XDA-Developers forum thread
Checklist
- The issue is not answered by reading the FAQ
- The issue is part of The Open GApps Project scope (and not of the pre-built OpenGApps.org packages scope, for support on those see XDA Forum)
If Open GApps compilation fails:
- The issue is not a duplicate
If Open GApps installation fails:
- Is the issue reproducible using the latest version of your recovery?
- Is the issue reproducible with (the latest) TWRP recovery? (other recoveries are only best-effort)
If receiving force closures after Open GApps installation:
- The issue is NOT an error within one of the bundled Google applications itself (verify by e.g. installing the application from the Play Store instead)
- The issue is reproducible on clean (=wiped
/data/partition) installation - The affected ROM includes the necessary patches and functionality as noted for Android versions and Platforms
- No non-AOSP hacks like privacy guards' permission restrictions etcetera are applied
Issue description:
Using your aosp_build repo/project, everything is fine during AOSP compilation, but I got bootloop.
I don't get bootloop when I don't add opengapps.
Reproduction Steps:
- Build AOSP and use aosp_build project/repo
- Flash AOSP image
- Boot...
- ...loop (stay infinitely on animated Android logo)
Expected behavior:
The device should boot normally.
Observed behavior:
Switching from release to debug build, I was able to get a no-auth root adb access during the bootloop. I can see that zygote and every services are killed every few seconds, and the boot sequence start again.
It seems to be linked to priv-app permissions whitelisting since I see:
08-11 12:37:54.748 1337 1337 E System : ****************************************** 08-11 12:37:54.748 1337 1337 E System : ************ Failure starting system services 08-11 12:37:54.748 1337 1337 E System : java.lang.IllegalStateException: Signature|privileged permissions not in privapp-permissions whitelist: {com.google.android.euicc: android.permission.WRITE_EMBEDDED_SUBSCRIPTIONS, com.android.sdm.plugins.dcmo: android.permission.MODIFY_PHONE_STATE, com.google.android.euicc: android.permission.WRITE_SECURE_SETTINGS, com.verizon.llkagent: android.permission.GET_ACCOUNTS_PRIVILEGED, com.google.intelligence.sense: android.permission.SUBSTITUTE_NOTIFICATION_APP_NAME, com.google.android.euicc: android.permission.MODIFY_PHONE_STATE, com.google.android.euicc: android.permission.START_ACTIVITIES_FROM_BACKGROUND, com.google.android.euicc: android.permission.READ_PRIVILEGED_PHONE_STATE, com.android.sdm.plugins.dcmo: android.permission.READ_PRIVILEGED_PHONE_STATE, com.google.euiccpixel: android.permission.READ_PRIVILEGED_PHONE_STATE, com.android.hotwordenrollment.xgoogle: android.permission.MANAGE_VOICE_KEYPHRASES, com.android.sdm.plugins.diagmon: android.permission.READ_PRIVILEGED_PHONE_STATE, com.verizon.llkagent: android.permission.MANAGE_USERS, com.android.hotwordenrollment.okgoogle: android.permission.MANAGE_VOICE_KEYPHRASES, com.google.intelligence.sense: android.permission.LOCATION_HARDWARE, com.google.android.euicc: android.permission.CHANGE_COMPONENT_ENABLED_STATE, com.google.intelligence.sense: android.permission.CAPTURE_AUDIO_HOTWORD, com.google.intelligence.sense: android.permission.WRITE_SECURE_SETTINGS, com.google.euiccpixel: android.permission.MODIFY_PHONE_STATE, com.google.euiccpixel: android.permission.REBOOT, com.google.android.euicc: com.android.permission.INSTALL_EXISTING_PACKAGES, com.google.android.euicc: android.permission.REBOOT, com.google.intelligence.sense: android.permission.MANAGE_SOUND_TRIGGER} 08-11 12:37:54.748 1337 1337 E System : at com.android.server.pm.permission.PermissionManagerService.systemReady(PermissionManagerService.java:2970) 08-11 12:37:54.748 1337 1337 E System : at com.android.server.pm.permission.PermissionManagerService.access$100(PermissionManagerService.java:122) 08-11 12:37:54.748 1337 1337 E System : at com.android.server.pm.permission.PermissionManagerService$PermissionManagerServiceInternalImpl.systemReady(PermissionManagerService.java:3031) 08-11 12:37:54.748 1337 1337 E System : at com.android.server.pm.PackageManagerService.systemReady(PackageManagerService.java:21785) 08-11 12:37:54.748 1337 1337 E System : at com.android.server.SystemServer.startOtherServices(SystemServer.java:1993) 08-11 12:37:54.748 1337 1337 E System : at com.android.server.SystemServer.run(SystemServer.java:513) 08-11 12:37:54.748 1337 1337 E System : at com.android.server.SystemServer.main(SystemServer.java:350) 08-11 12:37:54.748 1337 1337 E System : at java.lang.reflect.Method.invoke(Native Method) 08-11 12:37:54.748 1337 1337 E System : at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492) 08-11 12:37:54.748 1337 1337 E System : at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:908) 08-11 12:37:54.748 1337 1337 D SystemServerTiming: MakePackageManagerServiceReady took to complete: 574ms 08-11 12:37:54.748 1337 1337 E Zygote : System zygote died with exception
Since my build also include Magisk (https://github.com/CaseyBakey/chaosp), I'm able to change (with the Magisk resetprop command) the ro.control_privapp_permissions property to permissive. When doing this, the device instantly boot OK, the UI is started etc.
But, strangely, the quoted permissions are properly declared in the '/system/etc/permissions/privapp-permissions-google.xml' file on the device.
Typically:
sargo:/ # cat /system/etc/permissions/privapp-permissions-google.xml |grep -i -A10 euicc
<privapp-permissions package="com.google.android.euicc">
<permission name="android.permission.CHANGE_COMPONENT_ENABLED_STATE" />
<permission name="android.permission.MODIFY_PHONE_STATE" />
<permission name="android.permission.READ_PRIVILEGED_PHONE_STATE" />
<permission name="android.permission.REBOOT" />
<permission name="android.permission.START_ACTIVITIES_FROM_BACKGROUND" />
<permission name="android.permission.WRITE_SECURE_SETTINGS" />
<permission name="android.permission.WRITE_EMBEDDED_SUBSCRIPTIONS" />
<permission name="com.android.permission.INSTALL_EXISTING_PACKAGES" />
<permission name="com.android.permission.WRITE_EMBEDDED_SUBSCRIPTIONS" />
<permission name="com.google.android.permission.USE_GRIL" />
--
<privapp-permissions package="com.google.euiccpixel">
<permission name="android.permission.MODIFY_PHONE_STATE" />
<permission name="android.permission.READ_PRIVILEGED_PHONE_STATE" />
<permission name="android.permission.REBOOT" />
</privapp-permissions>
--
So we can see that, clearly, the package com.google.android.euicc has the android.permission.WRITE_SECURE_SETTINGS permission.
Upload the installation debug log (=tar.gz file) and logcat of Force Closure:
New link for the logcat since the previous one was deleted: https://dpaste.org/3Bxc
Don't wait to download it since it'll be deleted in 7 days and it's too big to be uploaded on pastebin.
@mfonville @Blystad do you have any idea where to look for?
The priv-app permissions are indeed whitelisted when looking at /system/etc/permissions/privapp-permissions-google.xml so it shouldn't prevent the booting?
Hmm, I agree that if they're specified in /system/etc/permissions/privapp-permissions-google.xml then it should be okay.
Can you boot the system using magisk, and then run (in adb shell):
pm get-privapp-permissions com.google.android.euicc
cat /system/etc/permissions/privapp-permissions-google.xml
Hi @Blystad, thanks for your answer.
Here is the corresponding log: https://pastebin.com/f6LwMLKW
Please note that I was able to access the ADB shell while the phone was still stuck on the android logo (as detailed in the first post) ;p
I think the "package" service is killed with every other services and thus, can't respond to this command.
edit: After "disabling" the priv-app-permissions whitelisting check, I got this: https://pastebin.com/5rwBCaiB
The list seems to be empty... but the xml seems to be OK?
Yes, I edited the previous post but it's less visible. Here it is:
After "disabling" the priv-app-permissions whitelisting check, I got this: https://pastebin.com/5rwBCaiB
The list seems to be empty... but the xml seems to be OK?
I'm using https://github.com/CaseyBakey/chaosp to compile AOSP for my device.
It's pretty straight-forward but I took a look and the only thing that I can see that could interfere with aosp_build, is another project used by CHAOSP, which is called android-prepare-vendor (https://github.com/AOSPAlliance/android-prepare-vendor).
We can see in config.json files, that "full" config (which are needed for Google Apps) add the privapp-permissions-google.xml file to the build tree. So maybe it's interfering in a way?
CHAOSP is using the RattlesnakeOS build script (https://github.com/CaseyBakey/chaosp/blob/10-testing/build.sh), and thus is pure AOSP with less than 10 patches.
All the modifications to AOSP are done within the apply_patches function.
I did check them and none is linked to priv-app permissions, or an specific hardening.
RattlesnakeOS doesn't add any "extra checks or protections" so it's not in this direction that we will find something.
To be sure, I'll try a new clean CHAOSP build from scratch.
@Blystad
A new, clean, build from scratch leads to the exact same problem.
Did you manage by your side to compile AOSP version 10 for a device, using opengapps/aosp_build and be able to boot without disabling the priv-app permission whitelisting?
I finally understood the problem and it is not linked to aosp_build!
A priv-app permission xml file can only act on priv-app from the same partition as the xml file.
android-prepare-vendor project was missing permission files from /product and /vendor partitions and some APKs from Google factory images where moved from /system to /vendor and /product partitions during the Android 9 -> 10 update.
I close this issue. Thanks for your time ;)
That's really interesting...Nice that you figured it out!
Yep I'm glad I figured it out!
For more details on this behaviour/mechanism @Blystad take a look here (https://source.android.com/devices/tech/config/perms-whitelist).
The sentence that got me was:
The privapp-permissions.xml file can only grant or deny permissions for privileged apps on the same partition. For example, if an app on the /vendor partition requests privileged permissions, the request can only be granted or denied by a privapp-permissions.xml file that’s also on /vendor.