reuse module context in mapbox

[zappybiby]

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.

[mar-v-in]

The API between play-services-maps and play-services-maps-core is defined by Google, not us. If we change it, things are going to break.

• The interface com.google.android.gms.maps.internal.ICreator is from Google.
• The requirement of a no-argument constructor (specifically without a Context argument) is from Google.

This change will break things in two ways:

• Apps that use the play-services-maps library from Google (that is most apps displaying a map) will not be able to do so anymore when run on a device with microG (they will try to invoke the no-argument constructor on com.google.android.gms.maps.internal.CreatorImpl which no longer exists)
• Apps that use the play-services-maps library from microG (probably very few) will not be able to do so anymore when run on a device with original Google Play Services (they will try to invoke the constructor with Context argument, which doesn't exist in Play Services).

[zappybiby]

The API between play-services-maps and play-services-maps-core is defined by Google, not us. If we change it, things are going to break.

• The interface com.google.android.gms.maps.internal.ICreator is from Google.
• The requirement of a no-argument constructor (specifically without a Context argument) is from Google.

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.

[mar-v-in]

I think you are tackling this from the wrong angle. Instead, figure out what inside play-services-maps-core-mapbox currently requires access to the context of the gms package and either eliminate those needs or use other techniques to fulfill those needs. As we do have access to the class loader that loads play-services-maps-core-mapbox, this should already give us almost all we need.