Related
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.
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.
Unreal.... can a group of professionals get together and spend a day cracking the bootloader and root the Verizon version note 5 not even one custom rom for this device all other models have gotten there attention we need to crack this note 5 please
so far no one can hack n920v bootloader. Me also waiting for this info. Until now my n920v still not root yet. huhuu
It does not bypass bootloader
It's funny, in the UART logs running an engineering s-boot, it will say that an invalid image was detected, and it will reboot to avoid tripping Knox. A t-mobile phone I got, I accidentally flashed a Verizon image, and there went Knox, before I had intended to. Verizon has probably drastically reduced the unexplained returns, with the lies suggested on here to use by doing that. That might be a main motivation to consider.
But back to the subject, before I ever tried attempted to understand Magisk (which I used on my XT1575), which sort of does the same thing I did, but still allows selinux, was to use the engineering kernel, and did the following:
& Mount /system as loopback in /data/systemmirror
& Mount a loop back image over /system, which effectively hides it
& Link to each file in the loopback to the mirror, except for what I didn't want, and add what I did want. I even got xposed, microg/unifiednlp working like that. I didn't want to use supersu, but I imagine it can be done too. Some files had to be on the loopback system because uh I think it didn't like dynamic linking some library files that were links, that was fun to debug again and again and again until it worked.
& Set selinux permissive, because links aren't normally allowed, and I couldn't figure out how to make that work in the policy, and I could have reloaded it with the tools in the supersu apk if I knew what I was doing.
Thus, a tethered root is made. Tethered. Every boot up, you have to log in with adb to run the shell script that mounts everything, changes selinux, and kills system_server, effectively rebooting it. I could not figure out another way. It worked, minus samsung pay.
While that doesn't sound so bad, I went into the subway, was playing my hacked up version of shattered pixel dungeon, and the kernel crashed. Man, I that was a bummer. Still haven't rooted it properly.
If there's a fwbl1 or something that breaks the chain of trust from a developers SDK, sboot could be modified to load any binary without tripping Knox into an existing sboot probably.
I've removed so much stuff from this post so many times while preparing the draft to submit to my comment editor, I wonder how many times before I'm forced to decide whether a sign post visible in 1/9th of a picture is part of a street sign or not.
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.
hi!
is there any way to replace the bootanimation binary on samsung devices before it gets loaded? i've dived into the magisk documentary a lot already and tried many methods to make a working module, but in every case the file either got replaced after the boot is done or just didn't get replaced at all.
if someone would please point me to the right direction, i was planning to release this module for other samsung phone owners to use!
Magic mounting often happens too late for the boot animation to successfully be replaced. There used to be an early mount stage, but that was buggy and therefore dropped a long time ago...
The earliest you could get away with is probably if you use a script in post-fs-data.d to bind mount the file from the module directory. Although, it is bad practice for modules to be placing scripts in post-fs-data.d, this could be necessary to get the earliest possible excecution. Just make sure to use the module uninstall.sh to delete the script and also leave in a self-destruct in the script if the module is removed without utilising the uninstall.sh file.
Also, bind mounts can trigger SafetyNet, but that depends a bit on what is actually mounted so keep an eye out for that.
No guarantees the above will work.