self package targeting for side by side install revanced coregms

[zappybiby]

Several call sites were still using GMS_PACKAGE_NAME even when they were really trying to target the currently installed GmsCore APK. This change switches those sites to runtime self-package resolution, while keeping the remaining explicit package cases unchanged.

Goals of the patch:

If a call site means "this installed GmsCore APK", use the runtime self package.
If a call site means the canonical Google package identity for protocol, network, spoofing, or compatibility, keep Constants.GMS_PACKAGE_NAME.
Do not use USER_MICROG_PACKAGE_NAME as a generic stand-in for "self".
Do not derive remote Maps / Dynamite resource contexts from a caller or embedding-app Context.

As part of the changes, the identified issue affecting patched YT Music app and Android Auto (DynamiteContextFactory) is fixed. DynamiteContextFactory no longer resolves the GmsCore package context through GMS_PACKAGE_NAME, and now uses BuildConfig.APPLICATION_ID instead. That keeps the YT Music on Android Auto Dynamite path working for renamed/repackaged installs.

Closes https://github.com/ReVanced/revanced-patches/issues/6602

[oSumAtrIX]

If a call site means "this installed GmsCore APK", use the runtime self package

This can be optimized with a compile time constant, sparing resolving the package name dynamically. Check if this reduces the amount of code changes needed. (BuildConfig.APPLICATION_ID like you already used works well)

[oSumAtrIX]

Was this supposed to be closed?

[jenno-verdonck]

Should the issues related to this PR be added to it so that they get automatically closed and so that people can more easily find it?

[Ushie]

In the opening message of this PR you can add

"Closes #number" as many times as you want

[oSumAtrIX]

Does this PR also solve notifications, apparently people don't receive them currently

[jenno-verdonck]

In the opening message of this PR you can add

"Closes #number" as many times as you want

I know but I did not create the PR so I can't edit the opening message.

[zappybiby]

I don't want to pivot too far off the main focus of the PR, but I did see the patched YTM app did send me this notification, which I believe is remote? You can see in my screenshot that both the stock app and the patched app sent it (YT Music Revanced is the 9:34 notification)

I'm not sure what exactly notification-wise wasn't working for users, I don't normally have notifications on.

Remote notification diagnostic excerpt

(Note: some aspects of my debugger tool aren't working properly, like the live downstream event watcher, so that's why none is shown)
label=firebase-transport-get-token-result | detail=tokenLength=142 | tokenPrefix=egj7IuKgTnGAH9S...
2026-03-14 21:34:27 | category=app-side | package=app.revanced.android.apps.youtube.music | label=firebase-receive-instanceid-receiver | detail=appState=service | replay=false | payloadProfile=<empty> | messageId=<empty> | focus=class=sdv | payload=class=sdv | repr=sdv@bfe55a
2026-03-14 21:34:27 | category=app-side | package=app.revanced.android.apps.youtube.music | label=firebase-receive-app-handler | detail=appState=service | replay=false | payloadProfile=<empty> | messageId=<empty> | focus=class=bcyd | payload=class=bcyd | repr=bcyd@8116881
2026-03-14 21:34:27 | category=app-side | package=app.revanced.android.apps.youtube.music | label=firebase-receive-app-handler-return | detail=completed

2026-03-14 21:34:28 | package=app.revanced.android.apps.youtube.music | title=New release for you | text=77yolan • lul_0 | channel=5 | id=99
2026-03-14 21:36:21 | package=com.google.android.apps.youtube.music | title=New release for you | text=77yolan • lul_0 | channel=5 | id=99

app.revanced.android.apps.youtube.music
---------------------------------------
Installed -> installed | version=8.10.52 | targetSdk=35
GmsCore DB app row -> known=true | allowRegister=true | wakeForDelivery=true | lastError=<empty> | lastMessage=2026-03-14 21:34:27 | totalMessages=1 | totalBytes=2692
GmsCore registrations -> 1 row(s): signature=1d8d63eb8... | timestamp=2026-03-14 18:42:40 | regId=egj7IuKgTnGAH9SEb...
App-side diagnostics -> 56 event(s) | last=2026-03-14 22:52:01 | firebase-transport-get-token-result | tokenLength=142 | tokenPrefix=egj7IuKgTnGAH9S...
Register provider probe -> none
Token request probe -> none
Firebase transport probe -> 52 event(s) | last=2026-03-14 22:52:01 | firebase-transport-get-token-result | tokenLength=142 | tokenPrefix=egj7IuKgTnGAH9S...
Registration handshakes -> none
Registration persistence -> none
Live downstream delivery -> none
Downstream receiver path -> receiverPermission=none | receivers=1 match(es): app.revanced.android.apps.youtube.music/com.google.firebase.iid.FirebaseInstanceIdReceiver
Firebase messaging service -> 2 match(es): app.revanced.android.apps.youtube.music/com.google.android.apps.youtube.music.notifications.FcmMessageListenerService, app.revanced.android.apps.youtube.music/com.google.firebase.messaging.FirebaseMessagingService
Firebase receive handlers -> 4 event(s) | last=2026-03-14 21:34:27 | firebase-receive-app-handler-return | completed
Downstream replay probe -> 2 event(s) | last=2026-03-14 10:28:31 | probe-result | messageId=diag-1773498511542 | payloadProfile=data_only_generic | matched=0 | dispatched=0 | permission=non... | payloadProfile=<empty> | postProbeAppState=service | postProbeHandlers=4 event(s): firebase-receive-new-token, firebase-receive-instanceid-receiver, firebase-receive-app-handler, firebase-receive-app-handler-return | postProbeReplayUi=24 event(s) | last=2026-03-14 21:34:28 | title=New release for you | text=77yolan • lul_0 | channel=5 | postProbeLocalUi=none

Is there an existing issue for notifications to discuss that part more?
I am still looking into the best way to test and diagnose remote notifications, to see if there's any change or if package renaming is related to the issue.

And @oSumAtrIX do you have thoughts on the microg package constant I mentioned in my comments? The PR functionally is essentially complete for the scope I wanted to cover, I verified the call sites resolve to correct package.

[oSumAtrIX]

Summary: With the few stock-only call sites known, I don't see further missed renamed sites that aren't part of the few niche call sites that don't have a matching Revanced component we could switch them to.

Just to understand, you believe this is complete, but you can't verify it is? It's fine though, i think this second review you did should give enough confidence for completeness.

[zappybiby]

Summary: With the few stock-only call sites known, I don't see further missed renamed sites that aren't part of the few niche call sites that don't have a matching Revanced component we could switch them to.

Just to understand, you believe this is complete, but you can't verify it is? It's fine though, i think this second review you did should give enough confidence for completeness.

What I did was the static analysis with androguard as I described. I also attached runtime probes to GmsCore and a diagnostic patch for Revanced YT/YTMusic to ensure call sites are being correctly resolved.

I feel quite confident that all potential call sites have been addressed. Im not worried about the small things I saw that only have a stock gms functionality as I don't think they have any significant impact. I already verified that one notification finding is essentially an older API that isnt used in either YT or YTMusic.

I am not familiar with tools like Frida so that kind of dynamic analysis is not something I could do.

[zappybiby]

YouTube notifications are working

[oSumAtrIX]

With a specific commit or unrelated to this PR?

[zappybiby]

I received that while having my PR Coregms installed to commit 12227d7

With Revanced Patches 6.1.0, Revanced YouTube 20.14.43

[oSumAtrIX]

thats really good, hopefully its what fixes the notifications again, great work thanks!

[oSumAtrIX]

click this whenever youre ready

[zappybiby]

Pre-release for testing:
https://github.com/zappybiby/GmsCore/releases/tag/gmscore-pkg-rename-test-40-1

[MrPaulMarshall]

Pre-release for testing: https://github.com/zappybiby/GmsCore/releases/tag/gmscore-pkg-rename-test-40-1

I just wanted to say that I've tested the pre-release build today and confirm that YT Music works as intended on Android Auto. I have not tested notifications yet, I will write again if I get any.

Anyway, good job @zappybiby , thank you!

---

EDIT:

Notifications doesn't work for me, but I am not sure why.
I've re-installed Youtube and YT Music via Revanced Manager and they showed up as registered apps in microG settings. I've also gave all three apps (microG, Youtube and YT Music) full notifications permissions. However, none have showed up since doing that, even though I see new notifications inside Youtube app itself.

That's what I see in microG settings:

---

EDIT 2:

After some ADB debugging Gemini (AI) says that there may be issues with patches for Youtube app in regards to <receiver> and such. I don't know that stuff, but I can share the AndroidManifest.xml extracted from my current Youtube installation if someone wants to look at it.

AndroidManifest.xml

[oSumAtrIX]

Does upstream do this hack in other Gradle modules in the project as well, if not, how does it determine the current package name? If it doesnt do either, context.getPackageName() feels to be simpler. Check if upstream uses context.getPackageName() in such library modules where the package name cant be retrieved from the build script.

[oSumAtrIX]

context.getPackageName() is not equivalent here. In this maps flow, the Context passed into the Mapbox comes from the embedding app, not from GmsCore. That means context.getPackageName() would return the client app package, not the installed GmsCore package that createPackageContext(...) is trying to open.

Ah thats a problem, is there a context somewhere we can use that belongs to GmsCore?

[zappybiby]

Not an existing one that upstream passes into Mapbox. In upstream, the Mapbox entry points receive the embedding app Context/Activity, and then the module constructs its own GmsCore-side MapContext locally via createPackageContext(...). So there is already a GmsCore-owned context, but it is derived from the caller context and still needs the installed GmsCore package name to create it.

Upstream:

• uses MapsContextLoader’s chosen context for classloading/init.
• But does not reuse that same chosen context as Mapbox’s runtime base context.
• Mapbox reconstructs a new base context from the caller context plus a package string.

I suspect this was done because the backend needs a hybrid context, not just the raw module context. It needs access to GmsCore resources and code, while still preserving caller-app behavior for things like getPackageName().

When MapsContextLoader was added, changing all backends to use the selected module Context directly would have been a much larger behavioral refactor. Upstream seems to have chosen the lower-risk approach of addng the new loader for Maps initialization, while keeping the wrapper behavior unchanged.

I don't see much in the way of a simple, parity-conserving solution:

• context.getPackageName() returns the host app package, not GmsCore.
• The library module’s own package name is also wrong, because it is just the code namespace, not the installed app package.
• Using the app module’s BuildConfig.APPLICATION_ID would be cleaner, but it would create the wrong dependency direction because the app module already depends on Maps.

I would say it would make sense for upstream to consider a flow that does:

  1. MapsContextLoader picks the maps/module context.
  2. Mapbox reuses that exact chosen context as its base, while still keeping caller-app behavior layered on top.

[oSumAtrIX]

In this case if there is no context to get the pkg name from, instead of the build system providing the constant, a new constant can be added in the Constants class next to Constants.GMS_PACKAGE_NAME for example called Constants.GMS_CORE_PACKAGE_NAME maybe?

I am not sure about the name GMS_CORE_PACKAGE_NAME because official gms is also technically GMS_CORE, so im open for suggestions. The issue with this is that once again we fragment the actual package name, for example changing the flavor would not be reflected in that constant correctly.

Now here is the question, as we know, GmsCore supports flavors. Assume we use the user flavor in upstream GmsCore. Mapbox would use Constants.GMS_PACKAGE_NAME. This doesn't look right. Shouldn't it point to the user flavor? Is this a bug in upstream or maybe its even intended to point to the real GMS package name?

If this is unclear, we might have to report this to upstream to sort this question out. If they say its intended, we can keep the constant as is, if they say its a bug, we can upstream a fix (e.g., your build flavor code).

[zappybiby]

like you mentioned the upstream Mapbox path still uses Constants.GMS_PACKAGE_NAME for createPackageContext(...), so that path is not flavor-aware.

Because of that, I do not think a new hardcoded constant in Constants really fixes the issue. If it is not flavor-aware, if we make it flavor aware it just pushes the flavoring elsewhere.

I'm thinking we could ask upstream if they could consider not reconstructing the GmsCore context from a package string and instead letting MapsContextLoader provide the already-selected maps/module context to the backend.

then mapbox is build its wrapper from the caller app context and the selected maps/module context

[oSumAtrIX]

Okay so as i understand, this is actually an upstream issue. This part of the code is not flavor-aware. I will ask upstream about this. Lets see what they have to say to this.

[oSumAtrIX]

Actually, wouldn't this apply to all the places where the constant is hardcoded?

[oSumAtrIX]

microg#3367 opened an issue. Also I saw https://github.com/microg/GmsCore/blob/master/play-services-base/src/main/java/com/google/android/gms/common/GooglePlayServicesUtil.java#L153. Is this not supposed to be changed too?

[oSumAtrIX]

Rest lgtm!