Where can I find general information on Xposed, e.g. how to install it?
In this thread.
Does this require root access?
Yes, because it replaces a file in /system/bin. Once the framework is installed, it should work without root access.
For which devices/ROMs does it work?
I develop the Xposed framework based on the AOSP sources. I'm personally using CM10.2 on an I9100 (Samsung Galaxy S2, bought in Germany). Basically, it should work on any phone which with a ROM based on Android 4.0 or later and an ARM or x86 processor (this is the processor architecture, almost all smart phones and tablets have either of those). Exceptions might be ROMs which are different from the original Android code in some very internal, central code parts (which don't need to be touched for most theming and enhancement modifications). But this is related to the ROM, not the phone itself.
The modules target higher-level code, so they are more likely to be incompatible with your ROM. Basically, the question is whether the methods and resources which the module modifies are similar on your ROM and on the developer's ROM. Let's say a module needs to modify the result of a certain method call. For this, it needs to specify the exact name and parameters that identify that method. If the in your ROM, an additional parameter has been added, the module can't find the method anymore and won't work. If the method can still be found, it will probably work (unless the rest of the app/ROM has changed too much).
There is not definite answer whether it will work. Just try it (of course, making a nandroid backup before is never a bad idea). If it doesn't work, just disable the module. You might want to inform the module developer (not me!) about this fact and provide details (e.g. a logcat and/or the content of /data/data/de.robv.android.xposed.installer/log/debug.log).
What about Gingerbread? Or any other Android version before 4.0.3?
An experimental version for Gingerbread made by liudongmiao can be found here: http://forum.xda-developers.com/xposed/-t2739034.
Note that I cannot give any support for it, please direct your feedback to @liudongmiao.
Are there known incompatibilities?
There seem to be issues with AOKP nightlies. For more details, please read this post.
There seem to be issues (bootloops) with the Oppo Framework, I don't have a fix yet.
On some HTC One phones with CM11, the System UI force crashes. This seems to be caused by SELinux restrictions. Executing "restorecon /system/bin/app_process" (as root, e.g. with adb shell) should help against the FCs, but Xposed might not work due to other SELinux restrictions. If you have the possibility to disable SELinux enforcing mode, you can try that.
If you are an SELinux expert and would like to help, please contact me.
Apart from that, obviously it won't work if the conditions mention above aren't met, e.g. if your phone isn't rooted or it is running on a pre-ICS ROM.
How can I install it?
See the first post. The framework installation needs to be done only once (and on updates), then it can be used for any modules.
Does Xposed get disabled if I flash a new ROM?
Yes, because the file it modifies, /system/bin/app_process, is part of every ROM and will be overwritten when you flash a ROM. However, as long as you don't wipe data, the Xposed Installer app will still be installed, so you can just click on "install/update" again in the Framework section and reboot.
For CyanogenMod-based ROMs, there is an easy solution: [1] and [2]. This will reactivate Xposed automatically after you flash a new ROM/nightly.
For other ROMs, you can try this one. Be careful, it will disable Xposed again if you flash it twice!
Isn't this insecure?
In a way, yes. With great power comes great risk. On the other hand, other ways of modifying your phone are also open to malicious coding. For more details see this post.
Why do I have to enable a module after installing it? Couldn't you skip this additional step?
This is for security reasons (see the question above). By making you confirm that you want to use a module, apps cannot contain hidden Xposed modules. The same could be done with an additional permission, but I'm not sure if everyone would recognize that and it is harder to implement. As a bonus, this toggle allows you to temporarily disable a modification or to ship an app that contains an optional Xposed module.
How do I develop my own modification using the Xposed framework?
First make sure that Xposed is working fine for you. Then read this extensive tutorial.
Why isn't the Xposed Installer available via Play Store?
I have several reasons for that. I wrote about it in this post. And as I learned, Google does indeed sometimes remove apps which interfere with other apps.
From my point of view, you are free to publish the modules you develop on Play Store (at your own risk - Google might remove them). However, be careful if you plan to get money from them. Paid apps are stored in encrypted containers, which means Xposed can't load them at boot time.
Where can I donate some money to support you?
http://repo.xposed.info/donate
Am I allowed to fork Xposed and publish my own version? What should I consider?
I have written this down in a separate post: http://forum.xda-developers.com/showpost.php?p=46325320&postcount=4372
Can I include Xposed in my ROM?
First of all: One reason why I developed Xposed was to avoid the need to flash anything just for a few small changes. So Xposed is designed to work on top of ROMs, not as a part of them.
That said, I don't forbid you to include it. Here are the conditions:
I won't support you in the process of including it. You'll have to figure out the best way to do it yourself. The easiest way (which will also cause the least problems) is probably to simply put the installer and the modules into /system/app, then your users just need to click the "install/update" button, activate the modules they want and reboot.
There might be ways to really pre-install Xposed so that it's working out of the box, but I don't recommend that. You have to be very careful about file permissions, so there is a good chance it won't work. Again, absolutely no support for this.
I won't support your users with problems which might have been caused by using the included version instead of installing it normally.
When your users report problems which are probably not related to including Xposed in the ROM, please try to give them some support yourself. If you can't find a solution, send them to the correct help thread. For example, this thread is only for the framework. Not for any modules, not even my own.
I expect you to include the latest versions, which are usually the ones working best. I won't support older versions.
Your users must be able to update to the latest version, preferably without installing a new version of your ROM. Again, I won't support older versions.
From the previous point, it follows that you need to include the original APKs, otherwise updating is not possible due to a certificate mismatch. This is even more important since updates are possible from within the app. It also avoids confusion, like users wanting support for any modifications you might have made.
You probably want to include some modules. There are many modules that are not written by myself. Therefore, you need to get permission from the module authors as well. For modules written by myself, the same conditions which you are just reading apply.
Please give proper credit (which includes a link to this thread for the framework). Don't sell it as your own work.
You might have the impression now that I'm not a big fan of including Xposed in a ROM. This impression is correct. It's not too hard to install Xposed and any attempts to pre-install Xposed will just cause additonal support requests.
Why don't you just recommend Xposed in your ROM thread, along with the place where they can download it (this thread) and some instructions how to get the most out of it for your ROM? Give your users some choice!
The following posts list known, confirmed issues of the Xposed framework/installer. The intention is to give more information about the symptoms, the background and possible solutions/workarounds.
I won't add every reported issue here, but only when it's clear (e.g. through analyzed logs) that the problem is indeed an incompatibility with Xposed. It doesn't include module issues and the inability to read and follow instructions.
In case you have found a solution/workaround for one of the issues, please let me know.
ART / Android L / Android Lollipop / Android 5.0
Symptom:
You want to use Xposed and ART. However, as soon as you install Xposed, the runtime is reverted back to Dalvik.
Or you want to install Xposed on Android L, but it displays a message that it's not compatible.
Background:
There is no Xposed support for ART (yet), therefore Xposed automatically reverts the runtime to Dalvik. You can be glad that I implemented this, otherwise you would end up in a bootloop. It's a completely different architecture with pretty much no documentation. Rewriting Xposed for the ART runtime requires understanding the concept, the code structure and many details to know how it works. I have already spent dozens of hours on that and some things are working. But still it's a long way ahead. Don't expect even a test version in the near future. So please don't ask when it will be available - you will surely know when it is ready. I have nothing else to say about that.
Update: ART might be become the default runtime environment in the next Android version. You can read my thoughts about this here.
Update 2: The Android L developer preview is out. Don't try to install Xposed on this ROM! Check here for some explanations and status: http://forum.xda-developers.com/xposed/android-l-support-t2797923
Update 3: An alpha version for Lollipop is available now: http://forum.xda-developers.com/xposed/official-xposed-lollipop-t3030118
Square Enix games (e.g. Final Fantasy) / Puzzles & Dragons
Symptom:
If you have activated Xposed and any module, some Square Enix games (e.g. Final Fantasy) and Puzzles & Dragons don't start anymore.
Background:
I have spent several hours analyzing this issue. Here are my findings: http://forum.xda-developers.com/showpost.php?p=42331031&postcount=1701
Solution:
I don't think I will be able to fix this. Some users reported that it's working after converting Xposed and modules to system apps (but I didn't test it and you have to do this after every update).
Otherwise, you could press the "uninstall" button in the Xposed Installer, reboot, play the game, afterwards press the "install/update" button and reboot again.
Aliyun OS
Symptom:
You experience bootloops after installing Xposed and you find files like /system/framework/core.jex. Typical devices where this happens are THL T100S (with a MediaTek MT6592 processor), THL W200S, CUBOT X6, several ones from Zopo, ...
Background:
These devices ship with ROMs that are based on an incompatible Android fork called "Aliyun OS". These ROMs have a proprietary ahead-of-time compiler called "jazz, which is incompatible with Xposed.
Solution:
No chance of fixing this within Xposed. It was reported that deodexing the ROM and then deleting the /system/framework/*.jex files helps, however you won't get any support for this in the Xposed subforum.
Another possibility might be to disable the JIT compiler by adding "dalvik.vm.execution-mode=int:fast" to /system/build.prop or /data/local.prop (might have an impact on performance). See https://github.com/rovo89/Xposed/issues/14 for details.
MIUI/Dexspy
Symptom:
You experience bootloops after installing Xposed on MIUI. There are references to "Dexspy" in /system/bin/app_process and /system/framework/*.
Background:
There are modified versions of Xposed that have been integrated into some MIUI ROMs. I don't know the details, I don't know if that's still the case for current ROMs, and I don't have the time to follow up on this.
Solution:
Sorry, but I can't support you with this. MIUI is closed-source and in some parts heavily modified from AOSP. I don't have the time to keep track of their changes, and due to some bad handling from their side in the past (forking Xposed without any credit, removing all references to the original project and myself), I'm not very motivated to do so. If you're lucky, Xposed might work on your MIUI ROM. If it doesn't, you'll have to find someone else to look into it. If someone creates a clean patch that doesn't break Xposed on other ROMs, we can talk about including it, but otherwise you'll have to decide between MIUI and Xposed.
Segmentation fault
Symptom:
During the framework installation, you get messages that contain "Segmentation fault". This usually happens on ICS ROMs.
Background:
For some reason, the BusyBox binary that comes with Xposed doesn't work with your ROM.
Solution:
Install the attached app, it contains BusyBox binaries which are compiled with different settings, with all dependencies included in the file. Due to this, the incompatibilities should be gone. These files aren't included by default because they are much larger and not needed by most users.
Resources subclass
Symptom:
You can install Xposed 2.6+ and your phone is still booting afterwards. The version numbers are shown in green in the framework section. However, no modules are working. In the Xposed error log, you find a message like:
Code:
java.lang.ClassCastException: class android.content.res.XResources doesn't extend class x.y.z
You might have a ROM from Huawei, Nubia, ...
Background:
These ROMs use a similar approach as Xposed to theme resources. They create a subclass of Resources which takes care of special handling and return an instances of it from getTopLevelResources(). If Xposed replaced this class with its own XResources implementation, then it would a) break the ROM's additional functionality and b) probably cause crashes if the ROM tries to use this functionality.
Solution:
As a workaround, you can simply disable the resources API in the Xposed Installer settings. Some modules won't work anymore, but most should still work.
Mid-term, I hope that I can build a solution that works with such ROMs as well, however it will take some time.
Huge log file
Symptom:
Your disk space is getting low and you find out that much of it is taken up by Xposed Installer (sometimes several 100 MB). You think that this is a bug in Xposed.
Background:
It's most likely not a bug in the Xposed framework, but a bug or incompatibility of a module. One reason might be the removal of a hack in Xposed 2.6. That hack had a side-effect that some modules relied upon. The might also be other issues, for example the module might simple not be made for your ROM.
In any case, such modules might run into errors frequently and log each of them, causing the huge log files.
Solution:
First, find out which module is causing this. You can check the log file in the Xposed Installer. Somewhere near the top of the exception call stacks (beginning with "at ..."), you can usually find the package name of the module that caused it.
Next, make sure that the module is updated. To be on the safe side, you should update all modules. Then you can clear the log file and reboot.
If there are still issues, please go to the support thread of the module. Check if your ROM is supported and whether somebody else has already reported the issues. If not, post your error.log there and ask the developer to have a look at it.
Related
Note: This thread is here mostly for historical purposes. While Xposed is supported in various forms [EdXposed and LSPosed], developent on the Xposed primary app has completed. Xposed framework compatible modules are still in active development and supported by their respective developers.
Click to expand...
Click to collapse
This is the announcement thread for Xposed for Lollipop, Marshmallow, Nougat and Oreo. I'll post all relevant news here, so subscribe to it if you'd like to stay informed.
You can find a list with Q&A about Lollipop support on the XDA Portal. Please read it, you will find many answers there. Also see this article with much background information on new stuff for Nougat.
Please install it only if you're willing to take the risk of boot loops. Just because it's working fine and stable for me doesn't mean it will work for everyone the same way.
Downloads:
XposedInstaller_*.apk from this thread: Must be installed to manage installed modules, the framework won't work without it.
xposed*.zip from https://dl-xda.xposed.info/framework/: Must be flashed with a custom recovery (e.g. TWRP) to install the framework.
SDK21 is Android 5.0 (Lollipop), SDK22 is Android 5.1 (also Lollipop) and SDK23 is Android 6.0 (Marshmallow).
For Nougat, SDK24 is Android 7.0 and SDK25 is Android 7.1.
For Oreo, SDK26 is Android 8.0 and SDK27 is Android 8.1.
I only support the latest Xposed version per Android release!
xposed-uninstaller*.zip from https://dl-xda.xposed.info/framework/: Can be flashed with a custom recovery (e.g. TWRP) to uninstall the framework.
The small .asc files are GPG signatures of the .zip files. 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.
Known issues:
- Before Nougat: Bootloops on Samsung stock ROMs. That's due to Samsung's changes to ART. There are unofficial builds that work around this by deodexing and adjusting the ROM.
- Sony seems to have shipped some ROMs with corrupted services.odex (the embedded .dex is invalid). Those ROMs will bootloop with a "Fatal signal 6" or "No pending exception expected: java.lang.ArrayIndexOutOfBoundsException" error, which I unfortunately cannot fix (see https://github.com/rovo89/Xposed/issues/64)
- Dell ships (at least) their Venue 8 7840 with a non-standard version of ART that is somewhere between 5.1 and 6.0 which obviously isn't supported by Xposed (see https://github.com/rovo89/Xposed/issues/77)
For discussions, please use the discussion threads (Lollipop / Marshmallow / Nougat / Oreo) or another matching one in this subforum.
As you have probably noticed, more than 2,000 posts have been made in the original thread about Xposed on Lollipop. I'm really overhelmed by all your feedback! Also many thanks to those people who have donated already, it's great to see how much Xposed means to you.
Although so much discussion and helping each other is great, it's hard for anyone (including me) to follow. Hence, I have decided to create this thread were only I (and possibly the XDA moderators) will give some updates. This will make it easier for me to inform you about the current status, bugs I know about and so on. Feel free to subscribe to it or simply check from time to time. I'm not sure yet about the best way for me to get a consolidated overview of existing issues that have been confirmed by several people and ideally already have a sufficient information (like logcats, clear description of the error, ...) attached, but I hope we can work something out.
Current status (Feb 19):
The most important issue seems to be the incompatibility with Samsung stock ROMs, especially because it's leading to boot loops. I have been working hard on fixing this in the days since the release, however it's not just a single spot that needs fixing. Thanks to GermainZ for testing and providing good log files! So far, I have detected the following issues:
- Enhanced .oat file format: Samsung has added a "TypeLookupTable", probably for performance reasons. The table itself will be ignored by Xposed, but it also means that the file format is slightly different. I have finally understood what they have done and added some logic to skip the referenes to this table.
- Different size of the String class: They have added a clear() method, which is unusual as strings are usually immutable. As this class is one of few that have special support in native code, I had to add one entry to the virtual table of the class.
- Additional fields in DexCache class: Offsets to some fields are different due to this and need to be handled in native code (as this another central class with native parts directly implemented in ART).
- Verifier rejects ViewDebug class: Doesn't seem to be overly critical to me, yet to be tested whether it's working fine with original libraries.
- Implementation missing for some native methods: Some methods in the reflection classes have been implemented in native code instead of Java. This means I will have to implement them as well.
The changes done by Samsung are bigger than I expected, especially given that ART is very complex and mostly undocumented. Anyway, I still think that once these issues have been overcome, it's better to replace the libaries than trying to manipulate data structures and behavior from "outside" (app_process). Think about it: If they have done such big changes, it's very likely that offsets in these data structures are different from AOSP and would need special handling as well.
It would of course be helpful to have an uninstaller ZIP in case you run into a bootloop. I didn't have time for that yet, but maybe someone can build an initial version that basically reverses the steps of the installer ZIP. For the ART libraries, that should be rather easy. You might want to stay away from moving app_process32 back in case you have SuperSU installed. It will need a special procedure to ensure you don't break either part or even your ROM.
There are other issues for sure, for example it seems that some methods cannot be hooked. That's something that needs more investigation, but I would like to fix the more critical issue like the ones for Samsung first.
That said, I won't be able to work on Xposed for the next days, definitely not before Monday. Keep in mind that this isn't my fulltime job and that an alpha phase might take some time. It would be illusionary to assume that we reach a stable state after a few days, with all the changes that have been done.
I have just uploaded alpha2. It fixes several issues:
java.io.IOException: Invalid argument while reading /data/data/de.robv.android.xposed.installer/conf/modules.list (sometimes it worked fine after a soft reboot), see https://github.com/rovo89/Xposed/issues/25
ClassNotFoundException for system services (e.g. ActivityManagerService) shown in the log, see https://github.com/rovo89/XposedBridge/commit/6b49688c929a7768f3113b4c65b429c7a7032afa
Resources-related incompatiblity on newer CM12-based ROMs
Hooks for very simple methods not working, see https://github.com/rovo89/android_art/issues/4
app_process version not displayed in XposedInstaller
When you flash the new files, the next boot might take a bit longer, as it effectively clears the Dalvik cache (which is necessary because of a change in the ART compiler).
Note that this version is still not compatible with Samsung ROMs (custom ROMs might work if they're not based on stock ROMs). Don't install it, otherwise you'll get into a bootloop and need to restore your backup!
I have already done a lot of investigations and adjustments, as also mentioned in the previous post. However, there are still differences that need to be addressed and it will take more time to resolve them. I can't give any ETA on that.
Ok, quick status update.
Sure, I have heard that Android 5.1 is out. However, it currently makes more sense for me to stablize Xposed for Android 5.0, as I have two productive devices plus the Genymotion emulator running on it. Hopefully, it can then be ported to Android 5.1, but that's hard to tell without having had a look at it.
It's generally hard to estimate any timelines for Xposed-related stuff, for mainly two reasons:
a) Working on Xposed is mainly analysis of AOSP code, traces, closed-source files, followed by some development and testing (often trial and error). I never now which other obstacles are still undiscovered, so the effort is unclear beforehand.
b) Even if I know the effort (= net time), I can't say when I will have the time to actually work on it. For example, this week I probably won't spend a single hour on development. Sorry, but I'm not going to sacrifice my private life for Xposed and I can't spend several hours per evening for this project (anymore).
One of the next steps will be the creation of some scripts that help me to compile and package Xposed. Apart from simplification for me, I hope that this might help other experienced developers to try and contribute themselves (e.g by analysing the issues they noticed themselves).
So much for now, keep enjoying the stuff that is already working and please refrain from asking me when Xposed for 5.1 will be stable... I simply don't know that myself.
rovo89 said:
One of the next steps will be the creation of some scripts that help me to compile and package Xposed. Apart from simplification for me, I hope that this might help other experienced developers to try and contribute themselves (e.g by analysing the issues they noticed themselves).
Click to expand...
Click to collapse
It took longer than expected, but I also think it's better than what I had planned originally:
https://github.com/rovo89/XposedTools
I hope this makes it easier for others to compile the native parts of Xposed and the modified ART runtime themselves and get involved, just like @romracer did. It also makes it easier for me to build and package the Xposed framework, as it was quite a hassle to make sure that all files are compiled correctly, pushed to my PC etc.
I have just uploaded a new flashable ZIP for Xposed 3.0 alpha3 (xposed-sdk21-arm-20150426.zip).
You only need to flash the ZIP again, the Xposed Installer app remains the same (and therefore still shows version alpha2). If XposedBridge.jar has version 64 after a reboot, the new version is active.
Changes:
- Fixed issues with replacing drawables
- Fixed NoSuchMethodError in handleInitPackageResources
- Possibly fixed some errors on ROMs that start in permissive SELinux mode and switch to enforcing mode later
As the question probably comes up:
- No, this version doesn't support Android 5.1 yet.
- No, this ZIP doesn't support arm64/x86 processors yet.
I will eventually support them as well, but as there are unofficial versions for these, I try to work on a few known issues for Android 5.0 before (when I find time for it).
Regarding Samsung ROMs: No progress. No ETA. No promise that it will be supported, although I don't exclude it either. It's simply unclear what further differences between their and AOSP's ART variant come up.
alpha4 (20150430) is now available. It fixes bootloops and crashes on some ROMs, especially on Sony devices. In the logs, there used to be "Too many open files" errors.
References for this bug:
https://github.com/rovo89/Xposed/issues/31
http://forum.xda-developers.com/crossdevice-dev/sony/workaround-bootloops-xposed-lollipop-t3089203
http://forum.xda-developers.com/z3/general/xposed-bootloops-lollipop-t3085627
I have just upload files for a big update. It includes many general improvements/changes and some smaller fixes.
One of the changes is that I decided to avoid confusion about all the different (yet similar) version numbers for installer, framework zip, app_process and XposedBridge by reducing it to two version numbers:
The framework (i.e. all the files in the flashable) zip is versioned with integers (65 for this release). This is at the same time the Xposed API version. Unofficial builds should use suffixes to label their releases.
The Xposed Installer app will continue to use the well-known, human-readable version numbers, e.g. 3.0 alpha3 for this release.
The next bigger change is the installation script in the flashable ZIP. I use a modified fork of BusyBox now to keep the scripts clean and work with a well-known environment. This should make it pretty reliable, even in case some weird recoveries forget to include the "unzip" command. Those who are interested in the technical details should check out the GitHub project.
While I was working at it, I finally built flashable uninstallation ZIPs as well. They revert all actions done by the installation script, provided you didn't delete the backups (<filename.orig>). These ZIPs are only tested with Android 5.0.
The other changes are:
- Installer: Display the installed framework version in green, instead of a static hint about flashing the framework via recovery.
- Fix for incomplete logs on some devices, see https://github.com/rovo89/Xposed/issues/34
- Fix for updated modules crashing until the next reboot, see https://github.com/rovo89/Xposed/issues/22
- Ignore unknown parameters to avoid bootloops on some devices, see https://github.com/rovo89/android_art/issues/7
- Some other internal improvements
- Some cherry-picked ART commits from AOSP
- Devs: Allow hooking native methods, see https://github.com/rovo89/Xposed/issues/28
- Devs: Several debugger fixes, see https://github.com/rovo89/android_art/issues/1
I'm also uploading builds for arm64 and x86 devices. I have tested them on my Nexus 9 and on the Genymotion emulator and didn't notice any issues. The unofficial builds don't seem to be modified from my source code either and I didn't get pull requests on GitHub for these platforms, so I assume that they work fine.
By the way, in case you're a dev (or just interested) and want to try out your modules on Genymotion, you can use this collection of scripts to faciliate the Xposed framework installation on Genymotion. Just follow the instructions, then you can simply drop the x86 framework installation ZIP on the emulator window to install the framework. Don't forget to reboot afterwards.
So much for now. Be assured that official Android 5.1 support will come sooner or later, but the changes above required quite some debugging, development and strategic thinking. It's nice to see that some unofficial ports fill the gap for those who don't want to wait.
About M: The AOSP tag for the preview seems to be just a placeholder, just like it was for the L preview. I haven't tried, but I doubt that compiling ART from this tag will fit to the M preview image. Hence, I won't be investing any of the time (that I don't have anyway) to try and get Xposed running on the preview image.
Those who had issues with installer version 3.0 alpha3 displaying the framework as not installed, please try 3.0 alpha4. ProGuard optimized a bit too much in one very specific case... unfortunately, this never appeared during development, just in the release build.
If modules aren't loaded after a reboot because modules.list wasn't found, try to disable/enable any module. This will write the file again.
One addition to the changes in framework v65: The ZIP files are now signed. This wasn't possible before integrating the custom BusyBox version as some recoveries failed to unzip the signed ZIP.
I have just uploaded ZIPs for Xposed framework version 66 and also replaced the uninstaller ZIPs. There are no changes in the framework itself, so if you installed version 65 successfully, there's no need to update. If you got messages containing "Invalid argument" or "Wrong SDK version: 19, expected 21" while flashing the ZIP files, this should fix them. Thanks to @romracer for the fix!
EDIT: Had to reupload. If you downloaded the ZIPs within the first 15 minutes after this post was published, please download them again.
New files for framework version 67 are now available. They fix an issue with recoveries that have SELinux disabled (even though they might claim that "Full SELinux support is present" in the log, like TWRP does). This seems to have happened mainly on LG devices and caused boot loops, but could affect others as well. Details about the fix are in this commit: https://github.com/rovo89/XposedTools/commit/c55ac907e16947d66012950d119d8db1aea69124
The uninstaller has also been updated, although it's unlikely that it would have caused real issues.
framework version 68 fixes two reported crashes:
"Fatal signal 11" reported for dex2oat or "Compiler driver" in the Xposed log. I have seen a few posts about such issues, but the one I tested the fix with was about Quickoffice. If you notice further issues like this, please report them on GitHub with the full logcat (as only that contains the command line that crashes).
"com.android.phone has stopped" on LG G3. Don't confuse this with support for encrypted apps (LGWeather, LGCover), this can't be fixed unless someone comes up with a decrypter, ideally one that can be executed on the device.
rovo89 said:
Don't confuse this with support for encrypted apps (LGWeather, LGCover), this can't be fixed unless someone comes up with a decrypter, ideally one that can be executed on the device.
Click to expand...
Click to collapse
I had another look at their encryption, or rather the library they use for it. Fortunately, all the decryption logic is in that library (liblgalmond.so), not in ART itself. So I did a lot of digging into their libraries and finally figured out how to call the relevant functions to detect and decrypt their encrypted apps on the fly. That's the requirement to recompile and run these apps.
So here it is, framework version 69 with support for LG's encrypted apps (LGCover, LGWeather, maybe more). Please make sure to clean your Dalvik cache after flashing the ZIP if you have an LG device and had issues with these apps.
It turned out that some LG devices (at least G2 mini and G Pad 8.3) are using encrypted precompiled (odex) apps. These need to be handled differently than apps which contain just the encrypted dex file. With framework version 70, Xposed supports both encrypted dex and odex files. Again, clearing the Dalvik cache might be necessary. If you don't have an LG device or don't get FCs, you can skip this update.
In framework version 71, I have fixed a boot loop on various devices/ROMs related to the "SettingsProvider". If you were getting boot loops with earlier versions, you might want to give this a try.
Apart from that, it should now work properly with Sygic (after reinstalling the app or wiping the Dalvik cache). Note that some modules might not work properly with this app, as they "hack" Android's resource processing (e.g. for images/texts) on a low level. As this conflicts with Xposed (which does a similar thing), I had to disable parts of the API for this app.
I finally created an official version for Android 5.1 (aka SDK22). You can download it as v72 from the first post.
This version is not directly based on @romracer's port, however there aren't many differences. He had merged AOSP 5.1 into the Xposed codebase, I did it the other way around and used this opportunity to reorder and combine the commits. So it's a little bit cleaned up now, which will hopefully make it easier to port these changes to future Android versions. I have also cherry-picked two of his changes that weren't in the offical version yet: A fix for a special case in resource handling on 64-bit and compression of the backup Xposed creates during its installation. Many thanks to @romracer for providing the unofficial version - this gave me the chance to fix and improve many things (which were in turn merged by him and others).
That said, there are also a few new changes:
- In error messages, the Android version is now display as well, e.g. "Wrong Android version: 5.1 / SDK22 ... This file is for: 5.0 / SDK21"
- The files for Android 5.1 can now handle gzip-compressed odex files (*.odex.gz). Those files only exist on certain ROMs (e.g. CM) that merged a few commits proposed by Intel. These commits weren't accepted into AOSP because the way they're handling the compressed files has some flaws. With Xposed installed, these files will be unpacked on-the-fly and recompiled.
The gzip support might also be interesting for ROMs where the /system partition is almost full. It should be possible to gzip some of the .odex files before installing Xposed in order to free up some space. This should work on any odexed 5.1 ROM, even if the Intel commits aren't included. However, this would be very experimental. Volunteers are welcome, but don't forget to create a backup.
Finally, I have updated the uninstaller zips. They include a timestamp now, as new installer zips might require new uninstaller versions. You should always be able to uninstall older versions with the latest uninstaller though. v72 requires at least the uninstaller from today (20150831).
With framework version 73, a bug on 64-bit ROMs is fixed which prevented modules from reading their preferences. I believe that the root cause is a bug in AOSP, but whatever - it should be fixed now. Thanks to @romracer and @cryptyk for the fix.
I have additionally merged a few changes from CyanogenMod. Most of them control when the Dalvik cache is cleared automatically after a bootloop (new feature in 5.1 AOSP, now improved) and one is supposed to increase the compile performance on some ROMs. Don't expect too much though.
In framework version 74, I have fixed some more incompatibilities which could lead to bootloops or crashes. I assume that most of these crash logs contained the string "Incompatible set properties", which is actually a consequence of previous method verification errors. It's hard to say which ROMs and devices were affected - but flashing the new version shouldn't hurt even if everything looks fine with older versions. If you do notice any issues and are sure that it's not caused by yourself, you have higher chances of getting them fixed if you open a detailed GitHub issue (usually I will need at least a full logcat).
I won't be able to work on Xposed for the next 2-3 weeks - no time for development, support or questions at all. If the rumors I have read are right, I should be ready just in time to start porting Xposed to M.
THIS IS CURRENTLY NOT WORKING
A newer version is available here: https://forum.xda-developers.com/apps/supersu/suhide-lite-t3653855
suhide is an experimental (and officially unsupported) mod for SuperSU that can selectively hide root (the su binary and package name) from other applications.
Pros
- Hides root on a per-app base, no need to globally disable root
- Doesn't need Xposed
- Even supports SuperSU's ancient app compatibility mode (BINDSYSTEMXBIN)
- Passes SafetyNet attestation by default on stock ROMs (last officially tested on 2016.10.07)
Cons
- Ultimately a losing game (see the next few posts)
- No GUI (at the moment) - Unofficial GUI by loserskater
Requirements
- SuperSU v2.78 SR1 or newer (link)
- SuperSU installed in systemless mode
- Android 6.0 or newer
- TWRP (3.0.2 or newer, with access to /data - link!) or FlashFire (link)
Xposed
Xposed is not currently officially supported, but if you want to use it directly, you must be using @topjohnwu 's systemless xposed v86.2 exactly (attached at the bottom). It seems to mostly work during my non-extensive testing, but there are still some performance issues (both boot-time and run-time). Proceed with caution, expect bootloop.
Alternatively, there are some reports that the latest Magisk version + the latest systemless xposed (for Magisk) also works. I have not personally tested this.
CyanogenMod
I've personally tested with CM13 on i9300 without issue, however, several users are reporting it doesn't work for them. Proceed with caution, expect bootloop. Also, aside from just flashing SuperSU, you need to make sure /system/bin/su and /system/xbin/su are removed, or CM's internal root will still be used.
Usage
Install/Upgrade
- Make sure you have the latest SuperSU version flashed in systemless mode
- Make sure you are using the latest TWRP or FlashFire version
- Remove any and all Xposed versions
- If you have been having issues, flash suhide-rm-vX.YY.zip first, and note that your blacklist has been lost.
- Flash the attached suhide-vX.YY.zip
- If you are upgrading from suhide v0.16 or older, reflash SuperSU ZIP, and note that your blacklist has been lost.
- Optionally, flash the Xposed version linked above, and pray
At first install SafetyNet is automatically blacklisted.
If you have just flashed a ROM, it is advised to let it fully boot at least once before installing suhide.
Uninstall
- Flash the attached suhide-rm-vX.YY.zip. The version may appear older, the uninstall script doesn't change very often.
Blacklisting an app
You need the UID (10000 to 99999, usually 10xxx) of the app, which can be tricky to find, or the process name. There may be a GUI for this at some point.
(Note that all commands below need to be executed from a root shell)
If you know the package name, ls -nld /data/data/packagename will show the UID - usually the 3rd column.
Similarly, for running apps, ps -n | grep packagename will also show the UID - usually the 1st column.
Note that the process name is often the same as the package name, but this is not always the case. UID is more reliable for identifying a specific app, and it is also faster than blocking based on process names.
When you know the UID or process name:
Add to blacklist: /su/suhide/add UID or /su/suhide/add processname
Remove from blacklist: /su/suhide/rm UID or /su/suhide/rm processname
List blacklist: /su/suhide/list
All running processes for that UID or process name need to be killed/restarted for su binary hiding. For SuperSU GUI hiding, the device needs to be restarted. I recommend just (soft-)rebooting your device after making any changes.
Please keep in mind that many apps store their rooted state, so you may need to clear their data (and then reboot).
Integration into SuperSU
This mod isn't stable, and probably will never be (see the next few posts). As SuperSU does aim to be stable, I don't think they're a good match. But who knows, it all depends on how things progress on the detection side.
Detections
This mod hides the su binary pretty well, and does a basic job of hiding the SuperSU GUI. The hiding is never perfect, and suhide itself is not undetectable either. This will never be a perfectly working solution.
Debugging bootloops
- Get your device in a booting state
- Make sure you have TWRP or a similar recovery
- Install LiveBoot (link)
- If you are not a LiveBoot Pro user, enable the Freeload option
- Enable the Save logs option
- Recreate the bootloop
- In TWRP, get /cache/liveboot.log , and ZIP+attach it to a post here.
Download
Attached below.
Any rm version should work to uninstall any suhide version.
There may be multiple versions of suhide attached, please look carefully which one you are downloading!
YOU ARE EXPLICITLY NOT ALLOWED TO REDISTRIBUTE THESE FILES
(pre-v0.51: 17410 downloads)
Hiding root: a losing game - rant du jour
Most apps that detect root fall into the payment, banking/investing, corporate security, or (anit cheating) gaming category.
While a lot of apps have their custom root detection routines, with the introduction of SafetyNet the situation for power users has become worse, as developers of those apps can now use a single API to check if the device is not obviously compromised.
SafetyNet is of course developed by Google, which means they can do some tricks that others may not be able to easily do, as they have better platform access and control. In its current incarnation, ultimately the detection routines still run as an unprivileged user and do not yet use information from expected-to-be-secure components such as the bootloader or TPM. In other words, even though they have slightly more access than a 3rd party app, they still have less access than a root app does.
Following from this is that as long as there is someone who is willing to put in the time and effort - and this can become very complex and time consuming very quickly - and SafetyNet keeps their detection routines in the same class, there will in theory always be a way to beat these detections.
While reading that may initially make some of you rejoice, this is in truth a bad thing. As an Android security engineer in Google's employ has stated, they need to "make sure that Android Pay is running on a device that has a well documented set of API’s and a well understood security model".
The problem is that with a rooted device, it is ultimately not possible to guarantee said security model with the current class of SafetyNet tamper detection routines. The cat and mouse game currently being played out - SafetyNet detecting root, someone bypassing it, SafetyNet detecting it again, repeat - only serves to emphasize this point. The more we push this, the more obvious this becomes to all players involved, and the quicker SafetyNet (and similar solutions) will grow beyond their current limitations.
Ultimately, information will be provided and verified by bootloaders/TrustZone/SecureBoot/TIMA/TEE/TPM etc. (Samsung is already doing this with their KNOX/TIMA solutions). Parts of the device we cannot easily reach or patch, and thus there will come a time when these detection bypasses may no longer viable. This will happen regardless of our efforts, as you can be sure malware authors are working on this as well. What we power-users do may well influence the time-frame, however. If a bypass attains critical mass, it will be patched quickly.
More security requires more locking down. Ultimately these security features are about money - unbelievably large amounts of money. This while our precious unlocked bootloaders and root solutions are more of a developer and enthusiast thing. While we're all generally fond of shaking our fists at the likes of Google, Samsung, HTC, etc, it should be noted that there are people in all these companies actively lobbying to keep unlocked/unlockable devices available for us to play with, with the only limitation being that some financial/corporate stuff may not work if we play too hard.
It would be much easier (and safer from their perspective) for all these parties to simply plug that hole and fully lock down the platform (beyond 3rd party apps using only the normal APIs). Bypassing root checks en masse is nothing less than poking the bear.
Nevertheless, users want to hide their roots (so do malware authors...) and at least this implementation of suhide is a simple one. I still think it's a bad idea to do it. Then again, I think it's a bad idea to do anything financial related on Android smartphone that isn't completely clean, but that's just me.
Note that I have intentionally left out any debate on whether SafetyNet/AndroidPay/etc need to be this perfectly secure (most people do their banking on virus ridden Windows installations after all), who should get to decide which risk is worth taking, or even if Google and cohorts would be able to design the systems more robustly so the main app processor would not need to be trusted at all. (the latter could be done for Android Pay, but wouldn't necessarily solve anything for Random Banking App). While those are very interesting discussion points, ultimately it is Google who decides how they want this system to work, regardless of our opinions on the matter - and they want to secure it.
--- reserved ---
Changelogs
2016.10.10 - v0.55 - RELEASE NOTES
- Some code cleanup
- Support for blocking based on process name
- Should fix some crashes (requires uninstall/reinstall to activate)
2016.10.07 - v0.54 - RELEASE NOTES
- Fix for latest SafetyNet update
2016.09.19 - v0.53 - RELEASE NOTES
- Haploid container (monoploid)
2016.09.18 - v0.52 - see v0.51 release notes below
- Fix root loss on some firmwares
2016.09.18 - v0.51 - RELEASE NOTES
- Complete redesign
- Zygote proxying (haploid)
- Binder hijacking (diploid)
- su.d instead of ramdisk modification
- Xposed supported (-ish)
2016.09.04 - v0.16 - RELEASE NOTES
- Fix some SELinux access errors
- Should now work on devices that ask for a password/pattern/pin immediately at boot - for real this time!
- Binderjacking improvements for Nougat
2016.08.31 - v0.12 - RELEASE NOTES
- Fix some issues with suhide-add/rm scripts
- Fix not working at all on 32-bit devices
- Should now work on devices that ask for a password/pattern/pin immediately at boot
- Rudimentary GUI hiding
- No longer limited to arm/arm64 devices: support for x86/x86_64/mips/mips64 devices added
2016.08.29 - v0.01
- Initial release
As always thank you Chainfire! I will try and edit this post.
Edit @Chainfire this seems to work for enabling Android Pay! I didn't get the chance to actually pay yet. But it did let me add my card and did not display the message about a failed authorization of Android check! Before I couldn't even get past that first screen.
Edit 2: @Chainfire It seems to of had an adverse effect on Snapchat. I cleared cache on the app, uninstalled and reinstalled and restarted. It kept Force closing after a photo no matter what. I used suhide-rm and it seems to have fixed the app from any issues. Thanks again and hopefully we'll get you some more reports. Either way your solution works!
Tested on stock rooted 7.0 Nexus 6p.
@Chainfire
What was your reason for doing this project?
Sent from my Nexus 6P using XDA-Developers mobile app
Ofthecats said:
What was your reason for doing this project?
Click to expand...
Click to collapse
For building it, curious if the method I came up with would work well. For releasing, if others are doing it, join them or be left behind.
I'm assuming with custom ROM android pay still won't work right?
HamsterHam said:
I'm assuming with custom ROM android pay still won't work right?
Click to expand...
Click to collapse
I'd just give it a try. It's spoofing the specific app, not the entire ROM that matters. It's fairly simple to try.
Installed on LG G4 w/ V20g-EUR-XX update and rerooted with TWRP 3.0.2-0 and SuperSU-v2.76-2016063161323. seems to be working fine, for the moment. Thank you for the update.
So far so good, I was able to add card to android pay. I would try using it during lunch and report back. Again, thanks for the continuous hard work.
djide said:
So far so good, I was able to add card to android pay. I would try using it during lunch and report back. Again, thanks for the continuous hard work.
Click to expand...
Click to collapse
What was the UID or process you found to blacklist it with?
Sent from my ONEPLUS A3000 using Tapatalk
how to install it? which file should I flash ? Both?
I can't see to add an app using terminal.
I'm typing in
/data/adb/suhide-add 10284
Says file not found. Can someone help, cheers.
Joshmccullough said:
What was the UID or process you found to blacklist it with?
Click to expand...
Click to collapse
Android Pay comes blacklisted out-of-the-box
HamsterHam said:
I can't see to add an app using terminal.
I'm typing in
/data/adb/suhide-add 10284
Says file not found. Can someone help, cheers.
Click to expand...
Click to collapse
Are you in Android or TWRP ?
ls -l /data/adb/
Chainfire said:
Android Pay comes blacklisted out-of-the-box
Click to expand...
Click to collapse
Derp. That's what I get for not reading the entire sentence under 'Install' in the OP......thanks!
PedroM.CostaAndrade said:
how to install it? which file should I flash ? Both?
Click to expand...
Click to collapse
Please don't quote a large post like that just to ask a single question.
Please read the first post, so you know what to do.
OnePlus 2 here, stock 6.0.1, systemless rooted with SuperSU Pro v2.76, flahed using Flashfire.
Passes SafetyNet check, does not pass my bank's root check, propably for the reasons the OP states above.
thdervenis said:
OnePlus 2 here, stock 6.0.1, systemless rooted with SuperSU Pro v2.76, flahed using Flashfire.
Passes SafetyNet check, does not pass my bank's root check, propably for the reasons the OP states above.
Click to expand...
Click to collapse
You need to blacklist the UID for your bank. Directions are in the OP.
I have seen a couple of posts scattered around about xposed and if it can be used on lollipop. Yes it can, provided you are rooted of course. There are several different variants of the xposed framework, to my knowledge, only 1 works decently and the others...not so much. This is what I have set up to run xposed on my S5. Since this phone uses Touchwiz, there will probably be some limitations on what modules you can install or what modules even work.
Disclaimer: actual results may vary, you assume all liability for anything you do to your phone as well as inadvertently activating Skynet.
To avoid plagiarism, all of this information is taken from the link below. However, I put the links that are one this post in one easy to find location instead of post jumping to find what you need.
https://forum.xda-developers.com/xposed/unofficial-xposed-samsung-lollipop-5-0-x-t3455992
1. Make sure you are running a rooted, stock Lollipop 5.0 rom with FlashFire installed. This works with both Odex and Deodex roms!
2. Make a backup of your device with whatever app or method you choose. I would recommend FlashFire.
3. Install the Xposed Installer app to your phone. Do not run/open it after installation, it will not work as it still needs the framework installed.
>> https://forum.xda-developers.com/attachment.php?attachmentid=3921508&d=1477916609
4. Save the following file to your phone, either internal or external SD. I would recommend external SD card.
>> https://forum.xda-developers.com/attachment.php?attachmentid=3955895&d=1480698503
The OP says to install the zip file via recovery, we can not have a custom recovery installed due to locked bootloader. Use FlashFire to install the zip file for the Xposed framework. Once that has completed, reboot your phone and open the Xposed Installer app on the phone.
From there you can enable Xposed, download modules, etc. Keep in mind, I did not create any of this...therefore, I can not offer much help on how to use Xposed or if you are having issues installing/configuring. If you are having issues, please reply and ask but you may get referred to the OP of the software.
On the Xposed Installer app, there is (see the attached screenshot) that says something about there seems to be an issue with your rom blah, blah, blah. Xposed and Touchwiz have had issues working together. Please remember that not all modules may install properly or even work...might even jack your phone up, hard telling! Please research any and all modules before installing them first, better safe than sorry.
I feel that it is necessary to add instructions about the process of flashing with Flash Fire. For anyone who does this in the future, select install from .zip and select the file you downloaded. You don't need to mount /system read/write or any other options. This was unclear to me, so hopefully no one does it in the future.
Samsung Xposed Safe Mode script v1.0
What does it do?
This is an init.d script which emulates the xposed safe mode where you can press any button during boot, get a vibrate (to know it detected you), and it will disable all your xposed modules. To be used in case of bootloops because of incompatible modules.
This only disables all modules so that you can boot. It does NOT actually uninstall or disable xposed itself.
Why would I need this?
I talked with the developer of xposed for Samsung, wanam, and apparently, xposed safe mode was disabled for Samsung devices due to a Knox issue (if you disabled xposed, Knox will hate you and refuse to boot the phone). This is good, but if you have a bootloop, AND you're on a bootloader locked device, you have NO CHOICE but to wipe your data. Ouch!! That's a heavy penalty for accidentally installing one malfunctioning module!
Or maybe your phone still is bootloader unlocked, but you're running Samsung xposed and safemode is still disabled for you. Then you'd rather have xposed safemode back just for the ease of not having to go through recovery to fix things.
How does it work?
1. Press any of three buttons during boot (volume keys, or home button). You have 10 seconds from bootup to choose to do this.
2. System will give you 2 short vibrates to tell you it detected it.
3. Press any button 4 more times, each time will give you another short vibration.
4. One long vibration will signal to you that xposed has been disabled.
5. The script will automatically reboot your device in 6 seconds. This is because we can't disable xposed, so xposed will STILL load modules on this bootup, which means you'll still see the bootloop momentarily until you reboot.
Great! How do I install it?
This is an init.d script, so you need init.d support in your phone. Obviously, if you have a bootlocked device, you probably don't have init.d support. This is not a guide on how to get init.d support, but I'll offer you a few tips you can use to search yourself.
- install-recovery.sh, since it's called by init.rc during boot, can be hijacked in order to create an init.d system.
- If install-recovery didn't work, SuperSU also includes an su.d directory which is executed at a similar time. Just throw a script in there, or throw a script in there which enables use of the init.d folder (run-parts /system/etc/init.d).
Anyways, here's how you install it:
- Place the script you downloaded into
Code:
/system/etc/init.d
OR
Code:
/system/su.d
Give the script proper permissions for the folder it's in
- For su.d folder, it is root:root 0700 (rwx------)
- For init.d folder, it could be a variety of permissions. My init.d folder runs as a result of su.d, so I gave it same permissions as su.d. If yours doesn't, then you might want to try root:root 0755 (rwxr-xr-x)
- The important point here is to make sure it's at least root user and group, readable and executable, rwxr-xr-x
Will it work on my device?
It should work on any device really, if you follow the simple instructions. But I've only tested it on the ATT S4 (Lollipop 5.0.1), so I can't guarantee it will work on your device. Test it out and see if it works for you! It probably will!
You saved me!
I'm glad to hear that! I love to hear and see a thanks, so make sure to click the thanks button and maybe write a post too!
Bugs and problems
You know how to report bugs and issues. State all relevant information related to the problem; device, problem in clear detail, with reproducible steps, and anything else you might need.
Related custom xposed builds
Here are a list of Samsung custom xposed builds I know this "safe mode problem" to be present in. (Don't forget, this problem is likely to be in any and all Samsung xposed custom builds due to the nature of the Knox problem).
[UNOFFICIAL] Xposed for Samsung Lollipop by arter97
[UNOFFICIAL][5.0][v87.1][03 Dec] Xposed for Samsung Lollipop 5.0.x
[UNOFFICIAL][5.1/6][v87.1][28 Nov]Xposed for Samsung Lollipop/Marshmallow
Disclaimer: As usual, while I've made every attempt to make it perfect, there are no guarantee it will work for you. By using this, you agree not to hold me accountable in case something bad happens to you (or it didn't save your device)! Do your own testing to make sure it works before you actually need to use it in an emergency!
FAQ
It didn't vibrate
You probably have a different device which places the vibrator in a different location. I don't have your device, so maybe you'll need to help me debug and find where the vibrator is located at.
It didn't work!
What happened? Give me some detailed information about exactly what you did, what happened, and the device you're on!
Some possible problems to investigate are:
Does the script have correct user: owner and permissions?
Is your init.d or su.d system even working? Make sure it is first
Nice work!
It should help with incompatible modules leading to a bootloop, but it won't prevent Xposed from loading, the flag "/data/data/de.robv.android.xposed.installer/conf/disabled" is ignored on my Xposed version, done here for a reason, i got many bootloop reports in the past by people accidentally triggering safe mode by physical buttons, leading to Knox refusing to deal with modified binaries.
Fortunately it does not seem to be the same with TouchWiz 7.0, so i will bring it back later for Nougat.
wanam said:
Nice work!
It should help with incompatible modules leading to a bootloop, but it won't prevent Xposed from loading, the flag "/data/data/de.robv.android.xposed.installer/conf/disabled" is ignored on my Xposed version, done here for a reason, i got many bootloop reports in the past by people accidentally triggering safe mode by physical buttons, leading to Knox refusing to deal with modified binaries.
Fortunately it does not seem to be the same with TouchWiz 7.0, so i will bring it back later for Nougat.
Click to expand...
Click to collapse
Thank you!
It certainly will help a lot for disabling incompatible modules. Yes, although it doesn't technically disable xposed itself. It's really great that future versions aren't that way!
I actually thought of creating another script which utilizes back and menu key buttons to actually uninstall xposed from backups (an actual disable xposed script of sorts), but I thought it was too much.
Hi Guys,
My Pixel 2XL "magically automatically" updated itself to Android 11, so I've been forced to migrate to the Canary build of Magisk
to get root back etc.
The problem I have, is that the modules are not being 'detected' despite being installed.
EG: Active Edge Mod for Pixel, module is installed in Magisk, but the app doesn't detect the installation.
Same for other Magisk modules.
I'm hoping its something simple I need to do to detect these, I've searched, but found no definitive answer.
Anyone have any suggestions? Or can point me to more info on canary?
Thanks in Advance!
I noticed v21 has been released, so I jumped back to the stable channel and updated app to 8.0.1, but strangely still have the same issue!
Modules aren't being detected.
I get the following error when I try to run energized in terminal;
/system/bin/energized[13]: .: /sbin/ .magisk/modules/energizedprotection/system/bin/setupFiles.sh: No such file or directory
You've got two rather special modules there, so they're hardly the benchmark for if things work or not.
For Active Edge Mod you're probably better of asking for help with the developer. And judging by that error the Energized developer also need to update their module, since that path no longer exists on A11 (and it's bad practise to hardcode the path like that anyway). You could edit the energized file in the module directly, to point to the correct path (check the module thread, I'm sure someone has brought this up already).
So, in conclusion: unless there are other more "normal" modules that doesn't work there's no issue and you need to contact the developers of these two modules so that they can fix them.
Thanks @Didgeridoohan, I wasn't aware that the paths had changed. That would explain a lot...
Out of curiosity, what would you consider a "normal" module? For testing purposes..
Cheers!
Thanks @Didgeridoohan, I wasn't aware that the paths had changed. That would explain a lot...
Out of curiosity, what would you consider a "normal" module? For testing purposes..
Cheers!
I always like @osm0sis' modules. They utilise the module installer scripts very nicely and pretty much always work (and if they don't something usually has gone horribly wrong).
Well, hijack the module installer scripts nicely.
Well, I do have @osm0sis BusyBox Magisk Module installed, but I think I read a tweet that TopJohnWu was incorporating a busybox binary in Magisk..
I can see that all of my Magisk modules (except Systemless Host) has a "folder icon with an i" on it. Can't find what that means.. and I get a blank screen when i press it.
Magisk has had Busybox integrated for ages... Lately it's become more usable for scripts and modules though. It's not exposed to the rest of the system like @osm0sis module is.
The icon you're seeing is the module readme. Click that and it should open in the window that you see.