reuse module context in mapbox#3401
Conversation
zappybiby
changed the title
|
The API between
This change will break things in two ways:
|
Understood, I will review options. That was part of my pre f867ebd change, but you bring up some other points I need to consider as well. I will look into this, thank you for your feedback. |
|
I think you are tackling this from the wrong angle. Instead, figure out what inside |
|
|
||
| override fun getClassLoader(): ClassLoader { | ||
| return MapContext::class.java.classLoader!! | ||
| return getModuleClassLoader() |
There was a problem hiding this comment.
Aren't those class loaders effectively the same?
| inp.close() | ||
| out.close() | ||
| private fun findLibrary(name: String): String? { | ||
| return (moduleClassLoader as? BaseDexClassLoader)?.findLibrary(name) |
There was a problem hiding this comment.
Have you verified this in a multi-arch environment?
That is, when the app using the play-services-maps library is build for a different architecture than the GMS package is installed at. The easiest way to test is to force install any app using maps as armeabi-v7a on a device that is arm64-v8a (most devices today). You can do this using adb install --abi armeabi-v7a target.apk
2 participants
This PR makes the Mapbox backend reuse the maps/module Context already selected by MapsContextLoader, instead of reconstructing a new GmsCore-side base context from the embedding app Context and a package string. MultiArchLoader now resolves package/version/APK metadata from the wrapped maps context instead of hardcoding Constants.GMS_PACKAGE_NAME.
Upstream already uses MapsContextLoader to choose the maps/module context for initialization, but the Mapbox runtime path still rebuilds its own base context in MapContext and still hardcodes package identity in MultiArchLoader. The problem with that shape was discussed earlier in the Mapbox thread on ReVanced/GmsCore#308, and was also discussed in microg/GmsCore#3367.