Related
In this method you will be able to activate your tethering hotspot only for a temporary period of time. First hotspot activate will work fine but once you turn it off you will be prompted with the entitlement check when you try to reactivate the hotspot. You will need to repeat the process again in order to bypass the entitlement check. So with that in mind lets begin.
(I AM NOT RESPONSIBLE FOR VERIZONS GETTING UPSET FOR YOU USING THIS FREE HOTSPOT!!!!)
In other words try to keep this method under VERIZONS knowledge and you should be fine.
Requirements:
You will need to have done CrashXXL`s root method to have a rooted Droid.
Then once you have a rooted device download SQlite editor which can be purchased on the Gioogle Playstore.
(NOTE: i will not post any download links for SQlite Editor due to XDA rules.)
Step1: Open Rsqlite editor then go to apps then Settings storage with the two tools icon. Now from there go to settings.db . Now go to secure and you`ll see a list of words and ids as well as value columns.
Step2: Change these exact values to the values listed below.
-dun_nat_enabled= enabled
-tether_reverse_nat_enabled= enabled
-entitlement_check= 0
-USB_entitlement_check= 0
-Network_settings_on_boot= 1
-APN_CHECK_STATE= 1
APN check state is the most important.
Step3: Once the values are changed reboot your device and you will be able to use the hotspot once then once you deactivate the hotspot itll check for entitlement check. So for now this is a temperary Hotspot method! Enjoy
My YouTube video tutorial: https://m.youtube.com/watch?v=A0Xc_z6vYXA
Easier method
This is only my first post, and I know that I might be missing something important, but there is an easier method to activate tethering for this device and firmware. While the xt1080 is not supported officially by kingroot, the app will grant temporary and limited root permissions (no /system access). This is enough to get the entitlement bypass app working on the device. I have attached the apks for the entitlement bypass and kingroot apps below. You can download the latest version of Kingroot from the official website. The entitlement bypass app will only run successfully once the device has been temporarily rooted by kingroot. While the root will not last, the bypass of the entitlement check for the tethering hotspot should remain in effect, until the next reboot. You should be able to use the hotspot without any problems until that point, at which time you will have to rerun the Kingroot app. This method has worked for me for months. I am on an xt1080 Droid Maxx running 4.4.4 SU6-7.2. Nothing else is required for this method. Although, the initial root may require a restart/retry or two. I hope this helps.
jamesbrogan85 said:
This is only my first post, and I know that I might be missing something important, but there is an easier method to activate tethering for this device and firmware. While the xt1080 is not supported officially by kingroot, the app will grant temporary and limited root permissions (no /system access). This is enough to get the entitlement bypass app working on the device. I have attached the apks for the entitlement bypass and kingroot apps below. You can download the latest version of Kingroot from the official website. The entitlement bypass app will only run successfully once the device has been temporarily rooted by kingroot. While the root will not last, the bypass of the entitlement check for the tethering hotspot should remain in effect, until the next reboot. You should be able to use the hotspot without any problems until that point, at which time you will have to rerun the Kingroot app. This method has worked for me for months. I am on an xt1080 Droid Maxx running 4.4.4 SU6-7.2. Nothing else is required for this method. Although, the initial root may require a restart/retry or two. I hope this helps.
Click to expand...
Click to collapse
I've spent a lengthy period of time trying to get tethering to work on a broken screen MAXX, because I refuse to finance a new phone to Verizon. This entitlement app worked perfectly. So I am not able to tether the connection to a prepaid phone and forward my calls to the prepaid device and use my TWC Phone2go.
Thank you
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've search the forums but apart from finding several people with the same issue, i didn't find anything useful.
I'm running LOS14.1 on a OP3 with latest Magisk. Safetynet passes but the MS Intune company portal seems to be detecting that the device is rooted. Turning off root however is not fixing this. Any idea on how it detects this or are there solutions via Magisk for dealing with this (or other solutions off course).
Regards
Mrhubris
mrhubris said:
Hi
I've search the forums but apart from finding several people with the same issue, i didn't find anything useful.
I'm running LOS14.1 on a OP3 with latest Magisk. Safetynet passes but the MS Intune company portal seems to be detecting that the device is rooted. Turning off root however is not fixing this. Any idea on how it detects this or are there solutions via Magisk for dealing with this (or other solutions off course).
Regards
Mrhubris
Click to expand...
Click to collapse
I am on stock Lollipop rooted using Magisk 11.6. Outlook wouldn't start for me even though magisk hide was enabled and safetynet passed. I used the Tasker app to get around the root check with the with the following tasks:
Launch App (Outlook)
Run Shell command:
su
chmod 0754 /data/magisk
sleep 25
chmod 0755 /data/magisk
This launches the outlook app and changes the permissions of the magisk folder for 25 seconds so that when it does the root check after I input my pin everything checks out. After 25 seconds it restores the permissions to what they were, and root continues to work. I exported this as an app (long hold on task, click menu in upper right and export as app) and it seems to work like a charm.
I tried changing permissions on the individual files in the /system/data/magisk folder, but that didn't work. changing the permissions on the whole /system/data/magisk directory to 0754 seems to do the trick.
You can also use a root file manager to change the permissions, but you have to be careful because if the file browser loses its root privilege before changing the permissions back, you will lose your root capabilities until rebooting into TWRP recovery to do a chmod 0755 on the magisk folder. It's more inconvenient than having tasker do it, but it works.
Hope this helps somewhat.
The only issue I'm having is that tasker seems to be a paid app. I'm not willing to pay money if I'm not sure it works.
This is why asked the question. In the other threads I read it was clear that this is not always working so I asked the question in here specifically for magisk.
Regards
Mrhubris
mrhubris said:
The only issue I'm having is that tasker seems to be a paid app. I'm not willing to pay money if I'm not sure it works.
This is why asked the question. In the other threads I read it was clear that this is not always working so I asked the question in here specifically for magisk.
Regards
Mrhubris
Click to expand...
Click to collapse
Tasker is definitely worth it! If you're worried you can try by doing the chmod manually first.
@dizzybrow
Thank you! Purchased Tasker just to do this and it worked!
dizzybrow said:
I am on stock Lollipop rooted using Magisk 11.6. Outlook wouldn't start for me even though magisk hide was enabled and safetynet passed. I used the Tasker app to get around the root check with the with the following tasks:
Launch App (Outlook)
Run Shell command:
su
chmod 0754 /data/magisk
sleep 25
chmod 0755 /data/magisk
This launches the outlook app and changes the permissions of the magisk folder for 25 seconds so that when it does the root check after I input my pin everything checks out. After 25 seconds it restores the permissions to what they were, and root continues to work. I exported this as an app (long hold on task, click menu in upper right and export as app) and it seems to work like a charm.
I tried changing permissions on the individual files in the /system/data/magisk folder, but that didn't work. changing the permissions on the whole /system/data/magisk directory to 0754 seems to do the trick.
You can also use a root file manager to change the permissions, but you have to be careful because if the file browser loses its root privilege before changing the permissions back, you will lose your root capabilities until rebooting into TWRP recovery to do a chmod 0755 on the magisk folder. It's more inconvenient than having tasker do it, but it works.
Hope this helps somewhat.
Click to expand...
Click to collapse
I can use Outlook app without Magisk Hide, I don't understand why you need do that.
Deic said:
I can use Outlook app without Magisk Hide, I don't understand why you need do that.
Click to expand...
Click to collapse
Each company has different policies. Also some don't use intune (maybe that's you).
Time for another update.
The problem is not necessarly the oulook app. It's the Intune Company Portal that's closing everything up. Is there a way around this?
From my experience it even trips on unsigned custom roms. Currently Paranoid Android is the only one not giving me problems.
as far as i can tell it detects:
- signed / Un-signed
- root (the binaries itself). Disabling root results in the exact same error notification
If magisk.hide is enabled for the app, there is no way it will detect the root binaries.
Detection could be due to the build props .. ones such as
ro.build.tags=release-keys
ro.build.type=user
Have you tried setting the above build.prop properties to the value mentioned above. These are not set like this for custom roms.
You may try the attached magisk module to set these.
Changing these build props is not working.
Root beer sample is still detecting dangerous props and safetynet is also triggering.
mrhubris said:
Changing these build props is not working.
Root beer sample is still detecting dangerous props and safetynet is also triggering.
Click to expand...
Click to collapse
Then you have some other issue. Both, root bear and safteynet should pass easily with magisk on custom roms.
candiesdoodle said:
Then you have some other issue. Both, root bear and safteynet should pass easily with magisk on custom roms.
Click to expand...
Click to collapse
Intune is just detecting specific aspects and the company i work for says that in those cases no configuration (of email for example) is allowed to happen.
But i've got no clue as to what it is detecting.
If i run Paranoid Android as a ROM it is possible. If i switch to LineageOS or Resurrection it's not.
Somehow the setup of these ROM's differs in a way to MS Intune trips or not. Is it possible to figure this out in some way?
I having same problems too but with onedrive, atm at work we are testing intune and now it would not let me use onedrive as the intune app detects root...
It could be detecting apps that require root as a secondary check, do you have anything like root explorer , Titanium backup etc ?
Sent from my ONEPLUS A5000 using Tapatalk
For me, It's detecting something in sbin even though magisk unmounts it. If I remove read or execute permissions from sbin then Company Portal and all associated apps launch just fine. Of course nothing that needs root works anymore since without those permissions nothing can access su or anything else needed for root.
Sent from my Nexus 6 using Tapatalk
i found out @dizzybrow fix works in magisk 11.6 but not 13 (didn't try 12). i'm staying on 11.6 just for this reason.
Any better ways to fix this problem?
illwafer said:
i found out @dizzybrow fix works in magisk 11.6 but not 13 (didn't try 12). i'm staying on 11.6 just for this reason.
Click to expand...
Click to collapse
So you are using Magisk Hide on 11.6 and Intune is not detecting root? I tried that and it didn't work for me.
Anyone else have any ideas?
Are you using Tasker with the variables provided by dizzybrow? If so, it should work with 11.6 (safetynet still fails).
illwafer said:
Are you using Tasker with the variables provided by dizzybrow? If so, it should work with 11.6 (safetynet still fails).
Click to expand...
Click to collapse
I am trying to, but I am not all that familiar with Tasker, so apparently I am doing something wrong. I would appreciate any assistance as far as setting it up correctly.
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.
Well... I bit the bullet and decided to update to android 11 from 10. After the update I lost my net.tethering.noprovisioning=true stuff. I remember having access through terminal emulator but now nothing I see online works to get me tethering again. Did Android 11 break that ability and do I need to revert? I of course followed all the steps of adding custom props via emulator and adding that tethering_nun line. Nothing holds after rebooting. Also the "Tethering enabler 15.0.0" module doesn't work. Does anyone have any advice?
Pixel 4xl unlocked
Verizon (but not a Verizon device)
If this is the wrong place for this, I'll move it
When I was on Android 11 on my pixel 4 the tetherenabler module worked fine.
But I've upgraded to Android 12 and have yet to root. But I discovered something interesting. Hot spot works natively without the need for any modifications.