Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Consider adding ability to also load GPS providers from non /system/app for Android N #3
There is Unified NLP as a part of MicroG. Since Android N, Unified NLP is not loaded because Android OS no longer loads GPS providers from non /system/app folder. @danielegobbetti has created and @mar-v-in has accepted a patch changing android_frameworks_base in an attempt to address this. Can you please also add it?
commit that causes issue:
I tried to start the process of creating a patch by myself, however I had issues running build-patch with a sample patch of yours. I hope it's fine if I post the log here instead of creating a new issue.
It would be great if you can give me a hint in the right direction. I will continue to try and create the patch by myself. Thanks for the quick answer.
This seems to be a dex2jar issue with Android N, see pxb1988/dex2jar#93.
so patches reference symbols from the system. for that reason, the system dex files are passed through dex2jar and the result is fed to the java compiler during patch building. (only the method prototypes are important here, the actual code is ignored.)
this dedexing process (dex2jar) is done just-it-time during patch building. but because it's slow, it can also be done ahead-of-time. (there's a haystack script for that.) when AOT dedexing is done, a
well... unfortunately dex2jar cannot handle Android 7+: the dex version changed (035 to 037) and dex2jar seems to be abandonware now. the solution is to manually dedex AOT the Android N fileset to a
how to rewrite the dex files? well, dexpatcher to the rescue! :)
the important thing is forcing API 23, aka Android M. the outputted dex will have some stuff only allowed in dex v037 from the source and thus will be malformed. dex2jar will fail to understand parts of it, but it will translate most of it which is more than enough.
The AOT dedex process was successful. However after placing the
The command at this point is:
it looks like
it seems p.requestedPermissions is no longer accessible on Android 7.1!
btw, watch your api level!
Strange, I applied both prebuilt core and hook patches on LineageOS 7.1.1 and the signature spoofing works fine. My assumption is that I did something wrong during the build process.
I will try to figure out what might be wrong and post my results, if any.
Thank you for your time, you already spent too much of it helping me :)
well, the Log class will be found and linked at runtime, even if not in the fileset, so no issue there.
but the access to the permission list will probably cause a verification error.
why didn't dexpatcher catch that?
well, for historical reasons. dxp was not made to patch several different versions of a bytecode with the same binary patch. thus, part of the type checking is expected to be done by the compiler.
this is why the symbols are imported: so patch code can use all of them. the compiler checks.
alternatively, instead of importing you can define the symbols you use like this:
dxp then ignores a. it still doesn't check anything at patch time, but you no longer need symbol a imported.
if you want to check for the existence of 'a' at patch time you can do this instead:
so now patch fails to apply if 'a' doesn't exist. but... this is not good because dxp will replace the definition of a. if a has annotations, they are deleted. if a changed to protected in a later rev of the app, it will be made private again and the app will fail (dxp will warn about this visibility change though).
what is needed is a new tag:
that verifies at patch time that a is accessible but doesn't change it. accessible at least with private access (but actual 'a' could be less restrictive). and at least in this class (but 'a' could be defined in a supper class).
i have the intention of improving dxp to be able to patch different target code with the same binary patch. it requires 3 features, one is DexCheck, it's all thought out. unfortunately i don't have the time to implement now.
in short, dxp was designed to be used like this:
the combo javac+dxp does a really good job of signaling where changes are needed. (this is your case btw!) but skipping javac can let errors creep though patch time to run time.
dxp could do a better job in the skip-javac case and i intend to fix that, but only if the patch programmer declares what to check, which means more work. this extra work is essentially declaring all of the used source symbols yourself, and forgo the convenience of having them auto-imported for you.
alternatively you can check for verification errors on an actual device or emulator after patching.
I made some progress. The build process was successful after I downgraded JDK to 7 and build-tools to 23.0.3. I'm not entirely sure what went wrong during the compilation, but now it works.
Here is my self-made patch. Testing it showed that microG passes all self-checks and that I can configure and use an external provider while having GmsCore installed as a user-app.
congrats, you made it!!!
google wants to break away from javac and dx (load of crap if you ask me, they should maintain dx all the same) with a direct to dex compiler called jack. AFAIK, only jack supports java 8 features, which led me tu suppose dx wasn't updated for N. this means: 1) dx shouldn't understand java 8 bytecode (but haystack compiles with
i don't know why you needed to downgrade to java 7. but of course you know that build-tools later than 23 require a java 8 JRE to run, so the build-tools part is explained at least.
regarding your code, i've looked at it; looks handsome! :) no, really: i'd need to look at android source and think a bit to have an opinion. at first glance it looks ok. if it works, just relax, i'm sure everything's fine :)