Signature conflicts with pre-installed GApps

[IzzySoft]

I still cannot get UnifiedNlp working on my LG P880 (stock Android 4.1.2 with GApps pre-installed of course). I've downloaded the UnifiedNlp.apk from here, and installed it on the device with adb install (see also: #34 ). Can open the app, configured two backends so far (the local GSM and openBmap backend). Still, the Xposed module claims it gets a location, but that it doesn't look like a UnifiedNlp one. Checking logcat revealed:

W/LocationManagerService(13440): org.microg.nlp implements com.android.location.service.GeocodeProvider but its signatures don't match those in com.google.android.location, ignoring

So what's wrong here, and how to fix? Note that uninstalling GApps or using a different ROM is no option for me currently.

Edit: I've tried working around that making UnifiedNlp a system app, but the very same error remains. So whatever it is, it seems to have protectioLevel "signature" (not "signatureOrSystem"), so this work-around doesn't work around.

[wish7code]

Just out of curiosity: what happens if you try LegacyNetworkLocation.apk?
see https://github.com/microg/android_packages_apps_UnifiedNlp/blob/HEAD/README.md#android-23---43-gingerbread--honeycomb--ice-cream-sandwich--jelly-bean

[IzzySoft]

@wish7code I don't even need to try that. Package name of that app is com.google.android.location – so I will get a signature mismatch, as a package with that name already is pre-installed (Google Network Location). The instruction you're referring to is for "Google-free devices" (let me know if I'm wrong here, but I cannot install two apps having the same package name).

But pointing to that: what might work is removing the Google Network Location app from the device, and replacing it by LegacyNetworkLocation.apk. I'm not sure about side-effects, so I'd rather avoid playing with that on my "main device" unless it's already proven to be "safe".

I guess a really safe approach would be having "mock locations" as option to switch to (as requested with #27). So if the "native method" cannot be used (as in my case), I'd at least have an alternative – though it might not work with all apps this way (see there). As @mar-v-in pointed out over there:

However I agree that using the mock API might become an interesting additional option.

Looks like this here is one of the places where it would be "interesting" 😇

[wish7code]

Disclaimer: Let me clarify, that I don't use the GAPPS setup, so I can't examine the actual behaviour further.

I alway thought that XPosed Framework is able to hook up existing system calls, thus redirecting location requests from com.google.android.location to the respective UnifiedNLP counterpart. Using this logic I thought there would actually be no need to replace the GAPPS apks but both could be installed side-by-side under their respective (different) namespaces.

I might be completely wrong with my assumptions, so it would be best if somebody from the developer team could shed some light..

[IzzySoft]

I alway thought that XPosed Framework is able to hook up existing system calls, thus redirecting location requests from com.google.android.location to the respective UnifiedNLP counterpart. Using this logic I thought there would actually be no need to replace the GAPPS apks but both could be installed side-by-side under their respective (different) namespaces.

That were my thoughts as well. But all the corresponding Xposed module lets me do is run a check, where it fails. As far as I knew, shouldn't XposedUnifiedNlp take care for exactly that part of integration I'm failing here? So should I rather open an issue with them in this case? There is already a related issue open (I've hooked into that). According to the discussion there, I did everything allright. Quoting @Rawi01:

If you want to use UnifiedNlp with this module you have to download and simply install the UnifiedNlp.apk from the UnifiedNlp release page. It only works with this apk. It is not necessary to copy it to some speciall directory or set permissions.

The installation instructions from the modules page on xposed repo have been followed, of course.

PS: My apologies for the mess, reporting this issue with all involved projects (UnifiedNlp front-end here, the back-ends (hi @wish7code and @n76 ), and the xposed module (Rawi)), but for an end-user it's quite tricky to figure where it really belongs to. Today, I'm pretty sure the backends are not responsible – but it's not yet clear to me whether it's UnifiedNlp or the Xposed module not working correctly on my device.

[n76]

I too am running without gapps so don't have any direct experience, but I see that on F-Droid there is a download for phones with gapps. I suspect that it uses a something other than com.google.android.location and so it can be loaded. I assume that once loaded, xposed can be used to wire up the calls. Has that been tried?

The write up mentions non-stock firmware so perhaps this won't work on a stock setup but it seems like there should be little difference between stock and another ROM with gapps.

[IzzySoft]

@n76 Thanks! That's what I've tried first (if we're both referring to the UnifiedNlp package available from there). Error messages fluctuated with that: either services not working, or no UnifiedNlp source. On suggestion of Rawi (see above) I've switched to the UnifiedNlp.apk from here. Now I've got a consistent error (no UnifiedNlp source). See above.

[wish7code]

Step-by-step install instruction for both GAPP and GAPPS-free devices is definitely on the TODO list..

Could you upload a complete logcat in the meantime, so we can trace down, which of the components isn't working? You might also try to activate debug logging in the openbmap UnifiedNLP settings, so logcats become more verbose.

[IzzySoft]

@wish7code I of course can provide a full logcat, but I'd prefer not to place that "in public space". If you could name a more closed place to deposit it (mail/upload? Find my contact info via my profile page here), I'm happily complying.

The core issue seems to be this one:

V/LocationManagerService(13440): com.google.android.location implements com.android.location.service.GeocodeProvider with version 1
V/LocationManagerService(13440): com.google.android.gms implements com.android.location.service.GeocodeProvider with version 0
org.microg.nlp implements com.android.location.service.GeocodeProvider but its signatures don't match those in com.google.android.location, ignoring

com.google.android.location implements com.android.location.service.NetworkLocationProvider with version 1

As you can see: µg tries to offer a GeocodeProvider (though I've no backend set up for that), but is ignored due to signature mismatch. Strange thing is the log doesn't show any hint on its NetworkLocationProvider: 2 backends configured here, which are bound:

D/NlpLocationBackendHelper(23816): Binding to: Intent { act=org.microg.nlp.LOCATION_BACKEND pkg=org.fitchfamily.android.gsmlocation cmp=org.fitchfamily.android.gsmlocation/.GSMService }
D/NlpLocationBackendHelper(23816): Binding to: Intent { act=org.microg.nlp.LOCATION_BACKEND pkg=org.openbmap.unifiedNlp cmp=org.openbmap.unifiedNlp/.services.OpenbmapNlpService }
I/ActivityManager(21057): Start proc org.fitchfamily.android.gsmlocation for service org.fitchfamily.android.gsmlocation/.GSMService: pid=23838 uid=10130 gids={3003, 1015, 1028}
I/ActivityManager(21057): Start proc org.openbmap.unifiedNlp for service org.openbmap.unifiedNlp/.services.OpenbmapNlpService: pid=23848 uid=10145 gids={3003, 1015, 1028}

Taking a closer look, LocationService was started for µg – as shortly after the last msg from above comes a stack trace starting with

Service org.microg.nlp.location.LocationServiceV1 has leaked ServiceConnection org.microg.nlp.location.BackendHelper@42ef8100 that was originally bound here
android.app.ServiceConnectionLeaked: Service org.microg.nlp.location.LocationServiceV1 has leaked ServiceConnection org.microg.nlp.location.BackendHelper@42ef8100 that was originally bound here
    at android.app.LoadedApk$ServiceDispatcher.<init>(LoadedApk.java:971)
    at android.app.LoadedApk.getServiceDispatcher(LoadedApk.java:865)
    at android.app.ContextImpl.bindService(ContextImpl.java:1191)
    at android.app.ContextImpl.bindService(ContextImpl.java:1183)
    at android.content.ContextWrapper.bindService(ContextWrapper.java:394)
    at org.microg.nlp.AbstractBackendHelper.bind(AbstractBackendHelper.java:78)
    at org.microg.nlp.location.BackendFuser.bind(BackendFuser.java:76)
    at org.microg.nlp.location.ThreadHelper.enable(ThreadHelper.java:70)
    at org.microg.nlp.location.ThreadHelper.reload(ThreadHelper.java:43)
    at org.microg.nlp.location.LocationProviderV1.reload(LocationProviderV1.java:54)
    at org.microg.nlp.location.AbstractLocationService.onHandleIntent(AbstractLocationService.java:68)
    at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:65)
    at android.os.Handler.dispatchMessage(Handler.java:99)
    at android.os.Looper.loop(Looper.java:137)
    at android.os.HandlerThread.run(HandlerThread.java:60)
Service org.microg.nlp.location.LocationServiceV1 has leaked ServiceConnection org.microg.nlp.location.BackendHelper@42ef8290 that was originally bound here
android.app.ServiceConnectionLeaked: Service org.microg.nlp.location.LocationServiceV1 has leaked ServiceConnection org.microg.nlp.location.BackendHelper@42ef8290 that was originally bound here
    at android.app.LoadedApk$ServiceDispatcher.<init>(LoadedApk.java:971)
    …

(second stack is basically the same as the first)

For at least a minute after that (until my logcat stops), no more mention of org.microg. I just see your OpenBMap being initialized (trying to load its data file).

[mar-v-in]

@timofonic are you referring to this specific issue, probably only affecting an unsupported setup? On devices without GAPPS, installation is already straight-forward and on devices with GAPPS and Android 4.3+ its possible using a third-party project.

[wish7code]

Unfortunately I think @timofonic is reffering to the GAPPS case..

Have a look at Rawi01/XposedUnifiedNlp#2 too (Warning bit lenghty): nobody ever confirmed a running GAPPS installation over there..

The problem seems unrelated to the actual location provider, but somehow framework specific..

Without GAPPS everythings works fine..