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]

Apart from the review, rest lgtm. I would like to understand a last question apart from those:

How did you determine the completeness of the changes in this PR? If you just did it by skimming the code, there is possibilty that we missed changing something. Is there maybe a systematic approach to verify, that the fix is applied correctly everywhere where applicable?

[oSumAtrIX]

Is there an existing issue for notifications to discuss that part more?

Users dont receive notifications, i am not sure if this PR solves it, but since you receive notifications (with this PR) I assume it'll fix it too.

[zappybiby]

Apart from the review, rest lgtm. I would like to understand a last question apart from those:

How did you determine the completeness of the changes in this PR? If you just did it by skimming the code, there is possibilty that we missed changing something. Is there maybe a systematic approach to verify, that the fix is applied correctly everywhere where applicable?

Using androguard,
inventory-package-rename-sinks.py
I looked at common package rename sinks:

Common package rename sinks reviewed

Intent.setPackage(...)

Intent.setClassName(...)

Intent.setComponent(...)

ComponentName(...)

Context.createPackageContext(...)

PackageManager.getPackageInfo(...)

PackageManager.queryIntentServices(...)

PackageManager.resolveContentProvider(...)

ContentResolver.query(...), insert(...), update(...), etc.

Strings reviewed

I looked at strings containing:

exact:

com.google.android.gms

com.google.android.gsf

app.revanced.android.gms

org.microg.gms

contains:

.permission.C2D_MESSAGE

.c2dm.permission.

.gtalkservice.permission.

content://

com.google.android.gms.iid

com.google.android.c2dm

phenotype

subscribedfeeds

com.google.settings

google.messenger

prefix:

com.google.android.gms.

app.revanced.android.gms.

org.microg.gms.

Code paths reviewed for possible package renaming

I looked at code that could possibly relate to package renaming

Class.forName(...)

Class.getMethod(...)

Method.invoke(...)

Constructor.newInstance(...)

ClassLoader.loadClass(...)

System.loadLibrary(...)

Runtime.loadLibrary(...)

There were only two exercised runtime buckets that did not immediately collapse to a simple “app targeted ReVanced GmsCore and Android resolved ReVanced GmsCore” result.

After investigating them, they do not currently look like missed rename call sites where ReVanced functionality already exists, and I don't see further changes that need to be made.

Cronet HTTP-flags probe

The first is the Cronet HTTP-flags probe, which is a stock-only external probe:

{"package":"app.revanced.android.youtube","label":"rename-sink-pm-resolve-service","payload":{"intent":{"action":"android.net.http.FLAGS_FILE_PROVIDER"},"match":{"package":"com.google.android.gms","name":"com.google.android.gms.chimera.GmsApiService"},"callSite":"bgrj#run:78"}}

Media-route discovery

The second is media-route discovery. It was worth mentioning because the discovery query returns both stock and ReVanced matches, which is exactly the kind of output that could hide a missed rename if the app later chose the wrong target. In the exercised path here, that is not what happened: discovery is dual at query time, but the later bind is still ReVanced GmsCore:

{"package":"app.revanced.android.youtube","label":"rename-sink-pm-query-intent-services","payload":{"intent":{"action":"android.media.MediaRouteProviderService"},"matches":[{"package":"com.google.android.gms","name":"com.google.android.gms.cast.media.CastMediaRoute2ProviderService_Persistent"},{"package":"app.revanced.android.gms","name":"com.google.android.gms.cast.media.CastMediaRouteProviderService"}],"callSite":"dfy#b:93"}}
{"package":"app.revanced.android.youtube","label":"rename-sink-intent-set-component","payload":{"requestedComponent":"app.revanced.android.gms/com.google.android.gms.cast.media.CastMediaRouteProviderService","emittedIntent":{"action":"android.media.MediaRouteProviderService","component":"app.revanced.android.gms/com.google.android.gms.cast.media.CastMediaRouteProviderService"},"callSite":"dfw#f:14"}}

Missing-endpoint cases

Separately from those two live runtime exceptions, there are also a few missing-endpoint cases ReVanced GmsCore does not currently expose the corresponding endpoint/module.

• wallet checkout: YouTube yea / YT Music aevk go through wallet builders qbp / qbw, which package com.google.android.gms.wallet.ACTION_CHECKOUT to app.revanced.android.gms; ReVanced GmsCore does not expose a checkout activity, while stock resolves com.google.android.gms/.wallet.ow.ChooseAccountShimActivity
• family create/invite: YouTube phi / YT Music suw construct rewritten ComponentNames for com.google.android.gms.family.v2.create.FamilyCreationActivity and com.google.android.gms.family.v2.invites.SendInvitationsActivity; those activities are absent in ReVanced GmsCore and present in stock
• cast settings: YouTube aets->onClick(...) and YT Music amxp->onClick(...) target app.revanced.android.gms/com.google.android.gms.cast.settings.CastSettingsActivity; that activity is absent in ReVanced GmsCore and present in stock
• vision fallback: YouTube qbi / YT Music ukf fall back to an explicit broadcast to app.revanced.android.gms/com.google.android.gms.vision.DependencyBroadcastReceiverProxy with action com.google.android.gms.vision.DEPENDENCY; that receiver is absent in ReVanced GmsCore and present in stock

Notifications

Lastly, for notifications:

• TOKEN_REQUEST / REGISTER look covered.
• In the latest raw runtime capture, both apps package those flows to app.revanced.android.gms, not com.google.android.gms.
• Receiver resolution landing on ReVanced GmsCore’s org.microg.gms.gcm.PushRegisterReceiver.

YouTube:

aoxi#b:35 TOKEN_REQUEST -> app.revanced.android.gms
aoxi#b:38 resolves PushRegisterReceiver in ReVanced GmsCore
oyl#e:56 com.google.android.c2dm.intent.REGISTER -> app.revanced.android.gms

YT Music:

bcuq#b:35 TOKEN_REQUEST -> app.revanced.android.gms
bcuq#b:38 resolves PushRegisterReceiver in ReVanced GmsCore
sel#e:56 REGISTER -> app.revanced.android.gms

The only currently stock pointing notification related call site is ACTION_SCHEDULE. ACTION_SCHEDULE is for GcmNetworkManager, which is an old background job scheduler API.

new Intent(ACTION_SCHEDULE).setPackage(GMS_PACKAGE_NAME).

My Analysis found no broadcast receiver in app.revanced.android.gms that can handle com.google.android.gms.gcm.ACTION_SCHEDULE.

I do not see any references to ACTION_SCHEDULE in YouTube or YouTube Music apk, so I do not think this finding has any relevance.

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.

[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