Database Develop

[OFFICIAL] Xposed for Lollipop/Marshmallow/Nougat/Oreo [v90-beta3, 2018/01/29]

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.

[AOSP] sepolicy patch for Marshmallow ROMs

After a bit of tinkering and some insight from Chainfire and imoseyon i was finally able to get SuperSU working on AOSP roms without being permissive or having to use Chainfire's prebuilt sepolicy
sepolicy patch is here: https://github.com/PureNexusProject...mmit/0f5072de4580a5db7348917e77e4c1c35d3e3c1a

Stickied.

sorry to be that guy, but how does this affect the average joe?
does it mean theres going to be a new version of supersu with this or does this mean that custom rom makers can use this patch to make there roms not need the the custom boot.img?

WarningHPB said:
sorry to be that guy, but how does this affect the average joe?
Click to expand...
Click to collapse
It doesn't, this is for ROM devs only, they know what to do with this.

Chainfire said:
It doesn't, this is for ROM devs only, they know what to do with this.
Click to expand...
Click to collapse
Welcome back! Hope you had a good break.

Chainfire said:
Stickied.
Click to expand...
Click to collapse
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:

BeansTown106 said:
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
Click to expand...
Click to collapse
There is no such thing now as "all current root apps working".
If SuperSU's deamon can be launched, and it can in turn launch the supolicy tool, most of the rules from the diff will be modified by SuperSU as needed.
What your patch needs to do (and you have already done) is make sure SuperSU can be launched in the right context, and can modify the sepolicy. You do not need to implement those 300+ additions - it will be done at boot automagically.
As for those additions themselves, they are primarily needed to:
- make sure SuperSU can work, internal communications between the different processes and such
- make processes running as the "init" context (where root apps run by default) as powerful as possible
- specifically "allow" a number of things that would otherwise still work, but would be logged (everything that starts with "allow init" or "allow recovery")
Now, even with the above, still not everything works out of the box. Everything that goes from "init" to "non-init" context should already work, but going from "non-init" context to "init" may not. In your example case, we go from "logd" to "init", which isn't specifically allowed. Often apps can be fixed to work around an issue such as this.
Generally speaking, the solution is not to fix the source sepolicy or the supolicy tool, the solution is for the "logcat extreme" app to run the following at launch (as documented in How-To SU):
Code:
supolicy --live "allow logd init fifo_file { read write }"
In this specific case, maybe it could be added to supolicy, it depends on what exactly generates the audit. If it's a simple logcat command, it's a candidate for inclusion. The problem might even be solved by switching contexts rather than modifying any SELinux policies. But that is something for the app developer to figure out.
In either case, it is not something you need to fix in the AOSP patches. Those already do what they need to do.
Since they started doing SELinux Enforcing though, the policies in AOSP have generally been a tad stricter than on retail devices (this was specifically the case during 4.4 days). This may lead to you sometimes having to add/remove a rule manually somewhere that was not added to SuperSU yet. It could happen, but it's unlikely, probably temporary, and it probably should not go into this AOSP patch.
A note on pof's sediff, I'm not sure it was done cleanly, as I see some modifications in there that are not done by supolicy. Either way, such a post is informative, not leading, as supolicy may do more or less modifications depending on various runtime variables (such as Android version). Additionally, due to context names and availabilities changing between Android versions, any rule modification referencing a context not available in the to-be-patched sepolicy will not be applied, and thus will not show up in an sediff.

@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?

Chainfire said:
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Click to expand...
Click to collapse
thanks for the description above now i understand. have never developed a root app so i had not read that part of how to su, but it makes perfect sense that the root apps would handle the denials live via your supolicy
as for system less root i have not tried that yet but i will give it a shot tonight, and report back, i know some people in my ROM thread have used system less root. but i am not sure if you had packaged your sepolicy in the install script for 2.61+ and if it is overwriting mine in the kernel, if that is the case i will modify the installation to not patch the sepolicy and see if it works with my pre compiled one based on the source above

Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.

the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...

Chainfire said:
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
Click to expand...
Click to collapse
will build and test with only load policy enabled, is this for system, and systemless root?
danieldmm said:
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Click to expand...
Click to collapse
updated link, so your saying systemless supersu works with no selinux modifications?

BeansTown106 said:
updated link, so your saying systemless supersu works with no selinux modifications?
Click to expand...
Click to collapse
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk

danieldmm said:
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
Click to expand...
Click to collapse
that is why, these patchs are to allow you to run in enforcing

I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks

Garzla said:
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Click to expand...
Click to collapse
Try the following. It works for me when needed...
http://forum.xda-developers.com/showthread.php?t=3574688

Thank you for your work!

Link in OP its no longer working...
Is there any actual guide how to add SU directly to AOSP build. I have found bits and pieces but those are mainly 4.x releases.
I'm using Android M release and quite much struggling to get it working.

I have tried to make SU default on AOSP 6.0 by using this guide.
http://forum.khadas.com/t/gapps-and-su-on-soc/118/3
I'm using user build and enabled selinux permissive on that.
i have made also ro.secure=0 ro.debuggable=1 and security.perf_harden=0 (Not sure if needed)
I have also modified to change the su permissions in fs_config.c
I managed to get this work so that when flashing rom SuperSu ask for updating su binary and after that su works.
but i then cleaned work area to verify build by deleting out dir and recompiled. No go anymore.
Why it's so hard to add su by default on AOSP rom. I woud like to have it by default so i would not need to do any tricks everytime i flash new rom.

It reminds me of Korean dramas ,

[Q] New to Droid

I just got my Droid 4 off of Ebay, and I'm going back to Android after 5 long years of Windows Phone. Rooted and installed the latest version of Safestrap that lets us used the (now)unused partitions. Seeing the lack of ROM diversities, My question is: Which ROM should I install? xD
All the Marshmallow ones and the Lollipop one I tried where really slow after installing just a few apps. So I went back to 4.1.2. There is a KitKat one that I'd like to try but the links are dead. I also found a thread suggesting to modify the booting of Cyanogen 12 with apparently good results, but I didn't look too much into how to do that.
Tbh I'd love something like SFOS but it looks like it's being worked on right now. So it might be a while till it's ready for daily usage, if it's ever brought to that point. :/

peter768 said:
I just got my Droid 4 off of Ebay, and I'm going back to Android after 5 long years of Windows Phone. Rooted and installed the latest version of Safestrap that lets us used the (now)unused partitions. Seeing the lack of ROM diversities, My question is: Which ROM should I install? xD
All the Marshmallow ones and the Lollipop one I tried where really slow after installing just a few apps. So I went back to 4.1.2. There is a KitKat one that I'd like to try but the links are dead. I also found a thread suggesting to modify the booting of Cyanogen 12 with apparently good results, but I didn't look too much into how to do that.
Tbh I'd love something like SFOS but it looks like it's being worked on right now. So it might be a while till it's ready for daily usage, if it's ever brought to that point. :/
Click to expand...
Click to collapse
Hello,
I'm using stock one JB 4.1.2, heavy debloated and overclocked. You can add some functionality from other roms by instaling xposed.

I recommend the latest Lineage 13.0 ROM. This is my daily driver and it's amazing.
I also have Mentors' debloated Stock ROM for dualboot, in case I ever need it. The biggest contra of the Stock ROM is the extremely bad GPU performance. It can't even display Snapchat because there are graphical errors everywhere. It also stutters while scrolling in a lot of apps.
These problems are all gone with CM13. I played through Red Dwarf on it and the game worked smooth as butter, with some nice, detailed graphics. Get an overclocked kernel from the forums here, while you're at it.
You should also never use the Stock ROM as the main system, because it lacks years of updates and has severe security holes in it.

schmatzler said:
I recommend the latest Lineage 13.0 ROM. This is my daily driver and it's amazing.
I also have Mentors' debloated Stock ROM for dualboot, in case I ever need it. The biggest contra of the Stock ROM is the extremely bad GPU performance. It can't even display Snapchat because there are graphical errors everywhere. It also stutters while scrolling in a lot of apps.
These problems are all gone with CM13. I played through Red Dwarf on it and the game worked smooth as butter, with some nice, detailed graphics. Get an overclocked kernel from the forums here, while you're at it.
You should also never use the Stock ROM as the main system, because it lacks years of updates and has severe security holes in it.
Click to expand...
Click to collapse
I tried Lineage with an overclocked kernel yesterdat but it was still quite laggy. I also couldn't install the google apps due to insufficient space. Did you do anything else? Also I'm on cdma so I stayed away from Mentor's ROMs.

Instead of the original GAPPS, I'm using:
- XPosed
- the FakeGapps module for XPosed
- the MicroG Play Services from here
- and the Google Play Store. Got the APK from apkmirror, installed it, copied the files from /data/app/com.android.vending to /system/priv-app/com.android.vending and chmodded the files to 644 and directories to 755 (this has to be done, otherwise the Play Store cannot login).
This is a bit of work, but it runs much faster and doesn't drain my battery as fast as the original GAPPS do. The last step isn't even required, you can use FakeStore or BlankStore instead and just get all your applications from apkmirror if you want it.
Bonus feature: You can now use Google Maps with the Apple NLP backend.

schmatzler said:
Instead of the original GAPPS, I'm using:
- XPosed
- the FakeGapps module for XPosed
- the MicroG Play Services from here
- and the Google Play Store. Got the APK from apkmirror, installed it, copied the files from /data/app/com.android.vending to /system/priv-app/com.android.vending and chmodded the files to 644 and directories to 755 (this has to be done, otherwise the Play Store cannot login).
This is a bit of work, but it runs much faster and doesn't drain my battery as fast as the original GAPPS do. The last step isn't even required, you can use FakeStore or BlankStore instead and just get all your applications from apkmirror if you want it.
Bonus feature: You can now use Google Maps with the Apple NLP backend.
Click to expand...
Click to collapse
I tried to follow this, but Google Play Store crashes. When I run the app, the Google Account is created, but thats it, I cannot run Play Store. Do you have any advice?

It still works fine for me with the same instructions posted above.
Maybe you have a different version of the PlayStore? Mine is from here and doesn't crash:
http://www.apkmirror.com/apk/google-inc/google-play-store/google-play-store-7-8-32-release/
You may have to kill the app after the first login and open it again so you can accept the EULA, though. Otherwise you'll get a connection error.
(Useful: 5 second back button killing in the developer options.)
If it still doesn't work:
- Open up the microG Settings and check if signature spoofing is indeed enabled
- Open up Xposed and check if the FakeGapps module is activated. If it isn't, activate it and reboot.
---
A completely different, even more lightweight method to get PlayStore and microG working:
1. Flash the latest LOS13 ROM.
2. Enable ADB debugging on the device and connect it via USB to your PC.
3. Install adb and python on your PC and run the Tingle application (cmd.exe: "python main.py")
This will patch the installed ROM on the fly and replace a system file. It enables signature spoofing, which means fake Google Play Services will run WITHOUT XPosed. No XPosed means even more free resources on the device.
The rest of the instructions is unchanged:
4. Get the MicroG Play Services from here
5. Get the Google Play Store from apkmirror, install it, copy the files from /data/app/com.android.vending to /system/priv-app/com.android.vending and chmod the files to 644 and directories to 755 (this has to be done, otherwise the Play Store cannot login).
This method is a lot more extensive, especially on Windows systems where you'll have to install ADB and make it visible in the system path. You'll also have to install python manually. A pain. Much easier on a Linux system.
But it's the only method to make it work on LOS14 at the moment, because there is no XPosed for Android 7 out yet AND the only method for people who don't want to use XPosed.
Just FYI, maybe this helps someone.

peter768 said:
There is a KitKat one that I'd like to try but the links are dead.
Click to expand...
Click to collapse
You can get CM11 and other CyanogenMods for Droid 4 here - http://web.archive.org/web/20161226224516/http://download.cyanogenmod.org/?device=maserati.
peter768 said:
Tbh I'd love something like SFOS but it looks like it's being worked on right now. So it might be a while till it's ready for daily usage, if it's ever brought to that point. :/
Click to expand...
Click to collapse
You can get Sailfish OS for Motorola Droid 4 here - https://talk.maemo.org/showthread.php?t=99031.
It's not 100% stable but worth trying out (though not as daily driver for me).
Of course using Safestrap you can have more than one ROM installed on the device so you can follow the development of each ROM/OS you are interested in.
For example I have CM11 as my daily driver, stock ROM in case of problems (didn't have to start it until now) and Sailfish OS to look on its development.

schmatzler said:
You may have to kill the app after the first login and open it again so you can accept the EULA, though. Otherwise you'll get a connection error.
(Useful: 5 second back button killing in the developer options.)
.
Click to expand...
Click to collapse
Many thanks, this was the issue. Works perfectly also with newer play store version.

After some frustration with LOS13 (Bluetooth not working, laggy performance) I'm using now Mokee ROM (with FakeGapps for Xposed). Workes nicely, especially I appreciate the Aegis app for controlling app behaviour (autorun, wakelocks, background services, hibernate, broadcasts). Restarting the phone every 2nd day prevents performance lags which build up slowly.

[ROM][Pie] Unofficial LineageOS 16.0

This is an unofficial build of LineageOS 16.0 for the Motorola razr I, (XT890/SMI).
Lots of thanks to Hazou. This rom is based on his los-14 rom and I got help from him with los-16.
This rom has full hardware support and should run stable. It has been tested by me in daily use. I'm using the rom without google apps, but with microg. Installing google apps requires some apps to move to data partition because of limited system size. See install description for more info.
Special Features
-All features of Hazous 14.1 rom
-MicroG signature spoofing patch is included.
-Adaptive icons can be disabled in homescreen settings.
I can include more features if requested
Known Bugs
-The camera preview image sometimes shakes at random
Download
https://mega.nz/#F!5fBWlIAQ!Jlq9Bj789iJ0iIIptK00tg
Update
If you already run an earlier version of this rom, just boot to twrp and install the latest flashable zip file
Install
1. Backup everything you don't want to loose.
2. Download and install TWRP 3.2.3 (download in attachments. Can be flashed with fastboot or with another recovery)
3. If you come from another rom do a full wipe with twrp
4. Download and install the rom flashable zip (download from mega.nz link is in section download)
5. If you want to install opengapps or need system partition space for other things. Install the move_to_data.zip file from the attachments. This will move the Webview and the LatinIME app to data partition.
6. Choose one of the following options:
-either install google apps (download form https://opengapps.org/. Choose x86 9.0 nano or pico)
-or install MicroG (can be installed with the unofficial installer https://forum.xda-developers.com/android/development/microg-unofficial-installer-t3432360) this is lighter in ram and cpu usage but you will get problems with google chrome and other apps
7. If you want root access install the addonsu-16.0-x86.zip (download in the attachments)
8. Reboot the phone. First reboot will take some time
Changelog
Code:
20191018:
fixed problem with sms receiving
20191012:
mobile network connection works now after boot
Fixed problems with network switching
Show taps option is working now
intel art extension enabled
Call recording enabled
text relocation warnings disbaled
(untested) encryption. Needs special configuration (see below)
20190819:
SELinux is now enforcing
Notification access feature enabled
solved crashes with houdini emulated apps
20190713:
usb configuration works properly
battery light works now
July security patches
20190704:
first stable release of this rom
DATA Encryption
If you want to enable data encryption this would break the pds partition backup. To prevent this, the cache partition can be used as backup location:
-edit /system/bin/pdsbackup.sh
-change PDS_FILE=/data/misc/pds/pdsdata.img to PDS_FILE=/cache/misc/pds/pdsdata.img
-resize data partition in TWRP:
Code:
umount /data
umount /sdcard
e2fsck -f /dev/block/mmcblk0p17
resize2fs /dev/block/mmcblk0p17 1367079
-reboot the phone
XDA:DevDB Information
unonfficial LineageOS 16.0, ROM for the Motorola RAZR i
Contributors
julianwi, Hazou
Source Code: https://github.com/julianwi/android_device_motorola_smi/tree/lineage-16.0
ROM OS Version: 9.x Pie
ROM Kernel: Linux 3.0.x
Based On: LineageOS
Version Information
Status: Stable
Stable Release Date: 2019-08-19
Created 2019-07-04
Last Updated 2019-08-19

This if I did not expect it, I'll try to see how it goes. Thank you.

Download links and install description are up now. Download from mega.nz because xda download section is broken at the moment. I'm waiting for your test reports

It's really great works, thank you!!
I quickly tried and found several points.
- USB connection with PC
All USB connection option including File Transfer, USB tethering, PTP are grayed out.
Disabling/Enabling android debug in setting didn't work.
- Wifi with storage encryption
When you enable storage encryption, WiFi always become disabled, not be able to enable.
Just FYI, it required deleting /system/bin/pdsbackup.sh AND reducing partition size of 'data' (/dev/block/mmcblk0p17).
- SElinux
Although it is designated as permissive in device.mk, it's actually worked as "disabled".
I'm not sure it's related or not, however, when building "user build", it's failed with "ERROR: permissive domains not allowed in user builds".
I know "user build" is not officially supported in Lineage release, however, it's really helpful if we can do it for AFW usage.
Previously I could use Lineage 14.1 smi build for AFW and safetynet app with user build.
BTW, performance is really great, seems to be almost same as Lineage 11.

dumkm said:
It's really great works, thank you!!
I quickly tried and found several points.
- USB connection with PC
All USB connection option including File Transfer, USB tethering, PTP are grayed out.
Disabling/Enabling android debug in setting didn't work.
Click to expand...
Click to collapse
I also noticed that. Will see how this can be fixed. It is just a problem with the option dialog. Usb connection works fine. As a workaround you can set a default USB configuration in developer options
dumkm said:
- Wifi with storage encryption
When you enable storage encryption, WiFi always become disabled, not be able to enable.
Just FYI, it required deleting /system/bin/pdsbackup.sh AND reducing partition size of 'data' (/dev/block/mmcblk0p17).
Click to expand...
Click to collapse
I have not tested storage encryption yet. Will have a look at it later
dumkm said:
- SElinux
Although it is designated as permissive in device.mk, it's actually worked as "disabled".
I'm not sure it's related or not, however, when building "user build", it's failed with "ERROR: permissive domains not allowed in user builds".
I know "user build" is not officially supported in Lineage release, however, it's really helpful if we can do it for AFW usage.
Previously I could use Lineage 14.1 smi build for AFW and safetynet app with user build.
Click to expand...
Click to collapse
I think lineage trust doesn't differentiate between permissive and disabled. Selinux support is planned for future releases

Thank you for quick check.
Regarding USB connection, I also confirmed that Ubuntu can recognize as external storage with above option, besides Windows still does not recognize. Maybe depending on my environment.
Also I noticed that Chrome, Chrome Beta and Chrome Canary (therefore another Chrome based apps such as Maps Go) always crash. This is also maybe my environment only, though. BTW, I could install MicroG, besides couldn't install OpenGapps 9.0 pico due to partition size limit.
Additionally, I couldn't find any LED settings, currently LED is always off during charge or any notification.

dumkm said:
Thank you for quick check.
Regarding USB connection, I also confirmed that Ubuntu can recognize as external storage with above option, besides Windows still does not recognize. Maybe depending on my environment.
Also I noticed that Chrome, Chrome Beta and Chrome Canary (therefore another Chrome based apps such as Maps Go) always crash. This is also maybe my environment only, though. BTW, I could install MicroG, besides couldn't install OpenGapps 9.0 pico due to partition size limit.
Additionally, I couldn't find any LED settings, currently LED is always off during charge or any notification.
Click to expand...
Click to collapse
Notification Led should work. Can be configured under settings->apps and notifications->notifications->notification light. I don't know what happened with the battery light. It will hopefully come back if I upgrade the driver to hidl.
Google Chrome is a known problem with MicroG. It requires official gapps. I will check if some of the unprivileged lineage apps can be moved to data partition to make place for google apps

Newbie question
Hi all, I know someone who's selling her old RAZR i XT890 and I'm interested (for experimental reasons but also the oddity that it's Intel powered). I've never owned a RAZR i so I've got some questions:
-The phone is from 2012 so quite old and has 1GB RAM, does it work well with this Lineage 16? Because usually newer software would perform bad on older SoC (I used to have iOS 7 on iPhone 4 back in the day and it was painfully slow compared to 6).
-On Lineage 16, can it run any Android app as a standard new Android Pie phone? I ask because this is an Intel x86 CPU, so can it still run Android apps as normal or are most of them only designed for ARM and therefore unusable?
If I get the good news, I may buy the phone and try this Lineage OS custom ROM.

Regarding LED, maybe it became working after modifying some option of notification light. Battery connection light is still always off.
Regarding opengapps, I moved webview and LatinIME from app directory to external SD in TWRP, then installed as normal app after system boot. Webview worked fine besides LatinIME always crash. I'm using different IME, so it's no problem. With this environment, opengapps nano can be installed, then Chrome, Maps and other google apps worked.

dumkm said:
Regarding LED, maybe it became working after modifying some option of notification light. Battery connection light is still always off.
Regarding opengapps, I moved webview and LatinIME from app directory to external SD in TWRP, then installed as normal app after system boot. Webview worked fine besides LatinIME always crash. I'm using different IME, so it's no problem. With this environment, opengapps nano can be installed, then Chrome, Maps and other google apps worked.
Click to expand...
Click to collapse
That's good. Than we can make a flashable zip to automatically move and symlink them to data partition.
I will provide a new build till end of the week with improved usb and notification LED implementation. I already got it working in my local setup
flameseewa said:
Hi all, I know someone who's selling her old RAZR i XT890 and I'm interested (for experimental reasons but also the oddity that it's Intel powered). I've never owned a RAZR i so I've got some questions:
-The phone is from 2012 so quite old and has 1GB RAM, does it work well with this Lineage 16? Because usually newer software would perform bad on older SoC (I used to have iOS 7 on iPhone 4 back in the day and it was painfully slow compared to 6).
-On Lineage 16, can it run any Android app as a standard new Android Pie phone? I ask because this is an Intel x86 CPU, so can it still run Android apps as normal or are most of them only designed for ARM and therefore unusable?
If I get the good news, I may buy the phone and try this Lineage OS custom ROM.
Click to expand...
Click to collapse
Newer android versions have been designed while keeping low ram devices in mind. Ram hungry special features like the picture in picture mode are excluded from builds for older device. So the situation is much better then on iOS. But a newer phone would run better thought.
Most android apps are available for x86. But some are still arm only and get automatically emulated. The intel houdini emulator integrates these apps natively into the system but they are a bit slower then x86 apps. These are for example Skype and a few unity based games

julianwi said:
Newer android versions have been designed while keeping low ram devices in mind. Ram hungry special features like the picture in picture mode are excluded from builds for older device. So the situation is much better then on iOS. But a newer phone would run better thought.
Most android apps are available for x86. But some are still arm only and get automatically emulated. The intel houdini emulator integrates these apps natively into the system but they are a bit slower then x86 apps. These are for example Skype and a few unity based games
Click to expand...
Click to collapse
Thanks for the response. So I should be alright with it then, hopefully. I just hope it won't lag on that old SoC. I'd love if you could upload a quick video of it in action.

TWRP error 70
julianwi said:
This is an unofficial build of LineageOS 16.0 for the Motorola razr I, (XT890/SMI).
Lots of thanks to Hazou. This rom is based on his los-14 rom and I got help from him with los-16.
This rom has full hardware support and should run stable. It has been tested by me in daily use. I'm using the rom without google apps, but with microg. I don't know how smooth it runs with official gapps.
Special Features
-All features of Hazous 14.1 rom
-MicroG signature spoofing patch is included.
-Adaptive icons can be disabled in homescreen settings.
I can include more features if requested
Known Bugs
-Mobile cell connection doesn't connect after boot. You have to turn airplane mode on and off to let it work.
-selinux is set to permissive for now (reduced security)
Please report more bugs if you test this rom
Install
1. Backup everything you don't want to loose.
2. Download and install TWRP 3.2.3 (download in attachments. Can be flashed with fastboot or with another recovery)
3. If you come from another rom do a full wipe with twrp
4. Download and install the rom flashable zip (download from mega.nz https://mega.nz/#!ICwXRC6D!VZqe3o5zeWbmMiZvka_BtUTW5T_V7_OdMS57Oe9CbMk)
5. Choose one of the following options:
-either install MicroG (can be installed with the unofficial installer https://forum.xda-developers.com/android/development/microg-unofficial-installer-t3432360)
-or install google apps (download form https://opengapps.org/. Choose x86 9.0 pico)
6. If you want root access install the addonsu-16.0-x86.zip (download in the attachments)
7. Reboot the phone. First reboot will take some time
XDA:DevDB Information
unonfficial LineageOS 16.0, ROM for the Motorola RAZR i
Contributors
julianwi, Hazou
Source Code: https://github.com/julianwi/android_device_motorola_smi/tree/lineage-16.0
ROM OS Version: 9.x Pie
ROM Kernel: Linux 3.0.x
Based On: LineageOS
Version Information
Status: Stable
Stable Release Date: 2019-07-04
Created 2019-07-04
Last Updated 2019-07-05
Click to expand...
Click to collapse
I've installed the OS without problems, but when i try to get GApps Pico or any other version TWRP prompt error 70. How should i proceed? There is any additional configuration needed?

Kazvko said:
I've installed the OS without problems, but when i try to get GApps Pico or any other version TWRP prompt error 70. How should i proceed? There is any additional configuration needed?
Click to expand...
Click to collapse
Yes, system partition size is limited on this phone. To install GApps some files need to be moved to data partition.
I created a flashable zip to automate this process. Take a look at the modified install description in the first post

New build is up now.
flameseewa said:
Thanks for the response. So I should be alright with it then, hopefully. I just hope it won't lag on that old SoC. I'd love if you could upload a quick video of it in action.
Click to expand...
Click to collapse
Sorry don't have enough time to make a video in the near future. Maybe someone else can record a video of it

I could confirm that notification LED and USB storage works fine with lineage-16.0-20190713-UNOFFICIAL-smi. Thanks.
Still WiFi with storage encryption does not work.

julianwi said:
New build is up now.
Sorry don't have enough time to make a video in the near future. Maybe someone else can record a video of it
Click to expand...
Click to collapse
Alright, thanks. I bought my friend's RAZR i and I am planning to use it as a daily driver with this ROM (I'm a light user anyway), I can't thank you enough for making this LineageOS for such an old device. I wonder if such a recent Lineage has been developed for the 2011 Atrix, haven't seen one.
I have questions though, firstly I've never used a custom ROM before, can I simply follow the instructions on this thread to get it working, or is there anything that has to be done beforehand like rooting? Secondly, are any other OSs successfully booting on this x86 phone, as I can't find it on XDA? (it surprisingly hasn't gotten much attention as a hackable device like HTC HD2 or Nokia N900 got).

dumkm said:
I could confirm that notification LED and USB storage works fine with lineage-16.0-20190713-UNOFFICIAL-smi. Thanks.
Still WiFi with storage encryption does not work.
Click to expand...
Click to collapse
I know, haven't looked at the storage encryption for now. It will maybe be in the next update next month
flameseewa said:
Alright, thanks. I bought my friend's RAZR i and I am planning to use it as a daily driver with this ROM (I'm a light user anyway), I can't thank you enough for making this LineageOS for such an old device. I wonder if such a recent Lineage has been developed for the 2011 Atrix, haven't seen one.
I have questions though, firstly I've never used a custom ROM before, can I simply follow the instructions on this thread to get it working, or is there anything that has to be done beforehand like rooting? Secondly, are any other OSs successfully booting on this x86 phone, as I can't find it on XDA? (it surprisingly hasn't gotten much attention as a hackable device like HTC HD2 or Nokia N900 got).
Click to expand...
Click to collapse
If the phone never had a custom rom yet, you have to unlock the bootloader first. Description is in this thread: https://forum.xda-developers.com/showthread.php?t=1928551

julianwi said:
If the phone never had a custom rom yet, you have to unlock the bootloader first. Description is in this thread: https://forum.xda-developers.com/showthread.php?t=1928551
Click to expand...
Click to collapse
That's an old guide, will everything still work?

flameseewa said:
That's an old guide, will everything still work?
Click to expand...
Click to collapse
Yes, it should still work the same. If some links are outdated you can google them yourself

Thank you for bringing my old RAZR i back to life! I really appreciate the time and effort you spent for this obselete phone. Looking forward for more updates and for a bug free ROM. Using it now
dumkm said:
- Wifi with storage encryption
When you enable storage encryption, WiFi always become disabled, not be able to enable.
Just FYI, it required deleting /system/bin/pdsbackup.sh AND reducing partition size of 'data' (/dev/block/mmcblk0p17).
Click to expand...
Click to collapse
I'm not sure if I misunderstood but when you said "it required deleting....." and "reducing partition size of data", did you mean you can get WiFi to work if you do those things? I'm no expert at these but I can atleast apply the "fix" (if it really is) given that you guide me, if it's okay with you. Thanks!

[MODULE] Smali Patcher for native Android (Termux)

NOTICE: Apparently, fOmey intends to support native android through Xposed, making this obsolete and since he confirmed that the source code will not be available, this project can't be updated with reasonable effort anyways. TL;DR: sm4a is dead
WARNING: Currently sm4a is stuck on Smali Patcher 7.2 and (due to complications on my end, specifically the decompiler not producing usable code diffs) an update to 7.3 is unlikely without access to the proper source code of smali patcher. If you want to, you can try to clone the repo, revert the last few commits, decompile smali patcher and try to port over the changes yourself.
Smali Patcher is a Module created by @fOmey that allows for users to apply patches to their Android system, such as removing signature verification or making mock locations seem genuine.
While the tool is very useful, it requires a windows installation to be ran. That was the reason I decided to work on porting the program to linux.
However: In doing so I recognized that I could get it running entirely on android without dependency on any desktop system using termux.
If you want to try it out, I have provided instructions for installing my port here (tested only on LineageOS 17.1 for SM-A520F because that is my only phone, it should work fine on other devices though).
Please note that I had to make some changes to the internal logic of Smali Patcher to get this running so if you experience any problems you should ask me for support and not bother fOmey. I have also created a windows backport of my modifications here.
Also, feel free to mess with the source code.
Thanks to fOmey for creating his awesome tool and not threatening to sue me if I release my modifications.

Nice. Working for me

Hi @CreepycCrafter24
Nice 1st post!
Your work has been featured on the portal: https://www.xda-developers.com/smalipatcher-android-framework-without-pc/
Well done! ?
Sébastien.

Seems like an nice idea but...
Instructions unclear
Root/vdexextractor doesnt exist at all, neither i know what copy over to proot means (i just know it isnt a folder)
---------- Post added at 10:58 PM ---------- Previous post was at 10:46 PM ----------
Automatic install fails to bc it only refers to ubuntu, whilst the proot thing needs ubuntu-18.04 or ubuntu-20.04 as input

Dr. DoubtReaper said:
Seems like an nice idea but...
Instructions unclear
Root/vdexextractor doesnt exist at all, neither i know what copy over to proot means (i just know it isnt a folder)
Click to expand...
Click to collapse
The manual instructions are mostly there for advanced users that don't like automated installation scripts or for non-standard environments. If you just want it to work you should be able to use the automated install script.
Proot is the utility that allows the script to have an isolated environment with an openjdk install. By "copying over to proot" I mean copying the file into a directory that is easily accessible from the proot environment, such as usr/var/lib/proot-distro/installed-rootfs/ubuntu/home, which is the proots home directory
The thing with ubuntu-... is interesting because that exact script worked when I last tested it. Could you try upgrading your packages? (pkg update I think)

CreepycCrafter24 said:
The manual instructions are mostly there for advanced users that don't like automated installation scripts or for non-standard environments. If you just want it to work you should be able to use the automated install script.
Proot is the utility that allows the script to have an isolated environment with an openjdk install. By "copying over to proot" I mean copying the file into a directory that is easily accessible from the proot environment, such as usr/var/lib/proot-distro/installed-rootfs/ubuntu/home, which is the proots home directory
The thing with ubuntu-... is interesting because that exact script worked when I last tested it. Could you try upgrading your packages? (pkg update I think)
Click to expand...
Click to collapse
I actually tried used the automatic install but as i said it failed, so i moved to manual which is strange too...
Packages are all on latest
I would have attached some screenshots but xda says no

Dr. DoubtReaper said:
I actually tried used the automatic install but as i said it failed, so i moved to manual which is strange too...
Packages are all on latest
I would have attached some screenshots but xda says no
Click to expand...
Click to collapse
I just updated all packages on my side and "ubuntu" still shows up as a valid distro in proot-distro. I am confused. I guess you should try manually running the commands in the setup script and replacing the distro name

CreepycCrafter24 said:
I just updated all packages on my side and "ubuntu" still shows up as a valid distro in proot-distro. I am confused. I guess you should try manually running the commands in the setup script and replacing the distro name
Click to expand...
Click to collapse
Hmm, manual setup kinda doesnt work either , might need some eidts in the automatic script but ive no clue bout that

Automatic script fail at ubuntu unknown distro. I think the script should read "ubuntu-20.04"

$ proot-distro list
Supported distributions:
* Alpine Linux 3.12.0
Alias: alpine
Status: NOT installed
* Arch Linux
Alias: archlinux
Status: NOT installed
* Kali Nethunter
Alias: nethunter
Status: NOT installed
Comment: Minimal version, most of utilities should be installed manually.
* Ubuntu 18.04
Alias: ubuntu-18.04
Status: NOT installed
* Ubuntu 20.04
Alias: ubuntu-20.04
Status: installed
Note: ubuntu-20.04 installed manually

CreepycCrafter24 said:
I just updated all packages on my side and "ubuntu" still shows up as a valid distro in proot-distro. I am confused. I guess you should try manually running the commands in the setup script and replacing the distro name
Click to expand...
Click to collapse
AFAFontes said:
$ proot-distro list
Supported distributions:
* Alpine Linux 3.12.0
Alias: alpine
Status: NOT installed
* Arch Linux
Alias: archlinux
Status: NOT installed
* Kali Nethunter
Alias: nethunter
Status: NOT installed
Comment: Minimal version, most of utilities should be installed manually.
* Ubuntu 18.04
Alias: ubuntu-18.04
Status: NOT installed
* Ubuntu 20.04
Alias: ubuntu-20.04
Status: installed
Note: ubuntu-20.04 installed manually
Click to expand...
Click to collapse
Am I doing it right?

Truant_Luce said:
Am I doing it right?
Click to expand...
Click to collapse
Yes you have the distro installed already but if you want to use automatic setup you need to wait for the script to be updated or edit yourself because path and login are still wrong.

I changed the install script to reference ubuntu-20.04. You might need to run "proot-distro remove ubuntu-20.04" if you still have the proot from a failed install. Other than that it should now work.

CreepycCrafter24 said:
I changed the install script to reference ubuntu-20.04. You might need to run "proot remove-distro ubuntu-20.04" if you still have the proot from a failed install. Other than that it should now work.
Click to expand...
Click to collapse
Its proot-distro remove ubuntu-20.04 btw

CreepycCrafter24 said:
I changed the install script to reference ubuntu-20.04. You might need to run "proot-distro remove ubuntu-20.04" if you still have the proot from a failed install. Other than that it should now work.
Click to expand...
Click to collapse
Thought I'd share a screenie that I feel is most relevant. I did uninstall the old one and try again, to meet this end. Still unsuccessful.

Truant_Luce said:
Thought I'd share a screenie that I feel is most relevant. I did uninstall the old one and try again, to meet this end. Still unsuccessful.
Click to expand...
Click to collapse
I have added git to the required packages. You can try the install script again. Also note that the command "smalipatcher" won't work because the home directory is not in PATH so you will need to run "./smalipatcher" instead.

Is it possible to implement android 11 signature spoofing patch?
https://github.com/microg/android_packages_apps_GmsCore/pull/1222/files

kurtn said:
Is it possible to implement android 11 signature spoofing patch?
https://github.com/microg/android_packages_apps_GmsCore/pull/1222/files
Click to expand...
Click to collapse
This might be possible but currently I don't have the time to try to implement this. If you need it right now you can try to implement the patch yourself.
Otherwise I will look into it in the coming days

Another problem is that the downloaded ubuntu doesn't come with the build tools for building vdexExtractor (done in setup2.sh)
so you might need to additionally run ./smalipatcher-shell and run "apt install glibc-utils zlib1g-dev" inside it.
Tested on freshly installed treble havocOS with magisk.
Don't forget to give termux permissions for storage!
@CreepycCrafter24 might add those to the script.

CreepycCrafter24 said:
I have added git to the required packages. You can try the install script again. Also note that the command "smalipatcher" won't work because the home directory is not in PATH so you will need to run "./smalipatcher" instead.
Click to expand...
Click to collapse
I feel like I'm stress testing your patience for noobs. Lol. Linux isn't fully my forte, but I understand a little. I am learning. I appreciate your willingness in making this project.
New screenies for you.
Edit: I will say I somehow assume this is partly on my end, with just my phone I assume. But thought I'd share.