Related
This thread is intended for module developers. Make sure you follow it (i.e. subscribe) to be informed about any API changes and additions.
I will announce changes before the release if they might make existing modules incompatible.
If you're interested in more details, you can follow the GitHub repositories:
https://github.com/rovo89/XposedBridge/commits/master
https://github.com/rovo89/Xposed/commits/master
https://github.com/rovo89/XposedInstaller/commits/master
Here you can also download the API jar file that you need to reference from your project. Make sure you read the development tutorial to understand how it works. Especially make sure that the classes are not included in your APK, but only referenced.
Note that I will only post the latest API version here to drive the adoption of updates.
This is on pretty short notice, but I have removed the method AndroidAppHelper.getActivityThread_mPackages(): https://github.com/rovo89/XposedBridge/commit/892ba9195da5516dd79f175ac95be2b313c8f8ca
It had been used internally some time ago. I scanned the modules which have been uploaded to the repository and didn't find any which uses this method.
Apart from that, I'm planning to make Xposed for command line tools (e.g. am and pm), implemented via IXposedHookCmdInit/initCmdApp(), optional and disabled by default. It is currently used only by App Settings (but unnecessary and therefore removed in the next version) and NFC LockScreenOff Enabler (I will contact the authors).
As the low usage shows, this feature is hardly needed, so there is no need to load Xposed every time such an app is started. It also avoids the additional log entries, which could be confusing for some users. Actually it is so rarely used that I might not even offer a setting in the UI for it, just a command file for experts. I will not remove it completely as it's useful for low-level framework development (I can quickly test whether my native code changes work without having to reboot).
Xposed 2.6 will bring support for replacing dimensions defined in code (instead of merely forwarding to your own resources): https://github.com/rovo89/XposedBridge/commit/48227c5b0a7ae3e3f81d76ad3bbaf017dc95614c
The new API will be published once that version is out. Until then, it would still be possible to make adjustments of the API. If you think anything should be changed, please let me know as soon as possible.
Ok devs, 2.6 beta1 is out, and so is the new API (version 52).
Here are the relevant XposedBridge changes to version 42 (internal changes/optimizations are not listed):
The resources API can be disabled via a debug setting in the UI. If your module implements IXposedHookInitPackageResources, it will not be loaded because it likely depends on this API. You can also check (but don't change) the status via XposedBridge.disableResources if you use the API in other ways.
Hooking abstract methods (including methods declared in interfaces) will throw an IllegalArgumentException now. The callback was never executed for them anyway. This change avoids debugging effort on your side because you will notice it immediately.
It's now possible to create a DimensionReplacement object and use it to replace "dimen" resources with values calculated at runtime. Previously it was only possible to forward such resources to your module. Example in the commit message: https://github.com/rovo89/XposedBridge/commit/48227c5b0a7ae3e3f81d76ad3bbaf017dc95614c
Removed AndroidAppHelper.createResourcesKey() methods and AndroidAppHelper.getActivityThread_mPackages() - weren't used by any module in the repository.
Fix delayed configuration update for forwarded resources. That's only of interest if your replacement resource contains variants for different qualifiers that might change at runtime (e.g. drawable-land/drawable-port). https://github.com/rovo89/XposedBridge/commit/1c81954e295cdda191cf8a1cf33d21d7c5ea334d
New findConstructorExact() / findAndHookConstructor() methods, similar to the one for methods: https://github.com/rovo89/XposedBridge/commit/a233fa0bc9499eadbe2efc0b49fc3f4a46264614
IXposedHookCmdInit is deprecated now, initCmdApps() won't be called anymore unless an undocumented file has been created. Only two modules used it, both got rid of it without any loss of functionality. This also averts situations like this where logging for tools like am/pm masks errors for Zygote.
Due to some internal changes, the constructor of XResources isn't called anymore (a good thing!), which breaks some features in App Settings (a not so good thing). That's because it relied on updateConfiguration() being called twice, so it could retrieve the package name in the second call and do its changes. A fix for that is on the way, using a new method (getPackageNameDuringConstruction()) added in the last minute, which returns the package name for a very specific situation. You will probably not need it.
Apart from that, there is now an official way to open a certain section in the installer:
Code:
Intent intent = new Intent("de.robv.android.xposed.installer.OPEN_SECTION");
intent.setPackage("de.robv.android.xposed.installer");
intent.putExtra("section", "modules");
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
Possible values for "section" are currently: install, modules, download, logs, settings, about.
You can for example use this to send the user to the module section if you find out that your module isn't active yet. The best way to find out is something like that:
Code:
// in your Activity, call it to find out the activation status
private static boolean isModuleActive() {
return false;
}
// in handleLoadPackage()
if (lpparam.packageName.equals("your.package.name")) {
// don't use YourActivity.class here
findAndHookMethod("your.package.name.YourActivity", lpparam.classLoader,
"isModuleActive", XC_MethodReplacement.returnConstant(true));
}
Do NOT try to read - or even change - the internal files of the Xposed Installer to get this information or force your module to be activated. Not only can this break anytime, it will also be bad user experience and a security threat if your module is active without explicit selection in the app. You will probably see your app removed from the repository if you break the rules.
If you have any questions or remarks, please let me know. And if you haven't subscribed to this thread yet, make sure to do so now in order to stay up-to-date with new developments.
IllegalAccessException if you use reflection yourself
One additional change in the new version was the removal of a hack that nuked some access checks in Dalvik by making them return "true" every time. After some of the other internal changes, some of the processing that required this hack was no longer necessary. With some more refactoring, I was finally able get rid of this hack. That's good because it caused crashes on some badly built ROMs (incorrect smali hacks), but also in some rare cases in normal apps: https://github.com/rovo89/XposedInstaller/issues/89
However, some modules relied on the deactivation of these access checks. Now they get IllegalAccessExceptions when trying to access e.g. private fields or methods.
Does this mean that Xposed used to cause security issues on the whole system? After all, it meant that any app could access things that they couldn't access otherwise, right? So it destroyed Java's security system!
The answer is: No, that wasn't a security issue! The Java access check system is actually optional. When you get a field/method/class via reflection, you just need to call setAccessible(true) on it to disable the access check. Example in XPrivacy: https://github.com/M66B/XPrivacy/co...430849f#diff-a350382a0ec1158ad9769d07bd754a63
Note that this is only needed if you use reflection yourself, e.g. with getDeclaredMethod() / getDeclaredField(). The methods in XposedHelpers call setAccessible() on the result before returning it to you.
2.6 final comes with XposedBridge v54.
The only changes relevant for developers are the addition of XSharedPreferences.hasFileChanged() and XSharedPreferences.getFile(), and a fix for replaced animation/xml resources. If you're using the latter and want to avoid that someone with the buggy version 2.6 beta1 runs into issues with your module, consider bumping the minimum required Xposed version to 54.
In Lollipop, there were a few architectural changes in Android. I hinted one of them in the Q&A:
The most significant one is that the code for system services has been moved to a separate file. For most of the affected modules, this can be solved by a little refactoring (moving code to a different place).
Click to expand...
Click to collapse
In detail, this means: If you want to hook a system service like PackageManagerService, you can no longer do that in initZygote(). Instead, move your code to handleLoadPackage() and check for dummy package "android". Make sure you use lpparam.classLoaders when looking for classes and hooking methods. This way has worked in older Android versions as well, so you don't lose backwards-compatiblity.
I'll just repeat here what I wrote in the official announcement thread, as it'll be helpful for all module developers:
rovo89 said:
After a long time with mainly bug fixes, version 81 focuses on improvements for developers:
There is a proper API now. Previously, I basically published the sources of XposedBridge.jar, which included many internal classes/methods that modules shouldn't use. Hiding them makes it easier to find the correct methods to use and also makes it easier for me to change implementation details.
The API is published on Bintray/JCenter, so it's easy to use, especially with Gradle/Android Studio. Full explanations here: https://github.com/rovo89/XposedBridge/wiki/Using-the-Xposed-Framework-API
100% of the API are documented with Javadoc now: http://api.xposed.info/
Apart from that, downloads have moved to http://dl-xda.xposed.info/framework/ and are GPG-signed now. You can verify them against this key (fingerprint: 0DC8 2B3E B1C4 6D48 33B4 C434 E82F 0871 7235 F333). That's actually the master key, the files are signed with subkey 852109AA.
There are no real changes for end-users in this release, nevertheless I would recommend that at least developers test their modules with it.
Click to expand...
Click to collapse
First of all, I don't have a Nexus 5, but I have a Galaxy Tab Pro 8.4 with the same SoC and I think the N5 has the same issues with the new SELinux policy.
I'm having issues building Android 7.0 because of this SELinux rule: allow mediaserver system_file:file execmod;
Which is also needed on the N5.
Code:
# Grant access to Qualcomm MSM Interface (QMI) audio sockets to mediaserver
qmux_socket(mediaserver)
unix_socket_send(mediaserver, camera, camera)
unix_socket_send(mediaserver, mpdecision, mpdecision)
# Permit mediaserver to create sockets with no specific SELinux class.
# TODO: Investigate the specific type of socket.
allow mediaserver self:socket create_socket_perms;
[B]# For text relocations in /system/vendor/lib/libmmjpeg.so
allow mediaserver system_file:file execmod;[/B]
https://github.com/CyanogenMod/andr.../blob/staging/cm-14.0/sepolicy/mediaserver.te
When I try to build with it uncommented I get a neverallow error. The same rule is applied to other modules, so if I comment it out I can successfully build and boot, but many things don't work.
I don't know much about SELinux and I haven't found a way to bypass this rule without disabling SELinux. Maybe in this subforum someone can help me since there are already Nougat ROMs for the N5.
Thanks.
The sepolicy in bold was for text relocation as it commented. Bionic linker in Nougat has disallowed this feature, that's, all libraries must contain no text relocation section. So it was officially deprecated even in CM codes.
If you just want to bypass the build error, comment out disallow policy in externel/sepolicy to fix up the conflicts. But if you're wondering to get libmmjpeg.so working, go allow text relocation in bionic or find out the proper prebuilts (see bullhead).
BTW, This library is just for jpeg deconding/encoding. And of course it's not related to 'many things'.
Hey guys,
As some of you may know, Android Oreo gave us the choice to use Google's Skia graphics engine (still using an OpenGL backend) to render the UI. It's hidden inside Developer options, and it doesn't stick after reboots. This little Magisk module aims to solve that, by systemless-ly patching /system/build.prop - adding the line debug.hwui.renderer=skiagl.
Those of you who have used Android Pie have probably (or certainly) noticed the UI looked different between Oreo and Pie, as far as font/text rendering is concerned. (I personally think text looks better on Pie.) That's due to SkiaGL being chosen as the default renderer on Pie (XDA's own Mishaal Rahman wrote about that, read his article here).
This module should work on any Android device running Oreo or higher. As I wrote above, Pie already uses SkiaGL by default so there's no need to flash the module if your device runs said version - unless you use a custom ROM and its developers, for whatever reason, chose to use the Oreo default renderer (HWUI / OpenGL) instead.
The attached screenshots show the difference between SkiaGL and HWUI.
Please be aware that this stuff is still experimental. At least for me, it partially broke WhatsApp's camera viewfinder (though captured pictures/videos are still fine) and caused Instagram force closes whilst browsing stories. It's quite perceptible that SkiaGL isn't 100% stable on Oreo yet.
If you still wanna flash this, just download the attached ZIP and install the module either via Magisk Manager or via TWRP. At least Magisk 18.1 is required.
Unstable, not compatible with O Having problems with the keyboard
setting the option really makes a difference, much smoother and much less ui stutters ...
would it be possible to port the newest skia files from 9.0 to 8.0/8.1 ??
edit: at least in firefox i see a dramatic speed up of graphics , the rest of the system could be just placebo XDD
edit2: your build prop doesnt seem to work for me .. galaxy s7 oreo 8.0
We are now working on the new Xposed API, which allows modules to get / set scope, to get framework info, and to store configs across apps without the embarrassing New-XSharedPreferences interface. The API library will be released to GitHub/libxposed and maven central after it is ready.
Now we are considering removal of resources hook in the incoming new API, so we need to know whether it is still needed or unreplaceable for some modules.
About why we want to remove this API: Resources hook is very hard to maintain and is even not fully supported now under some frameworks (e.g. Taichi). So even if we keep it, it will be maintain-only.
Old modules can still use this feature. We are just considering remove it in the new API.
You can vote at the LSPosed Telegram group or write your opinion here. Also we are glad to hear your suggestions about the new API.
@AndroidX @siavash79 @Dark_Eyes_ @firefds @David B. @Quinny899 @wanam
Just mentioning you guys since you're all active here on XDA. Please see the first post.
Regards,
shadowstep
Senior Moderator
Dr-TSNG said:
We are now working on the new Xposed API, which allows modules to get / set scope, to get framework info, and to store configs across apps without the embarrassing New-XSharedPreferences interface. The API library will be released to GitHub/libxposed and maven central after it is ready.
Now we are considering removal of resources hook in the incoming new API, so we need to know whether it is still needed or unreplaceable for some modules.
About why we want to remove this API: Resources hook is very hard to maintain and is even not fully supported now under some frameworks (e.g. Taichi). So even if we keep it, it will be maintain-only.
Old modules can still use this feature. We are just considering remove it in the new API.
You can vote at the LSPosed Telegram group or write your opinion here. Also we are glad to hear your suggestions about the new API.
Click to expand...
Click to collapse
Thanks for getting opinions
1. Xshared preferences interface overhaul is good news since it was always unstable for me. I personally switched to remote preferences API for AOSPMods
2. When going to systemUI and framework, it's sometimes very difficult and complicated to change some variable values through Xposed, specially with R8 code optimizations which dramatically limit the points we can hook into code.
There are two workarounds I know of, being Xposed resource hooking that can be also dynamic in runtime, or overlays, which being static, still limit the way we can change resources dramatically.
So, I'd really suggest keeping it in the API
siavash79 said:
2. When going to systemUI and framework, it's sometimes very difficult and complicated to change some variable values through Xposed, specially with R8 code optimizations which dramatically limit the points we can hook into code.
Click to expand...
Click to collapse
For R8 code optimizations, we introduced a new API to parse dex file, which allows modules to find methods/fields more accurately.
Anyway if we finally decide to keep resources hook API, do you have any suggestions on keeping/adding/removing specific methods of it or refine it to a more modern interface?
Perfect news.
About resource hooking, few things to note are that: it can't differentiate between different resource files, for example normal values vs landscape or dark/light values. It would be great if there's a way to push different values to different resource files.
Also, there are more limitations when talking about special resources such as themes. As an example, in AOSPMods, one of the reasons it's a magisk module instead of being a normal APK is that overlay files have to be used in cases that need modification of theme resources and that can't be done via resource hooking.
I personally love to get a more complete/flexible resource hooking API, but I completely understand if that's too much to ask. So even keeping it as currently is would be good enough
Thank you @shadowstep for bringing this to my attention!
Dr-TSNG said:
We are now working on the new Xposed API, which allows modules to get / set scope, to get framework info, and to store configs across apps without the embarrassing New-XSharedPreferences interface. The API library will be released to GitHub/libxposed and maven central after it is ready.
Click to expand...
Click to collapse
That's wonderful news, although I do not quite understand what you have against the new XSharedPreferences interface. I use it in my modules, and I've never had any issues with it.
Dr-TSNG said:
Now we are considering removal of resources hook in the incoming new API, so we need to know whether it is still needed or unreplaceable for some modules.
About why we want to remove this API: Resources hook is very hard to maintain and is even not fully supported now under some frameworks (e.g. Taichi). So even if we keep it, it will be maintain-only.
Old modules can still use this feature. We are just considering remove it in the new API.
Click to expand...
Click to collapse
I am not currently using the resources hook in any of my modules, so removing it would not impact me, but even so, I'm not a fan of the suggestion to get rid of it completely. I think that at the very least, it should be kept as maintain-only. It is unfortunate that it does not work with Taichi, but given that Taichi isn't a true Xposed implementation, I'm not sure that it's worth worrying about.
This looks great, I've been waiting for it since the initial issue talking about it. Prefs are always a pain to handle, and while the "new" method worked, I always preferred to use a Content Provider, which was nerfed in Android 12.
Really like the idea of setting the scope, it would be beneficial to the Xposed part of DarQ, the only suggestion I have is to make sure it includes some sort of "am I enabled?" check - currently I use self hooks (literally the module hooking itself and changing a method returning false to true) to verify it's enabled, but it doesn't seem to be foolproof as people sometimes still complain it doesn't work.
Quinny899 said:
the only suggestion I have is to make sure it includes some sort of "am I enabled?" check
Click to expand...
Click to collapse
Of course does, and the module app can get more info about the the Xposed state like it's under which framework and which version, and whether it is rootless or not without self-hooking.
You can view the detail here.
@shadowstep Thanks for the head up.
Glad to see a new api to manage configs across apps, shared prefs has been always painful to handle even with the new-xshared prefs.
I would suggest having an api to get the version name of scope's package, I'm aware of some workarounds that help get the version name, but it's not a reliable solution on the latest Android versions, this information is needed for logging/debugging purposes.
@Dr-TSNG thanks and keep up the good work.
@Dr-TSNG Thanks for new api I was wating for this api from more then 1 year coz when I build my first module (Android Faker) its was really pain in ass coz of Xsharedpreference after some research I found better solution which was remote preference but Quinny899 mention in Github issue that its not work in android 11 so after that I move to new Xsharedpreference which was introduce by lsposed team and its working great but its still create issue in some devices so I think it will be a better solution if we get it soon and I am not sure about resources hook coz I don't use it before .
The problem with xshared preferences is that if the apk is a system app it won't work for some reason. Only works on user apps
siavash79 said:
The problem with xshared preferences is that if the apk is a system app it won't work for some reason. Only works on user apps
Click to expand...
Click to collapse
Interesting. I use XSharedPreferences in a System Framework hook and haven't had any issues with it.
David B. said:
Interesting. I use XSharedPreferences in a System Framework hook and haven't had any issues with it.
Click to expand...
Click to collapse
Is your module installed as APK or as magisk module?
Try mounting it to system through magisk and preferences will stop working
siavash79 said:
Is your module installed as APK or as magisk module?
Try mounting it to system through magisk and preferences will stop working
Click to expand...
Click to collapse
It's installed as an APK. I misunderstood what you had said earlier. I thought you meant that the hook doesn't work when you try to use it on system APKs. I didn't realize that you meant that it doesn't work when the module is itself a system APK.
siavash79Yeah I agree with this and in my testing if you set target sdk 23 its doesn't matter if its as system app or user its work without any issues but its not worth coz it have some other issues
Thank you for accepting the API invokeSpecial() !
Add invokeSpecial · libxposed/[email protected]
Fix #2
github.com
Implement invoke special and new instance special · LSPosed/[email protected]
LSPosed Framework. Contribute to LSPosed/LSPosed development by creating an account on GitHub.
github.com
Looking forward to the new API release.
Happy Chinese New Year!
I just want to see @M66B happy again
Somewhat unrelated, but is there any chance of seeing original Xprivacy return or compatibility? I think it's a lot better than Lua
lawrencee said:
Somewhat unrelated, but is there any chance of seeing original Xprivacy return or compatibility? I think it's a lot better than Lua
Click to expand...
Click to collapse
No. Xprivacy will never "return".
XPrivacyLua is the best ever
My project is to use an RPI4b running KonstaKANG ROM in my car as an dedicated AA device. My car have a nice dashboard but there is absolutely no guidance service. The primary goal would be to use an offline map service. I have tested AA and CarPlay with standard cellular over USB and they work.
My first tentative where done with AOSP13-20230130-KonstaKANG-rpi4.zip (not sure about the 6.1 kernel) and lineage-18.1-20220512-UNOFFICIAL-KonstaKANG-rpi4. While they worked well on the device with a keyboard/mouse/hdmi, I later realize my USB OTG cable was in fact just a charging cable. So of course results where negative.
My second attempt, using better cable, was a bit more interesting. But I was feeding only 2.1a to the OTG USB, so the RPI4b felt a bit sluggish because of underpowered I guess, I have some of those cables on order to give required power to the RPI4b but in the meantime I will just need to be patient. I tested using build lineage-19.1-20230313-UNOFFICIAL-KonstaKANG-rpi4.zip. I wanted to use flamegaps but it would say that "version 12 is not compatible with 12.0" so I did try mindTheGapps and NikGapps, both seem to had the same result. I used AA 8.9.630603 with and without the XLauncherUnlocked v2.0.1. My result where at some point I got error 22, which bring me to try this xda-guide. I installed logcat I was able to snap this from the log :
---
W InputDispatcher :
ActivityRecordInputSink comdp.logcatapp/.activities.FiltersActivity will not receive the gesture at 2051644...
I InputDispatcher
Droping event because there is no touchable window or gesture monitor at (90,99) in display 0.
---
I know it's not as useful as full log, but for now it's all I could salvage from this tentative and it's a information so I note it.
I intend to do a third test this week-end with this version AOSP13-20230412-KonstaKANG-rpi4. Hopefully I will have full log to report back.
Aside from XLauncherUnlocked, I want to also try this AA AIO Tweaker that seem quite interesting. It's option to enable widescreen remind me that I had some consideration about if dashboard and AA would not want to connect because running an RPI4b simulate an 1920x1080 screen that would be incompatible to a car dashboard ?
I'm sorry if that post seem a bit picked up for now but I hope the situation will clarify over time as I wont write from memory, wandering files and jolted notes.
- Should I use v8a or v7a when I download a build of AA from APKMirror ? I found recently that Magisk state I have v8a, is it trustable information ? Maybe it invalidate all my test done with v7a. But from what I read about it, I dont think it make much a difference, but could be someone know better ?
- What would be my best option to run AA and see logs ? Since I'm in a car maybe I can bring here a laptop to do ADB over USB would be faster than setting up Wi-Fi ADB ? I think at this point, collecting logs is the most important part of my investigation. But I'm not so sure how to do it efficiently. I would be thinking than to do something like that and collect the log while I try to connect AA to the dashboard would be the way to go.
Cheers
I could test the new configuration this week-end. Unfortunately I did not had much luck but now I have debug log and precise description of what I did. One thing I noted is that AOSP13 was very fast, so the sluggishness was not from the RPI4b lacking power it seems. I could debug with logcat using Android Studio via Wifi, it was awesome to see all this working. Here is the configuration I used :
aosp 13 : AOSP13-20230412-KonstaKANG-rpi4
mindthegapps : MindTheGapps-13.0.0-arm64-20230408_162909.zip
magisk : 25.2
busybox : com.jrummy.busybox.installer_6.8.2
systemizer : app_systemizer-v18.
androidAuto : 8.9.630604-release-89630604_minAPI26(arm64-v8a)(nodpi)
I think systemizer might not be necessary as the AA seem to be already system installed as there was no uninstall option in app info. I could copy the log as systemizer.log attached..
Reading the log it appear obvious to me that it's related to that error you keep on seeing whatever test I do. It would appear twice in the log as soon as I click on the "pair a car" in AA.
Checkbox request failed
jwu: 17: API: UsageReporting.API is not available on this device. Connection failed with: ConnectionResult{statusCode=SERVICE_INVALID, resolution=null, message=null}
it seem this error to appear all the time, but I pursued the test and attached other logs. You can see the full log with the file logcat_aa8.9_1.txt.
+ add AA-AIO-TWEAKER-5.2.2-hotfix-release :
I disabled tab limitation, bt autoconnect, telemetry. The log error was similar so I saved nothing. But this thing seem very hot and I will certainly use it if I ever make it.
+add enabled zygisk, lsposed 1.8.6. shamiko 0.6, AA XLauncher 2.0.1 (w/ kinginstaller), enabled AAXLU in LSPosed :
shamiko 0.7 cannot install because magisk need to be 2.6, but shamiko 0.6 seem to work with magisk 2.5. I did try different way to launch AA using XLauncher but each time the same checkbox related error message in logcat_aa8.9_2.txt.zip.
~replace with NikGapps-basic-arm64-13-20230418-signed
Since it seem related to some API I did try to change the GApps but I'm not sure I can just bump mindthegapps with nikgapps, but I did try. The swap seemed to work but after that I could not log with Android Studio anymore for some reason so I used ADB shell to save logcat, maybe something else can be seen using it logcat_aa8.9_3.txt.zip.
~upgrade to AA projection.gearhead_9.3.631404-release-93631404_minAPI26(arm64-v8a)(nodpi) :
As a last resort, I did try to upgrade to AA 9.3, but the error about missing UsageReporting.API support was again here logcat_aa9.3_1.txt.zip.
I guess now I need to research about that API and understand why it missing... I'm thinking maybe it's because I did not registered google play service with my account to avoid it upgrading AA automatically. I'll check this out and get back later.
Cheers,
I was able to fix the UsageReporting.API is not available on this device. by registering the device with playprotect. Then I systemized gearhead, installed latest version that also work on a cellphone (9.3.631434), put AA in debug verbose mode and I get back with the error log about a leaked windows and dropping event because there is no touchable window at (x,y). I'm using a mouse/keyboard and hdmi display when I try to connect AA with the car, so maybe this is not considered as a touchable windows for AA ? Maybe there is touchable windows emulator I could use ?
At this point I start to get out of idea and it seem I get back to my initial point. Has anybody was able to use an raspberry pi as an AA client device ? I think my next step would be try that aa4mg thing, but I'm not so sure what is microG and if those KonstaKANG rom are compatible with it ... oh well, I guess there is only one way to know it.
Reading about aa4mg lead me to omnirom which seem interesting and look awesome on an rpi4b. I did try the omni-13-202303081341-rpi4-MICROG. Unfortunately I could not quickly install magisk to install aa4mg (there is that tutorial I could try) so I proceed a parallel task to try a fresh version of :
rom :
= lineage-19.1-20230313-UNOFFICIAL-KonstaKANG-rpi4.
install :
+ Magisk 25.2
+ f-droid
+ microG Service Core (via fdroid)
+ aa4mg (via magisk) (! should have volume ctrl here, but default seem fines)
+ aurora store (via fdroid) - AA is not there anymore
+ busybox (aurora)
+ app-systemize (via magisk)
+ kinginstaller
+ android auto 9.3.631434 (via kinginstaller, not rooted)
do :
> systemize : com.google.android.projection.gearhead
> give all permission to AA
> default USB mode : file transfer or USB tether
at this point I get the error "android auto wont run without google play services which are not supported by your device" but what is interesting is that AA seem to run on startup as it would detect the car is plugged. I've yet to receive those power-usb-otg cable so for now I can only say that since AA run on startup of a boot from lineageos if the RPI4b is plugged in the car dashboard.
So what's next ? I will maybe try 8.3 version of AA as I read about the error message of google play services could be fixed using prior version of software, but also review microG Service Core setup as I though this was supposed to replace the play services. Apparently my GmsCore has not the correct signature, so maybe there is the problem since I read it allow GmsCore to pretend to be GooglePlayService. Probably that Konsta KANG LineageOS for RPI4b need extra step to support signature spoofing. So I think I will leave it there for tonight, time goes so fast when you are busy ! According to that wiki, next item on my list of install is Xposed and also lsposed which I already installed in the past https://github.com/microg/GmsCore/wiki/Signature-Spoofing
I could not find procedure to do signature spoofing using zygisk so I did try the riru way :
install :
+ riru-v26.1.7.r530.ab3086ec9f-release
+ LSPosed-v1.8.6-6712-riru-release
+ fake_GApps_4.2_app-release
_> FakeGapps : System Framework (default recommended), added FakeStore 0.0.2, added microG Services Cores 0.2.27.223616
_> AAXLU enable module : Android Auto (default recommended), added System Framework, added FakeStore 0.0.2, added microG Services Cores 0.2.27.223616
I though I had stuff to setup to activate signature spoofing, but apparently a reboot and AndroidAuto would not complain anymore about missing Google Play Service ! Quickly Android, to the Carmobile ! I can honestly say my heart skipped a beat when I saw AndroidAuto authorization start on the car dashboard and car pairing tutorial on the Raspberry Pi 4b . Another good news was also awaiting me there, as I received those USB-USB-C_OTG_Power cable ordered in my first post, and they would work. So I could provide required amp/voltage to the RPI from auxiliary power outlet while using another port for usb data.
The pairing process on LineageOS's AA could not finish as some of the prerequisites apps where not installed, Here is what is missing :
(present) : Android Auto
(missing) : Google App
(missing) : Google Maps
(missing) : Google Text-To-Speech
I also noted you could not start AA from AAXLU in either material3 or stock mode. I will check this out after I will be able to successfully finish the car pairing wizard.
Before I proceed further I will take a clone backup of the microsd and take a break as there is just so much emotion a man can sustain. Of course I dont think I will wait long before install prerequisites and pursue investigation.
I was able to fix prerequisite this way:
+ install GSF from f-droid's microG repo.
~ fix background location servce permission thanks to ploink here.
~+ check permission : dumpsys package com.google.android.gms | grep granted=false
~+ add permission via adb shell su : pm grant com.google.android.gms android.permission.ACCESS_BACKGROUND_LOCATION
+ aurora store : google 14.17.24.28 arm64 (301236347)
+ aurora store : google maps (11.77.0300)
+ aurora store : speech service by Google (require GSF)
So the wizard would finish but keeping reporting that Maps "Permission needed, google maps in android auto needs a certain permission to work effectively. Review this permission in Settings : Location Allows Maps to determine your device's location" even if it is set. Google App would ask me to logon but complain that the account already exist on the phone. For now I'll just skip that. As I more important problems, the developper settings would crash if I try to acces them, the screen would randomly freeze or display garbage when connection the usb.
I will review those error but what I think I will try next is to see if AndroiAuto AIO can provide any insight on the problem. Try to rollback to AA 8.9. See what debug log tell about the problem.
Since I was getting some GMSCore permission problems on LineageOS I thought I would give OmniRom since there is a rom for Rpi4b !
omnirom : omni-13-202303081341-rpi4-MICROG
Note, install nikgapp AA at the very beggining as it will otherwise wipe data and many thing will need to be redone.
Here is what I installed :
+ magisk 2.6.1 (enable zygisk) patching with mkbootimg + unpackbootimg. Instruction from rsaxvc.net.
+ aa4mg-v0.6.1.zip (magisk) : (follow install instruction on github + disable wireless screen)
+ LSPosed-v1.8.6-6712-zygisk (magisk)
+ shamiko-v0.7.1-166 (magisk)
+ android auto (modded to remove nikgapps prerequisites), forum.xda-dev thread
+ google app (aurota store or apkmirror)
+ google tts (aurota store or apkmirror)
+ google map (aurota store or apkmirror)
tested to downgrade google map 10.87.4 using : pm install -i "com.android.vending" <apk>
With this procedure it's the farthest I went so far, although it was not working. Each time I would plug the RPI on the car I would need to redo the pairing wizard, with the green error message that Google Maps need location permission (I think I gave everything I could think of). After that, on the RPI it ask to finish the wizard on the car dashboard which is showing an empty screen. I think I will try with OmniRom Android 12 or lower version I could find, of course if anybody has idea for me I would be more than happy to hear about it.
I installed omnirom 12 for rpi in a similar way as my previous post and results are the same. AA say to continue setup on car screen which is displaying an empty screen. I'm not so sure what to test anymore and start to think it just wont work. I collected a log of when I plug the cable on the car to when I finish the wizard, maybe someone will see something ?