Related
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.
Hi,
I'm trying to automate the alert slider for my OnePlus 3 (Alert Slider module for Xposed isn't working anymore)
I found this: https://forum.xda-developers.com/oneplus-5/themes/tasker-alert-slider-enhancement-t3657510
But File Closed event profile isn't working. I've done some research and it seems it only works for SD Card filepaths
Is there any way to have a profile that checks if the /sys/class/switch/tri-state-key/state file was modified? Can Autotools do that?
Thanks
PS, My Tasker has root privileges
PPS, also, I can use %INTERRUPT, but I don't wan't to change to Priority, Alarms Only, etc. I'm on CM14.1 and I just want them all set to None
I think I would use a shell action and check the md5sum for the file. Compare it to a stored version and if different, it's been modified. Make sure to store the new value when it changes.
"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
ktmom said:
I think I would use a shell action and check the md5sum for the file. Compare it to a stored version and if different, it's been modified. Make sure to store the new value when it changes.
"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
Click to expand...
Click to collapse
Yeah, thought of that too but I need something that 'listens' for any changes in a /sys directory. A shell action needs to be triggered and I can't understand why File Closed and Read File (I used a shell action to replace Read File) isn't working on Tasker. Would it be because my phone is encrypted?
I don't think it has anything to do with encryption. Maybe selinux though.
I wonder if you could use "tail -f" or "inotifywait" in a termux script and update a tasker variable on change. Something similar to: https://glow.li/technology/2016/4/03/pass-variables-from-termux-to-tasker/
"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
ktmom said:
I don't think it has anything to do with encryption. Maybe selinux though.
I wonder if you could use "tail -f" or "inotifywait" in a termux script and update a tasker variable on change. Something similar to: https://glow.li/technology/2016/4/03/pass-variables-from-termux-to-tasker/
"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
Click to expand...
Click to collapse
Thanks for the input! I changed my SELinux to Permissive (using SELinuxModeChanger by MrBIMC) and Read File is working now.
But File Closed still isn't working. I also tried File Modified, no go. The file is indeed being modified and closed, albeit it's a system file /sys/class/switch/tri-state-key/state <-- no extension name
I just think (not saying I know) that monitoring system files is getting harder with each OS release since LP. If xposed modules aren't working then I'm not surprised that tasker has trouble.
AFAIK, there isn't a plugin that will add this monitoring as a context for tasker. That's why I was suggesting using what amounts to a Linux command within termux to set a tasker variable that you could monitor.
"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
ktmom said:
I just think (not saying I know) that monitoring system files is getting harder with each OS release since LP. If xposed modules aren't working then I'm not surprised that tasker has trouble.
AFAIK, there isn't a plugin that will add this monitoring as a context for tasker. That's why I was suggesting using what amounts to a Linux command within termux to set a tasker variable that you could monitor.
"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
Click to expand...
Click to collapse
Yep, I tried tail -f in terminal emulator just to test if it will display an output after moving the notification slider. But it seems it would just display an output if data is appended at the end of the file. The file content is being replaced (1=slider up, 2=slider mid, 3=slider bottom)
Is iNotify available as a command? or do I need busybox or something to make it work?
I use termux and inotifywait is a downloadable binary
"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
ktmom said:
I use termux and inotifywait is a downloadable binary
"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
Click to expand...
Click to collapse
Can you point me in the right direction on how to install the inotifywait binaries?
I've downloaded the inotify-tools-v3.14.tar.gz file from https://github.com/mkttanabe/inotifywait-for-Android and I don't know how to install it
Xaeons said:
Can you point me in the right direction on how to install the inotifywait binaries?
I've downloaded the inotify-tools-v3.14.tar.gz file from https://github.com/mkttanabe/inotifywait-for-Android and I don't know how to install it
Click to expand...
Click to collapse
https://www.google.com/search?q=how+to+get+started+with+termux&ie=utf-8&oe=utf-8&client=firefox-b
"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
ktmom said:
https://www.google.com/search?q=how+to+get+started+with+termux&ie=utf-8&oe=utf-8&client=firefox-b
"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
Click to expand...
Click to collapse
Got the binaries! Thanks!
And it still doesn't work.
I created the script for Tasker intent
I created the script that will monitor file changes
I tested the script on my storage location¹ and it fires off an intent when I modify the state file² using Solid Explorer to open the file using SE Editor³ then saving the file
I tested the script on the root location (/sys/class/switch/tri-state-key) and I don't know how the system updates the state file but it won't fire an intent.
I even removed all the events params in the monitor script so that any changes to the file would still likely fire off the intent script. No go.
Here are the scripts for anyone that can help me:
monitorslider.sh
Code:
dir=/sys/class/switch/tri-state-key
inotifywait -m $dir |
while read -r directory events filename; do
if [ "$filename" = "state" ]; then
sh test.sh 4
fi
done
test.sh
Code:
#!/data/data/com.termux/files/usr/bin/sh
#am broadcast --user 0 -a net.dinglish.tasker.[task name] -e [variable name] "[value]" >
#/dev/null
am broadcast --user 0 -a net.dinglish.tasker.slider -e position "$1" > /dev/null
¹-/storage/emulated/0/test
²-copied from /sys/class/switch/tri-state-key
³-built-in text editor of Solid Explorer
Pulling my hair on this one; I have rooted the tab successfully, flashed cAndroid 5.01 and it runs great, but won't accept any of the dozen version of Gapps (GPS stop, AOSP keyboard fail, Play Store Hangs, etc.) I have tried, so I thought, let's just try AOSP or cAndroid Nougat, which I have successfully flashed to my Nexus 7 2012 (note re-purpose addiction). Various sideloaded apks work with no issue on the 5.0 ROM, no google apps or services.
I am running CW Mod for flashing and SR5-SuperSU 2.8 for root and the AOSP Rom exits with Status 0, and the cAndroid exits with Status 7, and I am hesitant to edit the install script. Rootcheck show device rooted successfully.
Any help with either would be appreciated, ultimate goal is getting Onenote to run, again, which I have done for both 5.x and 7.x on nexus, using old APKs
Upate your Recovery to the TWRP Version >= 2.8.7.0..
Do you have a link for the twrp build for the gt-p7310, can't find it listed under twrp supported devices
thanks
Searched with every criteria I can come up with, can't find a .zip for GT-P7310 or p5wifi for >2.7
SOLVED
Found right copy of TWRP, installed and now running Nougat on the tab, thanks for the assist
Spoke to soon , update to 7.1.2 goes fine, but no keyboard works none of them will activate when a text field is tapped
You can actives the keyboard under setting, language and inputs , vituelle keyboards
Thanks for the update ; I have the device working properly now with 7.1.2 AOSP thanks to updating my TWRM ; everything works but anything Google or Microsoft - I have tried every version of GApps Zips, APKs GPS back to 10.0.8, Gmail, Play, Gboard, etc. and everytime I introduce anything Google , it flakes out, get service stopped messages from Play Services, Gboard stops, etc. Oddly enough GHandwriting works which i use alot on m other tabs with Onenote, which also won't run, I am assuming b c of GPS; Onenote installs passively, but errors out 8000400 evertime, which seems to be some kind of sign in error, but TS steps I have found have not worked. OTher than the Google and MS snafus, device runs better than ever and i am resolved to using Evernote and exporting over to one note when i need to, any ideas would be appreciated , I like the size of this device and hate to trash anything useful - Thanks for the reply
NOTE: This is only for Nougat (7.1) custom ROMs (such as Lineage 14.1 based)!
Make sure you do a proper nandroid backup before flashing!
I made a flashable zip for updating the libhoudini stuffs for Nougat (7.1) ROMs to 7.1.0a_y.49344. Not sure if this has been posted elsewhere before, though.
Before flashing, check your current libhoudini version by typing "houdini --version" either from adb shell or from terminal emulator. (UPDATE: Use the built-in Terminal as it doesn't work in Termux)
You should only try to flash this if your houdini version is below 7.1.0a_y.49344. Current custom ROMs usually have a houdini version of 7.1.0_y.48901 (DotOS 1.2 for example).
Flashable zip (It's about 34MB in size) (Dropbox link here)
The original source is from here, apparently taken from Nexus Player (fugu).
After flashing, "houdini --version" should report something like this:
Code:
[14902]
[14902] Houdini version: 7.1.0a_y.49344
[14902]
TESTING NEEDED: I'm not sure what this version of houdini might fix or break, so try this at your own risk. If you're currently not having problems with apps then there's no need to flash this. Compared with existing device files (7.1.0_y.48901, in /system/lib/arm/), several library files are changed, plus an additional "libgate.so" which I could identify it as being an ARM library file (so it'll also be placed in /system/lib/arm, although I'm not sure where it might be used).
EXPERIMENTAL (UNTESTED!): Here's another version in case someone might be interested. This build is 8.0.0_y.49374, and the version number literally means it's to be used for Oreo, so I'm not sure if it'll work on a 7.x ROM. The original source of this version is from Android-x86.
Flashable zip (Dropbox link here)
If the zip works, it should report the following version:
Code:
[19729]
[19729] Houdini version: 8.0.0_y.49374
[19729]
What is the use for this ?
PedroCaseiro said:
What is the use for this ?
Click to expand...
Click to collapse
It's just to put updated libhoudini libraries into the device, in hope that those updated stuffs might help with fixing some native libhoudini crashes on certain problematic ARM-only apps.
I had some ARM-only apps that always FC with native crashes (SIGSEGV) from libhoudini on Zenfone 2. Although the updated binaries unfortunately could not fix the problems entirely, at least the they work as intended as I haven't discovered anything broken by the updated stuffs yet.
However, this won't help if your app crash is due to the developer shipping an incomplete set of x86 native binaries (this can happen). You need to sideload it through adb and force it to use ARM abi, like this:
Code:
adb install --abi armeabi xxx.apk
Note that the abi name varies among apps, armeabi is just an example, it might be arm, or armeabi-v7a, depending on the app itself.
EDIT: Say, is there a way to report device incompatibilities to Play Store so I can explain the device's situation and let Play Store always ship the last known good version for our device? There seem to be some apps that previously worked, but not now due to updated native libraries that would cause native crashes on libhoudini (Play Store will still treat our device as compatible due to the device exposing the ARM abis thanks to libhoudini), and I often need to disable the app in question's auto-update to prevent Play Store updating it to the native-crashing version.
Running "houdini --version" in a terminal emulator results in:
"houdini: command not found"
for latest version of Groovy Android
deckinghalls said:
Running "houdini --version" in a terminal emulator results in:
"houdini: command not found"
for latest version of Groovy Android
Click to expand...
Click to collapse
Are you using Termux? It seems I'm getting the same result there as well, but houdini outputs just fine in the built-in Terminal as well as in the T-UI launcher.
And as for file lists:
In /system/bin there's the "houdini" binary.
Then there's "libhoudini.so" in /system/lib/ (this is the main library which is of i386 architecture).
And the rest of the files (ARM libraries) in /system/lib/arm/. These consist of the exact same set of files as the ones provided by the custom ROMs, plus an additional one (libgate.so).
LSS4181 said:
Are you using Termux? It seems I'm getting the same result there as well, but houdini outputs just fine in the built-in Terminal as well as in the T-UI launcher.
And as for file lists:
In /system/bin there's the "houdini" binary.
Then there's "libhoudini.so" in /system/lib/ (this is the main library which is of i386 architecture).
And the rest of the files (ARM libraries) in /system/lib/arm/. These consist of the exact same set of files as the ones provided by the custom ROMs, plus an additional one (libgate.so).
Click to expand...
Click to collapse
I am not sure what is meant by "the built-in Terminal" (I don't recall any ROM coming with one?) but I did use Termux as well as the terminal in TWRP. I figured out if you type "su" to get root access first, then the command works fine in Termux.
Flashed the .zip file. So far, I haven't noticed any changes, good or bad. I don't remember which apps would FC (maybe the Amazon Echo app and Disney Infinity 3.0?) but I'll keep you posted.
deckinghalls said:
I am not sure what is meant by "the built-in Terminal" (I don't recall any ROM coming with one?) but I did use Termux as well as the terminal in TWRP. I figured out if you type "su" to get root access first, then the command works fine in Termux.
Flashed the .zip file. So far, I haven't noticed any changes, good or bad. I don't remember which apps would FC (maybe the Amazon Echo app and Disney Infinity 3.0?) but I'll keep you posted.
Click to expand...
Click to collapse
Some ROMs do have built-in terminal app. However, you need to enable it, which can be done in Settings -> Developer Options (assuming you know how to enable Developer Options as well). There would be an option to enable "Local terminal" which is the built-in terminal app.
Which means it will help the x86 device run ARM ???
I do not understand. Please analyze me
Mkey_34 said:
Which means it will help the x86 device run ARM ???
I do not understand. Please analyze me
Click to expand...
Click to collapse
libhoudini is Intel's ARM binary translator that helps x86 devices run ARM apps, albeit with some limitations and performance reduction due to overhead. Without it, most apps won't be able to work at all, as they don't have x86 native libraries.
Zenfone 2 already has houdini included, that's why it could run as many apps as any other devices. The flashable zip here contains updated files (for 7.1 ROMs) in hope it could help with some problematic ARM-only apps that refuse to work with libhoudini, though in most cases the differences are barely noticeable.
LSS4181 said:
libhoudini is Intel's ARM binary translator that helps x86 devices run ARM apps, albeit with some limitations and performance reduction due to overhead. Without it, most apps won't be able to work at all, as they don't have x86 native libraries.
Zenfone 2 already has houdini included, that's why it could run as many apps as any other devices. The flashable zip here contains updated files (for 7.1 ROMs) in hope it could help with some problematic ARM-only apps that refuse to work with libhoudini, though in most cases the differences are barely noticeable.
Click to expand...
Click to collapse
Thank you
---------- Post added at 02:58 AM ---------- Previous post was at 02:53 AM ----------
something's wrong I can not download it. I need another link. thank you
My device is running Groovy Android 7.1.1, 18 May Build.
so i have successfully upgraded houdini version using your flashable file. Thank You for your work.
what if i want to revert to the houdini version that comes preinstalled with the rom, will dirty flash rom zip work?
sushuguru said:
what if i want to revert to the houdini version that comes preinstalled with the rom, will dirty flash rom zip work?
Click to expand...
Click to collapse
The zip is meant to be flashed every time you reflash the ROM, so yes, dirty flashing should be able to revert it.
But again... you're supposed to do a nandroid backup before flashing, and there's no need to flash this if you aren't encountering any native code crashes from arm-only apps at the moment.
Unfortunately, as Intel had already left the mobile market and no more Intel-powered smartphones produced anymore, some developers started to "move on" and use libraries or compiler options incompatible with houdini in order to make their apps run more efficient on modern ARM smartphones, without having to be "constrained" for compatibility reasons...
The houdini binaries I found only seems to be a minor update, and I'm not sure if Intel is still working on this or if there are possibilities to obtain an even newer houdini version with "y" suffix, which our phone uses.
Added an experimental (UNTESTED!) version found from Android-x86 (8.0.0_y.49374). This version was originally meant for Oreo, so I'm not sure if this would work on a Nougat ROM.
Currently on Android-x86 only the "y" version (which our devices use) is available. The other versions ("x" and "z") are not present, and the link would simply give you a "not found" error.
Although I don't mainly use the phone anymore, I could still conduct some tests with the device if I have time.
Bit the bullet and tested the 8.0.0_y.49374 build. Does not work. Evie force crashes right off the bat. Haven't tested further than this, but if I cannot even use my launcher of choice, that isn't a good sign.
All root applications need to be systemless to work on EMUI 9.1, old/classic root methods do not work anymore with the newest EMUI 9.1.
EMUI 9.1 introduces the EROFS filesystem for system partitions, which is a strictly read-only file system. This means no write support for anything using root to alter system files, you cannot permanently delete any system apps anymore. However, disabling system apps and bloatware is still possible.
Root features which aren't systemless such as the default hostfile adblocking (e.g. Adaway), root uninstallers, rw root file explorers, converting user apps to system apps, these all can't make (permanent) system changes anymore.
To make the adblocking work again in 9.1 you need to enable the Systemless hosts option in the Magisk Manager as a fix, reboot, and then apply the hostfile.
This also mean if you previously were running FakeGAPPS edxposed module with MicroG you can't do this anymore, as you can't uninstall the original gapps, therefore the MicroG the app signatures will conflict with microg, making it impossible to install. Edit: there is a systemless MicroG which runs instead of the system installed gapps, it's available in the Magisk manager (you still need edxposed and fakegapps for signature spoofing).
It makes me worry for EMUI 10/Android Q, Huawei really doesn't like custom software running on their phones.
EROFS file system
Dialaeialio said:
All root applications need to be systemless to work on EMUI 9.1, old/classic root methods do not work anymore with the newest EMUI 9.1.
EMUI 9.1 introduces the EROFS filesystem for system partitions, which is a strictly read-only file system. This means no write support for anything using root to alter system files, you cannot permanently delete any system apps anymore. However, disabling system apps and bloatware is still possible.
Root features which aren't systemless such as the default hostfile adblocking (e.g. Adaway), root uninstallers, rw root file explorers, converting user apps to system apps, these all can't make (permanent) system changes anymore.
To make the adblocking work again in 9.1 you need to enable the Systemless hosts option in the Magisk Manager as a fix, reboot, and then apply the hostfile.
This also mean if you previously were running FakeGAPPS edxposed module with MicroG you can't do this anymore, as you can't uninstall the original gapps, therefore the MicroG the app signatures will conflict with microg, making it impossible to install.
It makes me worry for EMUI 10/Android Q, Huawei really doesn't like custom software running on their phones.
Click to expand...
Click to collapse
It is for this reason that I quickly turned around and replaced 9.1 with 9.0. I am even looking at going to Oreo to be able to use TWRP. That will allow more flexibility instead of being restricted to how much one can customize his or her own phone. 9.1 may become unpopular with Huawei users.
cindybabe said:
It is for this reason that I quickly turned around and replaced 9.1 with 9.0. I am even looking at going to Oreo to be able to use TWRP. That will allow more flexibility instead of being restricted to how much one can customize his or her own phone. 9.1 may become unpopular with Huawei users.
Click to expand...
Click to collapse
Honestly, this update looks to me more like an update for Huawei and to push their own ecosystem, Huawei services and their HiVoice/HiTouch/HiWhatever crap even more, than it is an update for the users. They are trying to replace everything google with their own alternative and I don't think it's because they will play nice with my data and will be different than Google.
I also have a Huawei smartwatch if I set in the Huawei Health app that I live in the EU then I have to login with a Huawei account to use it, if I say I live in the USA I can still use it without logging in. Soon I might have a brick around my arm because I need an account to use my self-bought device unless I send all my health data straight to China. (To pair my GT watch to my phone I have to send my location or it won't link lmao)
I have the feeling they will start to hide more and more features behind a login screen to access, I am not a hypocrite, I don't use anything Google either, but I feel like I have less and less control over my data and phone... It's really a shame that the custom OpenKirin roms use a generic Huawei camera apk which isn't as good as the stock EMUI one and have some annoying papercut bugs (the OpenKirin developers are still amazing though for giving us a choice and creating a custom rom alternative).
When I bought my Mate 10 Pro you could still unlock your bootloader, and it seemed like it could be a popular device for tech enthusiast and they surgically killed all attempts to modify your own device since then...
And so we never got the big amazing community here that could have been supporting these phones, like the Oneplus phones.
Mostly we have been getting Magisk and all other nice features despite Huawei trying to being as difficult, and because of amazing developers who took the extra time to support EMUI.
I like the phone, it's great hardware, fast, amazing camera, a bit slippery and glassy to hold (but I have a decal on the back), but I wouldn't buy it again, or a different Huawei device for that matter. It's just much effort to do anything for me when you can do the same thing in twrp in two minutes.
-----------
Also it seems like you can install MicroG systemlessly through the Magisk Manager as module which 'overwrites' the gapps systemlessly.
cindybabe said:
It is for this reason that I quickly turned around and replaced 9.1 with 9.0. I am even looking at going to Oreo to be able to use TWRP. That will allow more flexibility instead of being restricted to how much one can customize his or her own phone. 9.1 may become unpopular with Huawei users.
Click to expand...
Click to collapse
Do you mind sharing how you downgraded back to 9.0? I am trying to downgrade my Mate 10 pro BLA-29 C432 from 9.1 to 9.0 or lower. Thanks
Crossover12 said:
Do you mind sharing how you downgraded back to 9.0? I am trying to downgrade my Mate 10 pro BLA-29 C432 from 9.1 to 9.0 or lower. Thanks
Click to expand...
Click to collapse
HiSuite lets you do that:
Update -> Switch to other version -> you'll get Earlier versions tab.
taddzio said:
HiSuite lets you do that:
Update -> Switch to other version -> you'll get Earlier versions tab.
Click to expand...
Click to collapse
Do you know if that this method will lock my bootloader? I am trying to avoid relocking my bootloader.
taddzio said:
HiSuite lets you do that:
Update -> Switch to other version -> you'll get Earlier versions tab.
Click to expand...
Click to collapse
IT is not working anymore, at this moment.