fix: Target own package for side by side installations of Google Services and MicroG GmsCore by zappybiby · Pull Request #308 · ReVanced/GmsCore

zappybiby · 2026-03-08T04:29:42Z

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 · 2026-03-08T12:44:10Z

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 · 2026-03-09T12:47:23Z

Was this supposed to be closed?

jenno-verdonck · 2026-03-12T16:29:37Z

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 · 2026-03-12T16:31:30Z

In the opening message of this PR you can add

"Closes #number" as many times as you want

oSumAtrIX · 2026-03-12T16:32:55Z

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

jenno-verdonck · 2026-03-12T16:34:56Z

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 · 2026-03-15T03:27:12Z

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 · 2026-03-16T20:58:54Z

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.

nsklei · 2026-05-29T18:16:04Z

Thanks for the detailed answer, that clears it up.

The one thing I'd gently flag: the narrower GmsProviderResolver shape you described looks like it maps onto the still-open play-services-base half of microg#3367 — and since it'd help microG's own user flavor too, it might be upstreamable rather than fork-only. Just noting it in case it's useful down the line.

oSumAtrIX · 2026-05-29T19:18:49Z

That make sense. We can also fasttrack any changes from upstream PRs if they look more or well good. Its always good to have the veto of the maintainer about it though.

zappybiby · 2026-05-30T06:19:44Z

Current PR head (a15d934) now includes the latest Mapbox changes introduced in microG PR 3401. With this change, we no longer need Gradle build flavoring for Mapbox.

My tests for side-by-side GMS look good. I tested ReVanced CoreGms (a15d934) installed side by side with stock GMS 25.26.35 / 252635038 on an API 36 emulator.

Mapbox maps loaded through ReVanced CoreGms in both full and lite modes, rendered tiles, and opened marker info windows without crashes or resource/native-loading errors.
I also checked that the changes did not affect ordinary stock Google Maps callers: a normal Google Maps SDK app still loaded Google’s maps module from stock com.google.android.gms and reached onMapReady
The only part of this change that impacts more than just maps is DynamiteContext.getResources()/getAssets(). DynamiteContext is used when loading other Dynamite modules so it was a regression risk I looked into. I checked each Dynamite module (ads, cronet, providerinstaller, vision/ML kit...) and didn’t find any regressions with side by side install.

Test build: https://github.com/zappybiby/GmsCore/releases/tag/gmscore-pkg-rename-test-57-1

oSumAtrIX · 2026-06-01T12:18:26Z

Current PR head (a15d934) now includes the latest Mapbox changes introduced in microG PR 3401. With this change, we no longer need Gradle build flavoring for Mapbox.

Great. Can you rebase the code in the following way so the changes are visible:

Upstream GmsCore -> Your PR 3401 -> Any additional changes from this PR.

This way I can track what changes only exist in our fork and which ones exist (or will exist) in gmscore. Once PR 3401 is merged upstream we can sync any changes here by rebasing gmscore again.

I also checked that the changes did not affect ordinary stock Google Maps callers: a normal Google Maps SDK app still loaded Google’s maps module from stock com.google.android.gms and reached onMapReady

Is this intended behaviour? I was under the impression that apps using gmscore should also use its api and not the official gms apis

initV2() receives the maps module Resources, we store those, and MapContext returns them from getResources(), getAssets(), and getTheme(). Instead of rebuilding MapContext from a hardcoded GMS package context, we now use the resources provided by the maps dynamite module.

Prevents InflateException that could happen when GmsCore inflates maps_default_bubble_layout.xml when MapContext.getTheme() returned an empty theme. MapContext now gives a usable theme copied from the caller context

Stop using canonical package identity at self-targeting call sites that actually mean the installed GmsCore APK, while keeping the Maps change narrowly scoped to the Mapbox backend path. For Maps, keep the loader and other backends unchanged and only stop the Mapbox backend from reconstructing a canonical com.google.android.gms context. Resolve the package context from the serving runtime application id instead, and keep MultiArchLoader version/APK lookup aligned with that Mapbox context. Also drop the transient self-package helpers and use direct package resolution at each call site: BuildConfig.APPLICATION_ID in play-services-core, and inline self-package context resolution in library modules that do not have the app BuildConfig.

The package-rename diagnostics showed that the Vision/MLKit face detector creators were still using the canonical package context even though the actual detector helper and model asset are owned by the serving self APK. Apply that ownership decision to all four remaining Vision/MLKit face detector creators by resolving the installed self package directly from the incoming context instead of going through a shared helper.

Runtime checks showed these LoginActivity package targets are self-owned flows. The signup handoff already resolved to LoginActivity's internal MainActivity component; the remaining issue was that the package field still pointed at canonical com.google.android.gms instead of the serving GmsCore app. The post-login ACTION_GCM_REGISTER_ACCOUNT broadcast also needs to target the receiver in the serving GmsCore app, not a separate canonical GMS package. Because LoginActivity is in the app module, BuildConfig.APPLICATION_ID is the simplest self-package constant for both call sites.

In my testing, we don't need setpackage here at all, its redudant and removing it allows us to avoid the need for flavoring (compile time) or switching it to runtime compilation. In my diagnostic probe tool, I tested three scenarios: ``` component-only = keep the explicit component, but do not call setPackage(...) component + self package = keep the same explicit component, and set the package to the renamed/local package (BuildConfig.APPLICATION_ID) component + canonical com.google.android.gms package = keep the same explicit component, but set the package field to the canonical Google package instead ``` all three intent variants still resolved to the same UserConsentPromptActivity. This is because the component itself is doing the routing work. ``` 03-12 13:13:54.342 I PkgRenameDiag: Consent prompt component-only -> action=null | package=null | component=app.revanced.android.gms/org.microg.gms.auth.phone.UserConsentPromptActivity | activities=1 match(es): app.revanced.android.gms/org.microg.gms.auth.phone.UserConsentPromptActivity 03-12 13:13:54.342 I PkgRenameDiag: Consent prompt component+self package -> action=null | package=app.revanced.android.gms | component=app.revanced.android.gms/org.microg.gms.auth.phone.UserConsentPromptActivity | activities=1 match(es): app.revanced.android.gms/org.microg.gms.auth.phone.UserConsentPromptActivity 03-12 13:13:54.342 I PkgRenameDiag: Consent prompt component+canonical package -> action=null | package=com.google.android.gms | component=app.revanced.android.gms/org.microg.gms.auth.phone.UserConsentPromptActivity | activities=1 match(es): app.revanced.android.gms/org.microg.gms.auth.phone.UserConsentPromptActivity ``` I also looked at how PackageManager resolves intents: ``` 1. SmsRetrieverCore creates an explicit intent for UserConsentPromptActivity. 2. It attaches the google.messenger extra. 3. It places that intent into SmsRetriever.EXTRA_CONSENT_INTENT. 4. That extra is returned to the client app as part of the SMS User Consent API result. 5. Later, the client app launches that consent intent. ``` So for an explicit local activity intent, the component itself is already doing the main routing work.

…arget

oSumAtrIX · 2026-06-17T22:01:57Z

Since the upstream PR is still stale, I would like to merge this PR as is. Does CI have to be adjusted to release the user flavor? If so, you can add the change into this PR

zappybiby changed the title ~~Fix self-targeting for repackaged GmsCore~~ self package targeting for Revanced coregms Mar 8, 2026

zappybiby changed the title ~~self package targeting for Revanced coregms~~ self package targeting for side by side install revanced coregms Mar 8, 2026