At XDA, we’ve been extensively covering the latest release of Google’s Android OS: Android 8.0 Oreo. Android Oreo brings a ton of new features, but the ones we’ve mostly been excited for are the under-the-hood changes. Things like Project Treble and system-wide custom theme support are two examples of Android Oreo-related changes that interest our readers. Another feature that Android enthusiasts have been looking forward to seeing in action is the new Rescue Party feature. This feature was touted by many to save your device from a bootloop, but the reality is far more disappointing. Rescue Party is not the bootloop fix you were looking for.
In reality, Rescue Party only works in a very limited situation, one that is very unlikely to matter to many users whose devices enter into a bootloop. This is especially true for nearly every user on our forum who encounters a bootloop – Rescue Party won’t help you. That’s not the fault of Rescue Party, though, because it was hyped up far more than it should have been considering what it actually does.
Rescue Party in Android Oreo – How it Works
Let’s start off with how Rescue Party is triggered. First off, Rescue Party needs to be implemented, which is not required by OEMs. On devices with Rescue Party support, the first check that happens is to see if the feature is even enabled, which may not be the case if the device is running on a debug/engineering build or if the system property persist.sys.disable_rescue is set to false in build.prop.
After the bare minimum parts of the Android OS have been started up during the booting process, the system determines if it needs to send a Rescue Party. As you may have already read before, a Rescue Party is sent whenever the device reboots more than 5 times in 5 minutes or a system app crashes more than 5 times in 30 seconds. Rescue Party then begins to increment through various “rescue levels” in an attempt to fix the reboot loop.
Here are the steps that Rescue Party can take:
Level 1 – Reset Untrusted Defaults
The first Rescue Party level is to reset any and all changes to the Settings.Global or Settings.Secure preference tables that are made by untrusted applications. Untrusted applications are those packages that are installed by the user. When this Rescue Party level is called, any change made by a third-party app will be replaced by its default value if it exists. If a default value doesn’t exist, then the setting is deleted.
The only way an untrusted application will even be able to modify a setting value in Global or Secure is if that application has root access or has been granted the WRITE_SECURE_SETTINGS permission via ADB. This isn’t that uncommon of a situation, though, as many of our very own non-root tutorials rely heavily on modifying these setting databases this same way.
An example of this Rescue Party level in play would be if the user was attempting to customize their navigation bar on Android Oreo. Doing this would require modifying Settings.Secure.sysui_nav_bar through a third party app such as Custom Navigation Bar. Now, modifying the nav bar through this method is unlikely to cause a bootloop, but if it did then this Rescue Party level would reset whatever change you made and replace it with sysui_nav_bar’s default value which is "left,back;home;recent,right".
Level 2 – Reset Untrusted Changes
The second attempt to fix the reboot issue is by taking level 1 a step further. Instead of just resetting any setting values that are made by untrusted packages, it will outright delete them all.
Level 3 – Reset Trusted Defaults
The last line of defense against bootloops offered by Rescue Party, level 3 will reset any changes made to Settings.Global or Settings.Secure value that have been made by trusted, ie. system, applications. It also attempts the changes made by earlier levels such as deleting changes made by untrusted packages.
Level 4 – Factory Reset
If all else fails, then the last attempt at fixing your device is to boot to the recovery and prompt the user to perform a factory reset. Although this action will likely resolve the bootloop (provided the bootloop isn’t caused by hardware issues like on the Nexus 5X or Nexus 6P), it’s obviously not ideal since it involves setting your phone up all over again.
Not a Bootloop Fix for you
So let’s summarize what Rescue Party actually does. Essentially, all it does is attempt to fix any erroneous changes made by the user or by system apps to the Settings.Global or Settings.Secure preference table. If your device enters into a bootloop because you flashed a botched audio mod, installed the wrong Substratum theme, enabled a Magisk/Xposed module that wasn’t for you, made a bad build.prop edit, or did any of the numerous things that a rooted user can do to enter into a bootloop, then Rescue Party isn’t for you.
If you somehow end up in a reboot loop by modifying a setting such as “Simulate Secondary Displays” in Developer Options, only then would Rescue Party actually help you. But I would surmise that the vast majority of our readers aren’t likely to have their bootloops resolved through Rescue Party. Unfortunately, the best way to deal with bootloops is to keep your data backed up on the regular, so you won’t ever have to deal with catastrophic data loss on your phone. Don’t count on Rescue Party to be your savior.
from xda-developers http://ift.tt/2fimoGO
via IFTTT
Aucun commentaire:
Enregistrer un commentaire