Pixel Launcher misses needed permissions and recent app list doesn't work

[ADeadTrousers]

Hi.

I'm not sure if this is the right place to ask for guidance but if it's not maybe someone will see this and point me to the right place.
Anyway, I tried to include gapps into my LineageOS 17.1 build and run into two problems. I want only those gapps installed that replace the stock apps so I used these settings:
https://github.com/ADeadTrousers/android_device_Unihertz_Atom_XL/blob/master/gapps_prop.mk

But right after the first time startup wizzard finishes Pixel Launcher crashes.
From previous experiences (when the Pixel Launcher issues were brandnew) I knew that I needed to manually add android.permission.STATUS_BAR and android.permission.MANAGE_ACTIVITY_STACKS to /data/system/packages.xml to get it to work again. Naturally I checked if the priv_app-permissions-google.xml is included in the build and it's there but it doesn't seem to get applied correctly during the first time run.

Furthermore the recent app list is not responding at all. The button on the phone is working though. I'm not sure if this is a side effect of Pixel Launcher crashing on first time start so that it couldn't finish a vital step for this to work or if it is a totally different thing. With Nova Launcher and it's possibility to run actions directly (com.google.android.apps.nexuslauncher/com.android.quickstep.RecentsActivity) I was able t get a sneak peak at the recent app list but it immediately crashed (Maybe because Pixel isn't running while Nova is running). So my guess is, because the button is essentially working and the "action" is at least callable, that this "string" doesn't get applied alright:
https://forum.xda-developers.com/showpost.php?p=78029447&postcount=483
(Sorry couldn't find a better source)

I'm at my wits end for now, cause I don't know what else to check or where to start at all fixing these problems.

wkr ADT

[MarijnS95]

If you see the launcher crash on privapp permissions that are defined in the xml this is perhaps the same issue as #269 (comment)?

privapp-permissions-google only reside on /system/etc/permissions while this app might (though unlikely) end up on /product? There's no LOCAL_PRODUCT_MODULE := true anywhere in aosp_build making this very unlikely. It seems the linked issue had an external factor moving apps between partitions.

[ADeadTrousers]

Nope, thats not it.
privapp-permissions-google.xml and `PixelLauncher.apk' are on the same partition (system).
After some trial and error I was finally able to build an -eng flavor of my ROM (yeah I'm a bloddy beginner) and do a complete logcat from boot until the first time startup wizzard finishes and Pixel Launcher crashes.
With 6 MB it's quite a chunk. Do you have any suggestions what to look for?

[acr92]

Just look for a stacktrace. You can search for "Exception". Or check adb logcat -b crash It shows any app crashes.

…

On Tue, 13 Oct 2020, 23:28 ADeadTrousers, ***@***.***> wrote: Nope, thats not it. privapp-permissions-google.xml and `PixelLauncher.apk' are on the same partition (system). After some trial and error I was finally able to build an -eng flavor of my ROM (yeah I'm a bloddy beginner) and do a complete logcat from boot until the first time startup wizzard finishes and Pixel Launcher crashes. With 6 MB it's quite a chunk. Do you have any suggestions what to look for? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#276 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACPHGWLWGPZGMSYFULMZS3SKTA7XANCNFSM4SNE52NQ> .

[ADeadTrousers]

I think I have a clue:
Pixel Launcher itself seems not to be the culprit. Google Play Services are. Or more likely the "ungranting" of various permissions from it.

10-13 17:34:28.222 1079 2990 I PackageManager: Un-granting permission android.permission.MANAGE_ACTIVITY_STACKS from package com.google.android.gms (protectionLevel=2 flags=0xa0cabe45)

I will try an new build were I add an exception to /etc/default-permissions/opengapps-permissions-q.xml

[ADeadTrousers]

It didn't work. It would have been too easy.
But what bugs me is, that the lines with PackageManager: Un-granting permission are still there.
Is there a way to figure out which permission files the PackageManager actually uses (or finds) during system boot?

[ADeadTrousers]

Finally I know what's up:
The overlay for Pixel Launcher doesn't get applied:
https://github.com/opengapps/aosp_build/tree/master/overlay/pixellauncher/28/frameworks/base/core/res/res/values/confix.xml
If I put the value directly into my devices overlay everything is working fine.

[MarijnS95]

Neat! Looks like that's only applied here:

aosp_build/opengapps-packages.mk

Lines 286 to 289 in 060cf79

	ifneq ($(filter 28,$(call get-allowed-api-levels)),)
	DEVICE_PACKAGE_OVERLAYS += \
	$(GAPPS_DEVICE_FILES_PATH)/overlay/pixellauncher/28
	endif

If GAPPS_FORCE_PIXEL_LAUNCHER is set to true:

aosp_build/opengapps-packages.mk

Line 276 in 060cf79

ifeq ($(GAPPS_FORCE_PIXEL_LAUNCHER),true)

IMO PixelLauncher/Android.mk should be wrapped in GAPPS_FORCE_PIXEL_LAUNCHER so that it can't be wrongly included by accident, or this "device overlay" converted to RRO (though problematic on SDK <= 28: 55ed81d).

[ADeadTrousers]

I really lost sight of the wood for the trees:
GAPPS_FORCE_PIXEL_LAUNCHER was the missing part. I was just so fixated on that api-level-filter that I overlooked that higher level if-statement.
Thanks for your help.

P.S.: What should we do with this issue? For me it's fixed now. But does anyone see a possible greater "fix" so no one else stumbles into this pit, having set to install Pixel Launcher with overrides but forgetting this important property. Maybe in the docs/Readme.

[MarijnS95]

@ADeadTrousers I see two options: hide the package itself behind GAPPS_FORCE_PIXEL_LAUNCHER (or a less force-y name) that also surrounds the inclusion of this overlay, and/or converting it to an RRO (similar to the links posted above) that's depended upon from PixelLauncher. The latter has to be tested on SDK <= 28 though.

Let's see what the rest of the maintainers think in the coming days?