Related
Okay, so I've seen these issues dealt with separately, but never in conjunction. Unfortunately, I am having both in conjunction.
Starting with a fresh Droid Eris, I used a one-click root to allow superuser permissions.
From there, I flashed CM7. Along with many other users, I ran into the issue where I had no data or voice signal.
I'll let you know here, that I've wiped EVERY time I did anything. This is NOT a wipe issue.
I flashed the newest radio... No luck. So, I went through clockwork's recovery and reverted back to the original 2.1 ROM. Still no luck on the signal issue. At this point, I decided to reflash CM7 and try to deal with the issue through ADB.
This is where things went wrong. The load for CM7 corrupted (I'm assuming) and gave me a nice case of Bootloop. Thinking everything was fine, (Assuming I'd do a battery pull and just go back to 2.1) I booted into the original Android recovery and NOW the damn track ball will no longer make selections. It will scroll, but not select.
Here's my question: Seeing as I can not boot fully to allow usb debugging, and I can not recover through Android (Thank you, trackball), is there ANY way to reflash the original RUU through ADB?
Thus far, I can't get passed the obvious "This device is not ready," prompt.
Any help is greatly appreciated.
FYI, adb is available when the custom recovery is booted.
what that means is that with the recovery booted you can:
1) drop a smallish (say, less than 100 MB) ROM file into /cache (e.g. "adb push")
2) create an Android command file (/cache/recovery/command) with a single line that points at the ROM file as an update
3) do a "adb shell reboot recovery"
This will cause the subsequent boot to the recovery to automatically install the ROM file you dropped in cache.
Voila. No trackball needed.
The syntax for the command file (/cache/recovery/command) will be a single line:
--update_package=CACHE:your_ROM_file_name_goes_here.zip
See this post for an expanded explanation.
cheers
[ Edit ]
Note that the above is a thumbnail sketch which requires you to fill in the blanks. For instance, wiping /data and /cache and flashing packages after the main ROM. Cumbersome, but you only need to do it once. Once you have a rooted ROM installed, you should flash a trackball-free version of the recovery so you don't need this method for every ROM you install. Instructions for that (using "flash_image" via adb) can be found elsewhere.
Scott,
Whoa! You got a lot going on there...
Okay, I don't have all of the answers here for you, but I know enough to ask a few questions that we'll need a clarification on.
1. Can you tell us your HBOOT version and whether its S-ON or S-OFF?
2. You mentioned that you've used ClockworkMod (not good , but maybe not terrible)...you also have mentioned using/having Amon_RA custom recovery. Which custom recovery do you have currently installed and can you boot into said recovery?
3. By the way, I think the voice/data signal thing is fixable--it sounds familiar to me, but I don't know the answer right off-hand and this is not your primary issue at the moment.
4. You should be able to run the RUU to restore 2.1 back to your phone. It doesn't require a working custom recovery running and/or adb. Although you might simply be asking if you can flash a ROM through adb, then the answer is yes, you can. Although you will need custom recovery running to make sure its adb server is running and that, of course, require USB connectivity (alluding to your "This device is not ready." message).
5. Usually, installing HTC Sync will install the USB drivers necessary for you to use adb. If that doesn't work for you, PM me with your email address and I'll send you about 10MBs worth of USB drivers I've collected over the last year that might help you with this issue.
6. Lastly, there is a version of Amon_RA's custom recovery available that does not require the use of the trackball. You're not really in a position to flash/install that at this point unless you have the S-OFF engineering bootloader.
I'll hold-off with additional info pending your responses to the above.
Cheers!
edit: trumped by the Master himself, LOL! [I knew you'd be along sometime soon, bftb0 ]
scary alien said:
Scott,
Whoa! You got a lot going on there...
Okay, I don't have all of the answers here for you, but I know enough to ask a few questions that we'll need a clarification on.
1. Can you tell us your HBOOT version and whether its S-ON or S-OFF?
2. You mentioned that you've used ClockworkMod (not good , but maybe not terrible)...you also have mentioned using/having Amon_RA custom recovery. Which custom recovery do you have currently installed and can you boot into said recovery?
3. By the way, I think the voice/data signal thing is fixable--it sounds familiar to me, but I don't know the answer right off-hand and this is not your primary issue at the moment.
4. You should be able to run the RUU to restore 2.1 back to your phone. It doesn't require a working custom recovery running and/or adb. Although you might simply be asking if you can flash a ROM through adb, then the answer is yes, you can. Although you will need custom recovery running to make sure its adb server is running and that, of course, require USB connectivity (alluding to your "This device is not ready." message).
5. Usually, installing HTC Sync will install the USB drivers necessary for you to use adb. If that doesn't work for you, PM me with your email address and I'll send you about 10MBs worth of USB drivers I've collected over the last year that might help you with this issue.
6. Lastly, there is a version of Amon_RA's custom recovery available that does not require the use of the trackball. You're not really in a position to flash/install that at this point unless you have the S-OFF engineering bootloader.
I'll hold-off with additional info pending your responses to the above.
Cheers!
edit: trumped by the Master himself, LOL! [I knew you'd be along sometime soon, bftb0 ]
Click to expand...
Click to collapse
Yup bftb0 is a beast at these things, lol
This Guide has been written to aid users both old and new as a generalization of how the entire process of phone customization works. It is useful and relevant knowledge that will aid in the process of unlock, root, flash, and recovery. This is not a tutorial on unlocking your HBOOT, nor is it a tutorial of how to root your phone. It is a list of things you should know before, during, and after you complete the process. Below is everything I could think of to help guide you as you attempt to obliterate unlock your phone. There are risks involved and you may end up with an unusable device, this is not to be taken lightly. However I have included a basic troubleshooting guide as well. Should you run into trouble, it lists some of the most common issues. If all goes well then congratulations on unlocking your device.
ROOT This is a term used for everything here. Basically there are areas of your phone that are locked out. Root gives you admin or superuser privledges that can be used to modify things like build.prop or app data that you could not normally access. Typically during to root process an app is installed on your phone that governs which apps are given exclusive superuser privileges to modify your system. Superuser by CHAINSDD and SuperSu by CHAINFIRE are the only two apps I'm aware of.
S-OFF Security off, Basically the Holy Grail of Android customization. This disables the security allowing you to directly modify the NAND memory of your device. This in turn allows you to apply patches, device drivers and other niceties not normally available. This is why developers work tirelessly to enable S-OFF (Be sure to thank them for their amazing work).
HBOOT - This is your boot loader and is very similar to the BIOS on a PC, it basically performs POST (power on self test). It is responsible for flashing official software releases, enabling FASTBOOT and is basically the bouncer outside a club. This is what initially stops you from flashing unsigned code to your phone. OEMs have begun offering tools to unlock your boot loader and enabling the use of fast boot. Examples include HTC DEV Unlock, Samsung Odin, and Motorola's Unlock My Device.
Note: Depending on the security of your HBOOT you may or may not have access to the boot partition. Best example would HTC's HBOOT software. Unlocked it only offers access to FASTBOOT which in turn allows for recovery and flashing of ROMs. It does block flashing radios and other firmware
What does upgrading your HBOOT do? It adds support for new hardware (future phones) or fix bugs (break any chance you have of S-OFF, it may also bed your significant other but I have yet to confirm)
Should I upgrade my HBOOT? If a new firmware is released they may contain bug fixes, new radios, or newer versions of Android. If you want S-OFF and have yet to obtain it, no. Developers may find an exploit that can be used to obtain S-OFF. If you are stuck with S-ON and are waiting for S-OFF, again the answer is no. Developers may find an exploit to obtain S-OFF. If you don't care about obtaining S-OFF and you want to update your firmware, flash new radios, or simply want the bug fixes then this is the only option you have while S-ON if you are running stock. The only real benefit comes from what you can not flash with S-ON, basically radios or update for various drivers.
What does downgrading my HBOOT do? It falls back to the previous version of HBOOT, in some cases developers have released tools to downgrade to a previous HBOOT allowing users to then exploit the older boot loader and achieve S-OFF. Some people with S-OFF will upgrade but there is no real benefit, it often causes more problems with ROMs. They then attempt to return to previous HBOOT (very real potential for bricking your phone)
How do I upgrade my HBOOT? By installing an OTA or by using official ROM Upgrade Utility (RUU) To my knowledge there is no other method for upgrading HBOOT
Why do I need to downgrade HBOOT? As of right now, you don't. Do not trifle in what you do not understand.
Does rooting my phone require a certain HBOOT? Root is not dependent on HBOOT
Help, I upgraded my HBOOT and lost root! HBOOT has nothing to do with removing root, the RUU replaced your ROM with one that doesn't have superuser privileges.
RUU ROM Upgrade Utility, this is used to update your phone or revert it to a OEM factory state. The most common use of RUU in the community is to restore the original recovery and or re-enable S-ON
RECOVERY A very small type of operating system that resides on a part of your phone that is separate from Android. It is used by OEMs to install official OTA updates. Developers have created custom recoveries such as CWM, Amon Ra, and TWRP that allow a user to flash unsigned ROMs to the phone allowing for a greater degree of customization not offered by the stock operating system.
Nandroid Also referred to as a system back up. This is a copy if your phone's current system state. It creates duplicate images of your kernel and system including system settings, apps and app data, userdata, and or any mods. First and foremost, this is the most important thing to do after you flash recovery and before you flash a ROM. Should anything go wrong during the course of flashing a new ROM package (ROM/Kernel) and or should you wish to return to a stock state, restoring a Nandroid is the easiest and most effective way. Always be sure to back up your current system state prior to flashing a new ROM and or Kernel.
Note: Using Flash Image GUI will replace kernel from within OS. Be sure to create Nandroid before using this app to flash a new kernel.
ROM A package consisting of a boot image (kernel) and a system image (AOS or Android Operating System, I will now refrain from calling it AOS in fear that Apple may ruthlessly try to sue me for infringing on such a broad generalization to an operating system). ROM broadly refers to all of the phone's software. A custom ROM is any ROM that is modified from stock OEM or AOSP (for good measure, Android Open Source Project)
AOSP vs STOCK
AOSP Pure untainted Android OS maintained by users who want a clean open source mobile OS that is available for everyone. This is the base for ROMs like CM10 or Kanged. This is also the starting point for all OEMs
STOCK A build of Android that has been customized by an OEM. At first manufacturers used the opportunity to build custom skinned versions of Android. They supplied custom apps which they packaged into the ROM separate from the apps available in the market as a means to include exclusive features. This started a fierce competition between manufacturers who began making radical changes to the lowest levels of Android, including the kernel and framework. This led to slow, unreliable devices (frustrating for many developers who only have one real world device) that may have great hardware but poor software. In order to satisfy carriers OEMs may remove features or add many unwanted features. The most prominent issue stemming from this practice has been the Carrier IQ debacle. Roms like Venom and Mean use stock as their base.
Note: The most recent changes done by HTC and other OEMs are so extensive that they now offer their own SDK (Software Development Kit) for app developers to be able to write applications that are compatible with their framework
Kernel It is the layer between software and hardware. It allows the hardware and software to communicate with each other. The kernels must match the ROM Base and Version. Sense with Sense, AOSP with AOSP, ICS with ICS, Jelly Bean with Jelly Bean
CPU Governors A CPU Governor controls the frequency of the processor in response to the workload placed on it. If your phone supports multiple forms of governing, You will have the option to choose how it affects the performance and battery power consumed.
On Demand Pretty much the standard governor. The way it work is by ramping up the frequency to max in order to ensure responsiveness and then sampling the work load and scaling down the frequency to match. This is done by setting maximum frequency when the CPU is busy and gradually scales down as CPU reaches idle.
Interactive Governor Similar to On Demand, Interactive will dynamically scale the clock frequency as the workload demands. This is where the similarities end however. Rather then ramping clock speed to max when CPU is busy, interactive determines how to scale the CPU as it comes out of the idle state. When the CPU leaves idle, the governor sets a timer (pre-set by the developer). If the CPU use is intensive between leaving idle and timer expiring, governor will assume the system is under clocked and ramp to max frequency. It is better suited to handling intermediate clock speeds. Think of this as a faster, smarter On Demand
Performance I got a fever, and the only prescription is more cowbell! This sets the min frequency to the max. Your phone will burn, your battery will spring a leak, and you will see insane benchmark scores. This is obviously not a day to day solution.
Power Save Is anyone home? This will set you max frequency to your min. What a bore.
User Space This allows the user to set the frequencies. Better suited to the more advanced users
Input/Output Schedulers Determines "who goes first" by assigning which operations go to the storage volumes.
NOOP Scheduler This scheduler works on a sort of "first come, first serve" basis and will implement request merging. Its best for solid state drives and good on DB systems. It uses the least amount of CPU cycles per request. The one flaw I can see straight away is "less cycles = less performance"
Deadline Scheduler Used to minimize latency, it reserves five queues and schedules all I/O operations accordingly. This is an aggressive scheduler that runs at near real time speed. It is great for reducing latency and like NOOP, works best on solid state drives, db systems, and reduces latency in any I/O request. When system becomes taxed, this scheduler becomes very unpredictable.
Completely Fair Queue Scheduler This scheduler is scalable per I/O Queue, it distributes I/O bandwidth to all I/O requests fairly and equally. It helps maintain balanced performance through out and is great for multiple processors. The problem is when too many requests are competing for bandwidth, performance degrades.
Simple Input Output Scheduler This is as plain as it gets. No priority queues, no reordering or sorting requests, and the most basic merging. Minimum latency and low overhead, this is a simple and reliable scheduler.
BFQ Scheduler I would rather not risk getting into trouble with this acronym, lets just say the B is for brain and the F is a no-no word. I have not really used this scheduler but it's supposed to be good for USB data transfer, high definition video recording, video streaming, and is a fairly reliable scheduler. In my personal use I didn't get very good results.
MD5 It is basically a finger print for files, the developers use this to help regular users verify the integrity of the file. Most recoveries already support MD5SUM to prevent users from flashing corrupt files. Always verify the MD5 of any Kernel or ROM before flashing it to your phone
How to verify MD5 Hash
In Windows Like most useful utilities in Windows this is not supported, you can download a small utility that will load the file and display the Checksum Hash needed to verify.
In OSX Open a terminal and navigate to the folder your ROM is in and type md5 filename.ext
In Linux Again open terminal, navigate to folder and type md5sum filename.ext
In Android Open a terminal emulator, navigate to folder and use the same command used in Linux. Not surprising as Android is Linux but really neat! There are also apps for checking MD5 Hash Sum
Crossplatform Download managers and manager extensions for browsers like Firefox and Chrome may come with Checksum built in
Recovery As stated, most if not all recoveries will verify checksum hash. It is still good practice to verify by other means to avoid a bad flash
ROM Downloaders I don't really trust these or any large download on Android, sue me. Downloader apps should have a means to verify hash
NAND or N(OT) + AND Named after its basic operating principle, it is a form of non-volatile flash memory. Devices such as USB drives, cameras, mp3 players, and cellphones use NAND to store necessary firmware/software needed to operate. On Android phones the NAND memory is what holds all the information that powers your device. It is divided into separate partitions that are used to store firmware, the kernel and the system along with any other information such as contacts and cached data.
The Partitions are as follows
BOOT This Partition holds the HBOOT and Kernel and as the name suggests, is responsible for the allowing the phone to start. This is the most important Partition in your NAND memory.
SYSTEM This Partition is what holds our beloved Operating System. It contains the entire Android Operating System and the apps that come preinstalled on our phones.
RECOVERY Recovery can be thought of as our alternative boot partition. It holds the advanced recovery console that we need for flashing our phones.
DATA Also refered to as user data. This partition holds our contacts, messages, apps, and settings.
CACHE This is for the temporary storage of frequently used app components and frequently used data.
MISC This contains various bits of information like CID (Carrier or region identification), hardware configurations and various hardware/system settings.
SD_EXT Not to be confused with the Ext-SD shortcut on some phones (a way to access the external SD) This is not a standard Partition, it is an additional partition stored or your SD card that acts as another data partition. This allows you to install apps on your SD card and store data relative to the apps installed.
ADB Android Debug Bridge, it is used for development purposes but it has its usefulness
adb push This allows you to copy a file or directory to a phone
adb pull This allows the opposite, copy a file or directory from the phone
adb sync Copy host - phone if there are any changes present
adb logcat View phone log
adb install [ -l ] [ -r ] < file name > Push package file to phone and install it (-l means forward lock the app, -r means reinstall the app keeping its data)
adb uninstall [ -k ] Removes app package from phone (-k means keep data and cache directories)
adb reboot [bootloader] Reboots phone into the bootloader
adb reboot [recovery] Reboots the phone into the recovery
FASTBOOT A command line interface that can be used to directly flash the file system in Android, it is quite possibly the most reliable method to use if you know what you are doing. HBOOT must be unlocked (OEM or S-OFF) to have access to FASTBOOT
fastboot devices List all connected devices/phones
fastboot update Flash/re-flash a phone from update.zip
fastboot flashall Flash boot, recovery, and system
fastboot flash Flash a specific partition (partitions are boot, recovery, system, cache, and userdata)
fastboot erase Erase specified partition
fastboot reboot Reboot phone normally
fastboot reboot-bootloader Reboot into bootloader
fastboot -w Erase cache and userdata
fastboot oem lock Relock the boot loader
Flash Image GUI Created by member joeykrim, it is an Android app used for flashing recoveries and kernels from with in Android ROM. This is an easy to use tool for OEM Unlocked (S-ON) users to replace/update the kernel and or recovery before rebooting into recovery to switch ROMs. I have not used this myself so I can not determine how safe it is. Always verify MD5SUM
HTC Dumlock Created by TeamWin as a means to flash phones with OEM Unlock (S-ON) on HTC devices with HBOOT that do not allow for boot partition to be flashed. It is built in to TWRP, TeamWin also offer a Universal Dumlock solution compatible with other recoveries. It is probably the safest method for new users despite its seemingly complex nature. It is installed from recovery and run from within Android similar to Flash Image GUI but does not flash kernels. It makes a back up of your boot and recovery and then it takes the back up recovery and writes it to boot from within OS, your phone will then reboot (some phones must reboot manually, do not boot to recovery). From here on the recovery is running from within boot, you must then restore boot and then you will be allowed to flash a ROM like you would if the phone was S-OFF. Be aware that this is not the most ideal method as it writes to your boot partition 3 times (recovery, then restore boot, then kernel). Still this is the most flexible method for new users.
Uniflash Created by member MihailPro, this utility is a veritable swiss army knife of Android customization. It is basically several tools rolled into one. It supports and automates adb, fastboot, image editing/creation, manipulation of file system, back up and restoration of NAND partitions.
Features:
Flash
flash core (My guess is this is the flashall command; boot, system, recovery)
flash recovery
flash splash
flash radio
flash official and custom firmware (updates, patches and zip files)
Modify
edit Build.Prop
remove bloat
install or remove custom applications
copy to and from the device (internal, external memory) with the option to delete files
wipe user data, cache and perform factory reset
Image Creation
Basically back up and recovery
Note: This application is not compatible with HTC Sync, in order to use it please uninstall sync. Those of us with HBOOT 1.15+ still can not modify certain aspects of the memory but this application should at least make it easier to fastboot flash kernels, recovery and or ROM
PRI Product Release Instruction, the protocol used for the transmission of voice and data across Sprint's cellular networks. It may be updated from time to time to improve battery life and/or performance. It will also be updated when any drastic changes are made to the network. This directly affects the performance of your phone's voice and data
PRL Priority/Preferred Roaming List, It is a database used primarily by CDMA networks. It provides a list of network identifiers(service providers), wireless bands, and sub bands used to select the best service for roaming (example of bands/sub bands: PCS wireless band is 1850mhz to 1990mhz, divided into 6 blocks I believe. Sprint uses 1900, Block G if I'm not mistaken). Rather then giving you the best and most reliable option, the carriers choose which service providers to use (they have roaming agreements which help keep company costs down).
NV Non volatile memory, it contains info for MEID/ESN/EVDO and other credentials.
Radios These are basically drivers for the radios on your phone (basically firmware) They pertain to CDMA/EVDO, WIMAX, LTE, BLUETOOTH, WIFI and even NFC. They may be updated with patches or bug fixes to improve battery life and or performance.
Note: The only means of flashing new firmware on S-On unlocked devices is by using official HTC software
Basic Troubleshooting
**Please take the time to read all the relevant info I have posted prior to reading the troubleshooting section. I promise it will help you to better understand your phone and that is the entire purpose of this guide**
Note: To those of you with CWM Recovery, it is recommended that you use TeamWin Recovery as it is better suited for our phones.
Brick This is a very serious problem, your device is catatonic and will not respond to the usual methods of power on/off or sim-pull. In some cases the phone comes back when the battery dies and is recharged, this isn't very often. There are un-bricking tools written by OEMs when they screw up (Samsung / Motorola) and there are tools written by developers working on S-OFF. They notice a very real danger and will supply the tool just in case (this is not possible in all cases). Bricking can and will be permanent in many situations
Boot loop There a different kinds of boot loop situations (also referred to as soft brick, please do not cry brick in the forums if it is a boot loop) the most common are a mismatch of kernel and ROM.
Help, my phone is stuck in a boot loop or my phone is stuck on HTC! Not a problem at all. Hold down the power button and continue to hold it, the capacitive buttons will begin flashing and phone will reboot. After the screen turns off let go of power for one second and the press and hold power and volume down to boot into the boot loader. This is known as a simulated battery pull. HTC built this in as a fail safe to reboot your phone, and it gives us a chance to jump into the boot loader should anything go wrong. Once you have successfully made it to the boot loader read through these forms of boot loop to understand what went wrong.
Known forms of boot loop
Generic Boot loop You have a working recovery and now you have installed your first ROM. There's just one problem every ROM you try boot loops but if you restore your back up and it runs fine. This is common when you haven't taken the time to wipe your phone before you flash. You can use a wipe script to clean your phone or you can systematically wipe Dalvik, Cache, Factory Restore, and then wipe System. Now you can flash your custom ROM (HBOOT 1.15+ requires you to flash the kernel separately)
Help my phone won't boot past the splash screen similar to a generic boot loop, the most common fix is to wipe the phone before flashing your ROM. Wipe your dalvik and cache, the factory reset and wipe system. You can now flash your new ROM
Kernel Issue You have flashed a kernel that may be corrupt, originate from a different base, or is just not supported by the ROM (not really the case these days, most developers are willing to share tweaks and custom code) The result is a phone that boots to a black screen and will hang or reboot.
Note: HBOOT 1.15+ requires you to flash the kernel separately, all relevant info to do so is in this guide.
ROM Issue The kernel boots and luckily the ROM takes to the kernel but something in the kernel does not agree with your ROM. The result is a phone that will boot to android and promptly reboot.
Missing ROM Due to a misunderstanding, you have already wiped all ROM data from phone (cache, dalvik, and system) and fastboot flashed the kernel. Now phone hangs on HTC boot screen and will not load Android. Only the kernel has been flashed, the screen hangs because there is no OS to load. Fear not, return to recovery and flash the ROM package that your boot.image originated from. Now select reboot to system and wait for your phone to restart. The kernel will boot, your OS will load, and all will be right with the world.
Update.zip or update pmg.zip This is a doozy, the rewrite didn't take and you no longer have a working kernel or system image, phone will keep booting to boot loader. If you updated using fastboot this will be less frustrating then if it was placed on the root of your phone/SD card. If fastboot method was used just jump into recovery and flash a working ROM package or restore a back up. If updating from boot loader, remove the SD card and delete update. The boot loader will continue to automatically read update and flash it until you do so.
Bad kernel and or system image and recovery Phone will boot to boot loader, will not boot to OS and selecting recovery will boot to boot loader. All is not lost, simply fastboot recovery and or boot image (for those on HBOOT 1.15 and higher) and then flash ROM from recovery. This happens but it is very unlikely it will happen to you.
MISC
Help I just flashed the latest *insert ROM here* and my apps wont open (force close) This isn't the end all solution, but in many cases you just boot into recovery and select fix permissions. If you still have apps force closing and you know its not from the market, you may have to boot recovery and wipe the system and data, you will then need to re-flash the ROM
Help I flashed a new ROM/update/script and now I can't access my internal/external SD card Its OK, the SD card has been corrupted but you can reformat it with recovery itself or by using recovery to mount the card and formatting it by PC
Help the internal card isn't recognized by recovery or PC! (This is rare so make sure before attempting this fix) You're card is beyond a simple reformat, the physical address linking the card and or entire card is corrupt. Don't panic, you have to start clean. Back up the info on you external or remove it, make sure you have a ROM available on your PC. Go into recovery and repartition your phone, this will wipe all memory. You then load up a working ROM (a bad back up may be responsible or just reintroduce the problem), after you have flashed the ROM (HBOOT 1.15+ must fastboot kernel, unless S-OFF) go ahead and boot into android and restore your apps.
Help I repartitioned my phone and now I'm having trouble with my apps Not a problem, go into recovery and fix permissions.
My power button is broken! While I really don't recommend continued flashing of your phone without a power button, you can use built in menu options to reboot to recovery or adb reboot to recovery and or adb boot to fastboot.
Note: In the event that recovery is somehow damaged, phone may boot to boot loader depending on the state of your system. To the best of my knowledge, there is no way out if power button is damaged
Help my power button is broken and I'm stuck in the bootloader without Rom or Recovery Without the power button you can not choose recovery from the menu, so even if you flash TWRP you are stuck in bootloader. Flash recovery normally so that you have it after the problem is fixed. (Type fastboot flash recovery twrp.img) Now flash recovery again, only this time you will flash to boot. (fastboot flash boot twrp.img) This is a workaround to get into TWRP. Now we reboot the phone and flash the rom. (Type fastboot reboot) Wipe the phone as you normally would. (Dalvik, Cache, Factory reset, System) Install a Rom that has a kernel installer and reboot.
I can't seem to get my GPS to lock onto my location You can try using an app called GPS Tools, it will clear any data and reset GPS
How do I check to make sure my ROM/Kernel isn't damaged? Open zip file prior to flash or verify MD5 Checksum Hash
How do I check MD5? Read my section on MD5 verification
How do I flash ROMs? You can use Regawmod but I recommend you use HTC DEV Unlock. The basic process for this is simple. Register to HTC Developer website, go to unlock device and select other. Follow the simple instructions to enable adb and request token(Its a unique identifier for each phone). The website will then ask for token and send an email with further instructions. Once you have unlocked the boot loader you will now have access to fastboot. You have 2 methods of flashing recovery, you may fastboot flash the recovery image or use the update zip provided by TeamWin (Make sure the zip or image is compatible with your phone and verify MD5 sum to ensure no corrupt files are flashed). Once recovery has been flashed, its best to boot into recovery and make a back up of your phone's current state. Now before attempting to flash any ROMs, boot back into stock Android and download Goo manager from the market. Once installed, open app and from the menu select install open recovery script. This will ensure you have the latest recovery incase the one you just flashed is out of date. It will also enable you to use yet another alternative method to reliably flash your phone. As always, please read all relevant information before you attempt to unlock or flash your device. There are guides to help you posted on the forums. Good Luck!
Note: HTC Device Drivers must be installed prior to using HTC Dev Unlock, it should be covered in the HTC's unlock instructions.
Help the RUU failed and my phone is stuck in boot loader Try running it again or failing that, flash twrp in fastboot, then flash a kernel from which ever rom package you wish to flash and flash rom in twrp. If you really want to update it would probably be better for you to flash a stock rom with a stock recovery and perform an OTA update. If you relocked your boot loader, just flash the unlock_code.bin which you can get by unlocking through HTC DEV
Help my Android has super ceded Isaac Asimov's Three Laws of Robotics You gave it root, what did you expect to happen. It's the ghost in the machine man, Sky Net has to happen eventually.
So a brooding teenager with a hatred for machines really is our only hope for survival? God no, an emo teenager is never the solution
I think this is it for the most part, everything here should help most users troubleshoot their phones by themselves.
Thank you thank you thank you
Oh yea FIRST lol
Sent from the depths of hell
---------- Post added at 01:13 AM ---------- Previous post was at 01:07 AM ----------
Btw nice write up suggestion if i may would be add link to my flashung thread that also has rx's link to his thread about everything just a suggestion
Sent from the depths of hell
didnt I shoot you, damn those incredible recoveries they save just about anything if you know how to use them. Also, I believe that post has inevitably given me some form of carpal-tunnel. That or I'm just tired of typing typing typing. ALSO, I thought about linking the guides but that would make it more of a tutorial style and I clearly state it is not a tutorial, all the relevant information is on XDA or linked by other members
om4 said:
didnt I shoot you, damn those incredible recoveries they save just about anything if you know how to use them. Also, I believe that post has inevitably given me some form of carpal-tunnel. That or I'm just tired of typing typing typing. ALSO, I thought about linking the guides but that would make it more of a tutorial style and I clearly state it is not a tutorial, all the relevant information is on XDA or linked by other members
Click to expand...
Click to collapse
Very true well sorry bout carpel tunnel and all that lol very informative tho if used that is
Sent from the depths of hell
These people better use it lol, I some what ignored the gf to write this and I suspect she will be forgoing all extra-curricular activities in retaliation
I've been a bit confused on this: If I have S-OFF already, flashing a new RUU isn't going to be a problem; right? All I would have to do is re-install a rooted ROM to be back to where I am now (using CMX)?
if you want the new radios you can flash a zip that has the new radios without changing your hboot
om4 said:
And for the love of God clear your Wallet settings before you do anything. Menu > Settings > Reset Google Wallet. This can not be done anywhere else, you have been warned
Click to expand...
Click to collapse
Actually, I think it has been proven that you don't have to clear Wallet settings. I can't remember where I read it, but the problems when the phone first came out were problems with the app itself. I have flashed around 5-6 times with a full wipe without clearing the settings and Wallet works fine. I use it every day.
sofla2 said:
Actually, I think it has been proven that you don't have to clear Wallet settings. I can't remember where I read it, but the problems when the phone first came out were problems with the app itself. I have flashed around 5-6 times with a full wipe without clearing the settings and Wallet works fine. I use it every day.
Click to expand...
Click to collapse
well 1.22.651.3 did reset some of the phones that had bricked the secure element but not all of them, there are users who havent taken the new updates either so better safe then sorry. I added it as an after thought just to be safe but if its no longer a concern I can remove it
om4 said:
well 1.22.651.3 did reset some of the phones that had bricked the secure element but not all of them, there are users who havent taken the new updates either so better safe then sorry. I added it as an after thought just to be safe but if its no longer a concern I can remove it
Click to expand...
Click to collapse
No, probably best to leave it to let people know there was a problem, especially if for some reason they are still on the original software.
sofla2 said:
No, probably best to leave it to let people know there was a problem, especially if for some reason they are still on the original software.
Click to expand...
Click to collapse
Out of curiosity I looked at the change log for Wallet, all data is stored in the cloud now. So if I'm understanding this correctly, the secure element problem appears to have been bypassed
om4 said:
Out of curiosity I looked at the change log for Wallet, all data is stored in the cloud now. So if I'm understanding this correctly, the secure element problem appears to have been bypassed
Click to expand...
Click to collapse
That is a possibility
Arrghh!!?!?!! A developer called MihailPro just released a tool aptly named Uniflash that now makes a good chunk of this irrelevant. Oh well, it makes things easier for everyone here. I guess I could always add troubleshooting scenarios, unless a dev thinks of a way to automate that as well lol
om4 said:
Arrghh!!?!?!! A developer called MihailPro just released a tool aptly named Uniflash that now makes a good chunk of this irrelevant. Oh well, it makes things easier for everyone here. I guess I could always add troubleshooting scenarios, unless a dev thinks of a way to automate that as well lol
Click to expand...
Click to collapse
I will have to search for that. Also, Joeykrim's Flash Image GUI works great! I have used it on a few of my compatible devices. It takes 5-10 seconds to flash an img
Sent from my EVO using Xparent SkyBlue Tapatalk 2
om4 said:
Arrghh!!?!?!! A developer called MihailPro just released a tool aptly named Uniflash that now makes a good chunk of this irrelevant.
Click to expand...
Click to collapse
This still deserves a sticky.
Here is the link for more info on Uniflash, for those interested: http://forum.xda-developers.com/showthread.php?t=1859261
Added basic information on Uniflash, i was trying to add it earlier but my internet hates me
side note: those who took the time to read and learn about the info I posted will most likely be able to name the adb/fastboot commands this program automates...not very useful but it shows how easy these tools become when you understand the underlying process
Pretty good write up, but the key is whether people actually read it
Rxpert said:
Pretty good write up, but the key is whether people actually read it
Click to expand...
Click to collapse
thats always the case and a major problem with american education lol
Wileout suggested I post links to the tools and guides on how to root. I sincerely thought about it but theres a major issue with that, if I post links for tutorials or links for the tools I listed the reader is more likely to skip reading and go straight to the tool. Then we end up with more people asking for help
Posting links to other threads also puts the burdon on you for keeping the information up to date. I'd suggest leaving out anything that changes rapidly
Rxpert said:
Posting links to other threads also puts the burdon on you for keeping the information up to date. I'd suggest leaving out anything that changes rapidly
Click to expand...
Click to collapse
pfft...thats half the guide now and I wrote that thing at 2am this morning
I am on rooted Thor with 13.3.2.4, with the Nexus Rom installed via safestrap. I have been reading all the threads on unlocking the bootloader and find all of the steps to be very scary. I would like to wait until there was some kind of "toolkit" for this rather than having to first downgrade and then use python through adb etc which I am somewhat uncomfortable with. Will there ever be such a simpler solution?
The bootloader unlock procedure is a no brainer, can't mess up anything there. Downgrading is a little risky, but you're on 3.2.4, thus you can even use the rollback images for Safestrap, take a look at this thread (page 1 is about 3.2.5/3.2.6 users who can NOT use the downgrade images). I'm afraid it won't get any easier than that.
If you don't want to use Python, just execute the adb commands to get your ID and serial (post them here, or PM me if you don't want anyone to see them), I'll create the .unlock file for you then. Downgrading and (actual) unlocking are tasks you have to do yourself though.
I think I might try it this weekend. Thanks for the help.
Cl4ncy said:
The bootloader unlock procedure is a no brainer, can't mess up anything there. Downgrading is a little risky, but you're on 3.2.4, thus you can even use the rollback images for Safestrap, take a look at this thread (page 1 is about 3.2.5/3.2.6 users who can NOT use the downgrade images). I'm afraid it won't get any easier than that.
If you don't want to use Python, just execute the adb commands to get your ID and serial (post them here, or PM me if you don't want anyone to see them), I'll create the .unlock file for you then. Downgrading and (actual) unlocking are tasks you have to do yourself though.
Click to expand...
Click to collapse
I have successfully downgraded to 13.3.1.0, but I am confused about how to install TWRP. Since I have not enabled wifi and registered, I can't install flashify or cwm, or even install a file explorer apk to access my storage, and I don't know how to get the twrp.img file (which I guess I can only install via adb?) Where do I get the correct twrp.img file? I'm kind of stuck....
kbs24 said:
I have successfully downgraded to 13.3.1.0, but I am confused about how to install TWRP. Since I have not enabled wifi and registered, I can't install flashify or cwm, or even install a file explorer apk to access my storage, and I don't know how to get the twrp.img file (which I guess I can only install via adb?) Where do I get the correct twrp.img file? I'm kind of stuck....
Click to expand...
Click to collapse
I am by no means an expert but I just went through this process myself yesterday and it was relatively simple. Check this thread. It has a number of helpful posts in it, including my questions from yesterday.
The correct TWRP image is here. Just follow the instructions in that thread. It's super simple if you use the minimal adb and fastboot linked by Cl4ncy in the first thread I linked. If you have any other questions I'll do my best to help you.
kbs24 said:
I have successfully downgraded to 13.3.1.0, but I am confused about how to install TWRP. Since I have not enabled wifi and registered, I can't install flashify or cwm, or even install a file explorer apk to access my storage, and I don't know how to get the twrp.img file (which I guess I can only install via adb?) Where do I get the correct twrp.img file? I'm kind of stuck....
Click to expand...
Click to collapse
Sorry for the late reply, @muunkin pointed you in the right direction already.
Be sure to (re-)root 3.1.0 and disable OTA via HDX ToolKit, and enable USB debugging in Fire OS, hope you installed minimal adb and fastboot, then copy the TWRP image for your HDX (Thor = 7", Apollo = 8.9") to the root of the sdcard (which is the directory you'll see in Explorer after connecting the HDX to your PC, i.e. don't open another directory), open a DOS box, change dir to the adb directory (enter cd\adb) and enter the commands mentioned in the TWRP thread. This will flash the TWRP image to the recovery parition.
Do a backup of your Fire OS in TWRP before you flash any custom ROM, and copy it to your PC, also look for the TWRP backup of the stock recovery (I think TWRP does a backup somewhere), and move that to your PC as well.
In case you don't know how to access TWRP: with the HDX powered off, you press and hold volume up, then press and hold the power button, release both when the grey Kindle Fire logo appears on screen. Some ROMs (e.g. CM12) offer the advanced reboot in developer options, this will add options to reboot into recovery, bootloader or a soft (quick) reboot to the power menu.
Cl4ncy said:
Sorry for the late reply, @muunkin pointed you in the right direction already.
Be sure to (re-)root 3.1.0 and disable OTA via HDX ToolKit, and enable USB debugging in Fire OS, hope you installed minimal adb and fastboot, then copy the TWRP image for your HDX (Thor = 7", Apollo = 8.9") to the root of the sdcard (which is the directory you'll see in Explorer after connecting the HDX to your PC, i.e. don't open another directory), open a DOS box, change dir to the adb directory (enter cd\adb) and enter the commands mentioned in the TWRP thread. This will flash the TWRP image to the recovery parition.
Do a backup of your Fire OS in TWRP before you flash any custom ROM, and copy it to your PC, also look for the TWRP backup of the stock recovery (I think TWRP does a backup somewhere), and move that to your PC as well.
In case you don't know how to access TWRP: with the HDX powered off, you press and hold volume up, then press and hold the power button, release both when the grey Kindle Fire logo appears on screen. Some ROMs (e.g. CM12) offer the advanced reboot in developer options, this will add options to reboot into recovery, bootloader or a soft (quick) reboot to the power menu.
Click to expand...
Click to collapse
Thank you both @muunkin and @Cl4ncy for guiding me through this. It is clear now that I have to flash TWRP via adb. Unfortunately I did, however, last night briefly turn on wifi in order to get es file explorer, and very quickly the OS ugraded itself to 13.3.2.3. Then, stupidly, I decided to go back to Nexus rom 2.0.2, which I did by reinstalling safestrap. And, Nexus rom is installed on the Stock Rom slot, and I did NOT backup the 13.3.2.3 stock rom. SO, since I am on Nexus rom, do I understand correctly that I need to begin again by downgrading to 13.3.1.0? Right? (After printing out all of these threads and printing out a lot of it and carefully reading, it looks to me like if I had stayed on stock 13.3.2.3 I would not have had to downgrade.....but too late now anyway.) I do have the minimal adb and fastboot installed, and my device is recognized, so eventually this will work I'm pretty sure. I appreciate the help!
kbs24 said:
Thank you both @muunkin and @Cl4ncy for guiding me through this. It is clear now that I have to flash TWRP via adb. Unfortunately I did, however, last night briefly turn on wifi in order to get es file explorer, and very quickly the OS ugraded itself to 13.3.2.3. Then, stupidly, I decided to go back to Nexus rom 2.0.2, which I did by reinstalling safestrap. And, Nexus rom is installed on the Stock Rom slot, and I did NOT backup the 13.3.2.3 stock rom. SO, since I am on Nexus rom, do I understand correctly that I need to begin again by downgrading to 13.3.1.0? Right? (After printing out all of these threads and printing out a lot of it and carefully reading, it looks to me like if I had stayed on stock 13.3.2.3 I would not have had to downgrade.....but too late now anyway.) I do have the minimal adb and fastboot installed, and my device is recognized, so eventually this will work I'm pretty sure. I appreciate the help!
Click to expand...
Click to collapse
No, 13.3.2.3 is ok for both TWRP and unlocking the bootloader, i.e. no need to flash 3.1.0 again - a firmware below 3.2.4 is enough.
Cl4ncy said:
No, 13.3.2.3 is ok for both TWRP and unlocking the bootloader, i.e. no need to flash 3.1.0 again - a firmware below 3.2.4 is enough.
Click to expand...
Click to collapse
Even if I am not running on the stock rom? I can adb install TWRP while on Nexus rom?
kbs24 said:
Even if I am not running on the stock rom? I can adb install TWRP while on Nexus rom?
Click to expand...
Click to collapse
Hm, I'm not exactly sure about this - @ggow's answer here seems to point out that you really have to do it all over again.
Why did you install Safestrap again anyway? ADB-flashing TWRP and unlocking the bootloader before you install a custom ROM would've been the next steps. Also I told you to create a backup of your stock slot before you flash any custom ROM, didn't I?
Cl4ncy said:
Hm, I'm not exactly sure about this - @ggow's answer here seems to point out that you really have to do it all over again.
Why did you install Safestrap again anyway? ADB-flashing TWRP and unlocking the bootloader before you install a custom ROM would've been the next steps. Also I told you to create a backup of your stock slot before you flash any custom ROM, didn't I?
Click to expand...
Click to collapse
Yes you sure did, and that's why I said "stupidly" about me putting safestrap back and nexus rom. I was overanxious and acted impulsively, not having a recovery installed was freaking me out. Bad habit. About doing the backup, there did not appear to be enough room on the internal storage. Sorry. We'll start over no problem. Again thanks.
kbs24 said:
Yes you sure did, and that's why I said "stupidly" about me putting safestrap back and nexus rom. I was overanxious and acted impulsively, not having a recovery installed was freaking me out. Bad habit. About doing the backup, there did not appear to be enough room on the internal storage. Sorry. We'll start over no problem. Again thanks.
Click to expand...
Click to collapse
I'm also not sure how to do this now. You don't have any Safestrap 3.2.3 Fire OS backup to restore, you shouldn't use the 3.2.4 rollback image, as you're not on 3.2.4, so what do you want to flash to the stock slot now? Or did I miss anything?
Cl4ncy said:
I'm also not sure how to do this now. You don't have any Safestrap 3.2.3 Fire OS backup to restore, you shouldn't use the 3.2.4 rollback image, as you're not on 3.2.4, so what do you want to flash to the stock slot now? Or did I miss anything?
Click to expand...
Click to collapse
I was going to look for a stock 3.2.3 to flash. If can't find, I do have a backup of stock 3.2.4 on the card which I would flash, thus requiring the downgrade.
kbs24 said:
I was going to look for a stock 3.2.3 to flash. If can't find, I do have a backup of stock 3.2.4 on the card which I would flash, thus requiring the downgrade.
Click to expand...
Click to collapse
I haven't seen a 3.2.3 Safestrap flashable Image, good luck. Regarding the 3.2.4 backup I'm not sure whether it works with the 3.2.3 bootloader.
Cl4ncy said:
I haven't seen a 3.2.3 Safestrap flashable Image, good luck. Regarding the 3.2.4 backup I'm not sure whether it works with the 3.2.3 bootloader.
Click to expand...
Click to collapse
Yeah, I am probably screwed. But we'll see. I'm pretty sure I understand what the process should be at least.
kbs24 said:
Yeah, I am probably screwed. But we'll see. I'm pretty sure I understand what the process should be at least.
Click to expand...
Click to collapse
Not sure how far you got with this but you *should* be able to flash TWRP from Nexus provided the version of FireOS was 3.2.3.2 or lower prior to the installation of Safestrap v3. The customized version of twrp leverages a vulnerability in the HDX bootloader that is installed with FireOS. Neither Safestrap nor Nexus mess with the bootloader so the prerequisites should remain intact. I say should as interactions are complex - further complicated by a fussy device with limited recovery capability should something go wrong. To the best of my knowledge no one has attempted a twrp flash from Nexus while Safestrap v3 is installed.
Thoughts:
- grab flashify from the play store or here; make a backup of your current recovery environment (this step will also help to familiarize you with flashify)
- download the HDX customized version of twrp (here); use ES File Explorer to verify MD5
- use flashify to install twrp (can also be done via adb commands as shown in the twrp op)
Options:
- unlock the bootloader before attempting other remedial steps. Unlocking is a frustrating but low/no risk activity that yields substantially improved recovery capabilities once completed. Yep - you can do this without twrp (unlocking before flashing twrp is the recommended path according to several devs - although I prefer the opposite).
[-or-]
- flash 3.1.0 from here to the stock slot and then attempt to remove Safestrap v3. If successful you can proceed with flashing twrp unlocking, etc in the normal manner. As with any flash there is a risk something will go wrong or FireOS will not start up properly. To help mitigate the latter suggest installing a fallback version of Nexus v2 in a secondary slot. Don't forget to remove this slot before uninstalling SS.
The above is only an outline. Give it some thought and post any questions BEFORE taking action. I also suggest you let this post sit for a few days in case some of the rational is fatally flawed. Lots of smart people in the community who will jump in if my guidance is misdirected (which it has been shown to be on occasion). Don't risk a brick by acting too quickly. Proper preparation is essential for a successful outcome.
Sorry for sounding like your mum ... :angel:
Davey126 said:
Not sure how far you got with this but you *should* be able to flash TWRP from Nexus provided the version of FireOS was 3.2.3.2 or lower prior to the installation of Safestrap v3. The customized version of twrp leverages a vulnerability in the HDX bootloader that is installed with FireOS. Neither Safestrap nor Nexus mess with the bootloader so the prerequisites should remain intact. I say should as interactions are complex - further complicated by a fussy device with limited recovery capability should something go wrong. To the best of my knowledge no one has attempted a twrp flash from Nexus while Safestrap v3 is installed.
Thoughts:
- grab flashify from the play store or here; make a backup of your current recovery environment (this step will also help to familiarize you with flashify)
- download the HDX customized version of twrp (here); use ES File Explorer to verify MD5
- use flashify to install twrp (can also be done via adb commands as shown in the twrp op)
Options:
- unlock the bootloader before attempting other remedial steps. Unlocking is a frustrating but low/no risk activity that yields substantially improved recovery capabilities once completed. Yep - you can do this without twrp (unlocking before flashing twrp is the recommended path according to several devs - although I prefer the opposite).
[-or-]
- flash 3.1.0 from here to the stock slot and then attempt to remove Safestrap v3. If successful you can proceed with flashing twrp unlocking, etc in the normal manner. As with any flash there is a risk something will go wrong or FireOS will not start up properly. To help mitigate the latter suggest installing a fallback version of Nexus v2 in a secondary slot. Don't forget to remove this slot before uninstalling SS.
The above is only an outline. Give it some thought and post any questions BEFORE taking action. I also suggest you let this post sit for a few days in case some of the rational is fatally flawed. Lots of smart people in the community who will jump in if my guidance is misdirected (which it has been shown to be on occasion). Don't risk a brick by acting too quickly. Proper preparation is essential for a successful outcome.
Sorry for sounding like your mum ... :angel:
Click to expand...
Click to collapse
Thanks for your input. I am still on the nexus rom, but I am fairly sure that Safestrap was installed while on 13.3.2.4. Is there a way to tell? It is safestrap 3.75, based on twrp 2.7.
I had some time today to work on this, and after looking over the ideas from all of you (thank you very much!) it seemed that my only option is to restore my backup which will get me back to the Nexus 2.0.2 rom. So I did this successfully. Being on Nexus rom, I was then able to use the 13.3.2.4 rollback file to get back to 13.3.0.9. Then ran into trouble......the system update to 13.3.1.0 was not successful. the .bin file was located, but all that happened was a "validating update file" followed by forced reboot. I remain stuck on 13.3.0.9. There are threads discussing editing build.prop but I know I did not have to do this when I first did a rollback a few days ago. Not sure whether to give up or maybe someone has another idea how to get the system to use that .bin file? Should I turn on wifi and wait for an ota or is that too risky, will it jump me all the way up to the most current build? Will it maybe go incrementally?
kbs24 said:
Thanks for your input. I am still on the nexus rom, but I am fairly sure that Safestrap was installed while on 13.3.2.4. Is there a way to tell? It is safestrap 3.75, based on twrp 2.7.
Click to expand...
Click to collapse
(Also as you suggested, I did try flashing the zip 3.1.0 and it did not work, never rebooted successfully. So went back again to 3.0.9.)
kbs24 said:
I had some time today to work on this, and after looking over the ideas from all of you (thank you very much!) it seemed that my only option is to restore my backup which will get me back to the Nexus 2.0.2 rom. So I did this successfully. Being on Nexus rom, I was then able to use the 13.3.2.4 rollback file to get back to 13.3.0.9. Then ran into trouble......the system update to 13.3.1.0 was not successful. the .bin file was located, but all that happened was a "validating update file" followed by forced reboot. I remain stuck on 13.3.0.9. There are threads discussing editing build.prop but I know I did not have to do this when I first did a rollback a few days ago. Not sure whether to give up or maybe someone has another idea how to get the system to use that .bin file? Should I turn on wifi and wait for an ota or is that too risky, will it jump me all the way up to the most current build? Will it maybe go incrementally?
Click to expand...
Click to collapse
Glad you were able to make some progress. I believe you could have flashed twrp from Nexus as I believe you successfully downgraded/upgraded to 13.3.2.3 which would then be the base version when you reininstalled Safestrap. But you found another path which is just fine.
It is possible the 13.3.1.0 is invalid (possibly corrupt). You can use ES File Explorer to validate the MD5 (c49c0363de4d8dfa5c87c1bdb88aa2ba) or download a fresh copy here. You can also upgrade directly to 13.3.2.3 instead of hopscotching through 13.3.1.0 and then applying the 13.2.3.3 bootloader update.
I strongly suggest you NOT connect to WiFi as it is unpredictable if/when you will receive at OTA and what version will be downloaded. Options for getting files onto you device:
- use HDX toolkit to root and block OTA on 13.3.0.9; you can then enable WiFi
- tether your device and drop files into "Internal Storage"
- use 'adb push' to transfer files
You should not need to mess with build.prop as the 3.2.4->3.0.9 rollback should have handed that. It's quite easy to brick your device if you get any of the edits or permissions wrong.
Hello,
Wondering what would happen if device get stolen? I've just started, especially since recovery is so easily accessible. Basically, anyone can enter, wipe data and everything left and put a new system... All that he needs is an microSD. Or in my case, I left all .zip files on mine, so that he can even chose whether he'd like more stock 5.1.1 or existenz.
Sometimes I don't know why I bother with a screen lock at all...
Anyone has any idea about preventing boot into recovery? Locking the recovery? Would disabled debugging and unknown sources fix the problem? Encryption?
Sorry if such subject already exists, couldn't find one.
Cheers!
Preventing recovery boot isnt something not known to be able to do however there is a "Theme" for Twrp that allows a password to be loaded up before accessing it
For your phone being turned on you can use Google device manager and enable required settings on your phones
Envious_Data said:
Preventing recovery boot isnt something known to be able to do however there is a "Theme" for Twrp that allows a password to be loaded up before accessing it
For your phone being turned on you can use Google device manager and enable required settings on your phones
Click to expand...
Click to collapse
OH. Didn't know about that. I'll have to try that one.
Sent from Xperia Z2
Luckily not from an iPhone = Yesterdays technology at tomorrows prices
I'll try that too. Found something for locking for 2.8.6.0, hopefully it will work for 2.8.7.0 too.
If all recoveries are locked and the android as well, would it be possible for someone to flash another recovery on top of existent ones?
dennnic93 said:
I'll try that too. Found something for locking for 2.8.6.0, hopefully it will work for 2.8.7.0 too.
If all recoveries are locked and the android as well, would it be possible for someone to flash another recovery on top of existent ones?
Click to expand...
Click to collapse
Depends on how you install
Flashable zips typically erase the partition where as images being flashed via command need to be wiped before installing
Important notice! : iLLNiSS made me aware of a serious risk!
If you play with the firmwares manually and not with the flash all bat then DO NOT flash the blobs!
These are the actual bootloader files and stuffing up here will cause a hard brick!
I have to stress this out as it is serious thanks to not having working APX drivers a flshing programs for the Shield!
For starters, I uploaded a copy of the 7.2 developer firmware here:
7.2 developer ZIP on Dropbox
It is the full 1.1Gb update and not the 422mb block based one.
I have done some extensive tests since the first block based update wrecked my rooted Shield.
Some of it will end up in this post as info for everyone.
But lets start with what seems to be the problem for a lot of users right now who run a rooted Shield : Fixing the problem
A downgrade is officially not supported by Nvidia but my tests showed it works just fine if you only go back to the 7.1.
So far my tests showed differen sources for a Shield no longer working after the OTA.
1. The device had an unlocked bootloader and you got the 422mb block update.
This would have stuffed your bootloader and the Shield won't go past 1/4 on the progress bar for the update.
You are in luck as just flashing the 7.1 bootloader will fix it.
After that just dismiss the update and change the settings to manual updates.https://forum.xda-developers.com/editpost.php?do=editpost&p=78466377
2. Your device was already fully rooted and you got the full update that resulted in your Shield doing all sorts of thing but nothing properly anymore.
As long as your apps are still there and the Shield is still somhow usable you are lucky again.
A downgrade to 7.1 will fix it, I will explain the steps required further down.
3. You made bid mods, used Magisk or other rooting tools and now your Shield complains that your system is corrupt.
Bad luck if your bootloader is locked as you loose it all.
Lucky if the bootloader is unlocked as you might be able to keep most if not all during the downgrade.
General words of warning:
Even if your bootloader was unlocked from day one I can not garantee that the downgrade will keep all settings, apps, databases and so on.
For me it works fine as I kept all vital databases on external storage.
The procedures are all based on the developer firmware, on the stock firmware some things can still be done but then again you should not have more than software problems.
On the stock firmware the bootloader is locked by default and you can use some things required to owngrade due to the restrictions of a stock system.
General downgrade procedure for the developer firmware to get back to 7.1 :
If the update did get stuck on the progess bar early on and a reboot won't fix it so you can dismiss the update you just follow the steps.
If you can reboot into the 7.1 then just dismiss the update.
Trust issues or curruption warnings at boot but an otherwise working shield on 7.1 require to flash the 7.1 bootloader again.
In some cases it is possible to skip the corruption warning with a connected controller.
A reboot once you got to the homescreen will determine how bad it is.
Reboot goes fine: You are good.
Reboot keeps nagging with warnings other than the unlocked bootloader: Downgrade.
The downgrade is only required if you have problems or the Shield already runs on the 7.2!
In almost all other cases just flashing the 7.1 bootloader is sufficient.
Fixing a stuffed Shield by sideloading the 7.1 firmware while keping all apps and things:
Enable USB debugging and allow the connections for the computer if you still have access to the settings.
Otherwise you need to flash the 7.1 fresh and might loose vital things that need to install again.
Reboot into the stock recovery, if you use TWRP flashed on the Shield already then please flash the recovery from the 7.1 firmware first.
Hook up the controller and pressing A or B should get you into the normal recover screen past the dead droid.
ADB sideload XXX - where the xxx stands for the filename you have for the developer ZIP.
After the rebbot you should be back on your 7.1 homescreen and can dismiss the 7.2 update.
Also change the update settings while at it
Fixing a fully stuffed Shield and then downgrading to the 7.1 firmware:
If all went down south then you tried a few things and realised there is no way to get your data back and even less to prevent the 7.2 update.
Installing the 7.1 from scratch forces the setup wizard and before you can get anywhere you need to update to 7.2
So much easier to use the linked 7.2 update from above until Nvidia provides it on their download servers.
A vital thing to do is to keep the bootloader locked!!
Same for NOT having TWRP installed on the Shield!
If in doubt flash the 7.1 boot and recovery partitions first then go back into the stock recovery and wipe the cache.
Coming from a stock developer firmware with just an unlocked bootloader you are good to go.
Sideload the 7.2 update.
Unplug when the reboot starts and go into fastboot to lock the bootloader: Fastboot oem lock.
This is a vital step as the new kernel otherwise could ruin the completion of the install.
Ignore the double hassles and go through the wizard so you can enter the settings again to enable the developer mode and USB debugging.
Unlock the bootloader so you can do it all again Last time I promise!
Once you have both the bootloader unlocked AND the Shield in a usable condition past the setup wizard:
Reboot into the recovery to sideload the 7.1 firmware.
After the next reboot you are back on the 7.1 homescreen drirectly and can dismiss the update.
Possible tricks that can help you to prevent the installation of the 7.2 update if you come from a fresh 7.1 install instead:
Don't allow the reboot and instead use ADB to reboot into the recovery.
Wipe the cache - this will remove the scripts required to start the update after the reboot.
The next reboot should bring you back to the homescreen where you can stop the new download of the update and change the update settings.
TWRP, full root and new security measures in 7.2:
The 4.9 kernel used also makes use of a Fstab configuration that no longer includes the system partition.
This and other restrictions currently make the normal use of Magisk impossible.
With no system partition available to Magisk the changes in the boot process come to a stop and the Shield gets stuck during boot.
The added restrictions also make it very, very hard to manually add SU and busybox.
At least without getting the currupt system popup on every boot and finding out that a lot of things still don't work properly.
A final 7.2 firmware is said to be available on the download servers today.
If this final is no different from the current OTA then it will not be of any use for users requiring a fully rooted devices.
With the stock recovery still using the old kernel all attempts to use recovery functions to alter the system for rooting fail as well.
Can't blame the company as all this is part of Google revamp og security and closing backdoors and loopholes for possible attackers.
Personally I think it is Googles way of keeping control over devices they don't actually own.
Anyways I did make some little progress:
Plans for the near future:
Security is good but I like to know what my Android devices are doing and especially what Google likes to collect if I can not find ways to stop it.
So I will not try to use any backdoors or secrurity vulnerablilites in the new kernel to allow a full root on my Shield.
I will go the route I know best: Manual labour
The bootloader is already fixed to allow what we are used to from previous developer firmwares.
As SU and busybox can not be manually entered at this stage I will try to include them directly in the stock 7.1 firmware while renaming the OTA updater to have it a bit easier.
Assuming that works as expected I will do the same on the 7.2 firmware and compare the corresponding scripts and so on.
If the standard SU still works on an "unlocked" 7.2 I should be able to adjust the Magisk ZIP accordingly to implement it into the bootloader.
Only need to figure out if Magisk then has enough rights to work and the system is still happy to accept the changes.
I noly have the 16Gb 2017 model to work with but since the bootloader seems to be same for all Shield models I think if it works then it should do so for all models.
In the meantime I hope the infos here will help some pople to get their shield back without the need to sent it in.
Update 25/12/18: I got TWRP working on 7.2
This is only true for the 2017 model though as I have only this for testing.
Currently creating a backup to the internal storage.
If the restore works then I will upload the new TWRP - for the said model only!
Give me a day or two to fix it for the other models too.
There is progress on the rooting front as well.
Created new scripts for my kitchen to be able to handle the new file_context thing.
A fully pre-rooted and totally unsecure (in terms of ABD, DM-verity and such) is already cooked, just did not dare yet to try it out as I have a real life job too.
As for the pre-rooted firmware:
Things have changed quite a bit with the new kernel in terms of "just adding SU or Magisk".
Magisk might see an update for this problem soon, SU however seems to tally fail on two levels.
So far I was unable to do a full install of the modded firmware.
Flashed all at once and the boot just hangs.
Bootloader, reboot, then the rest seems to work.
At least for the basic install of the system.
If I add SU and busybox the system still ends up with a corrup notice during boot and then it fails.
Tune in over the next few days for progress updates at the end of the thread.
Major developments will be added right here.
Just a matter of finding the last restrictions.
Once that is done Magisk should be possible as well.
Ok, TWRP boot fine, does a backup but fails to restore the system to a bootable state.
Will now check if at least installing a zip works.
Well, it did not, so TWRP has to wait a few more days
I edited post 3 with instructions on how to "unbrick" and go back to 7.1.
Update 27/12/18: A friend of mine found some intersting stuff.
A 7.2 firmware offering a pure Android without any TV stuff but also a full root possible.
I hope he will share his finding here soon or allow me post it all in his name.
For now lets just say: It really works if done the rght way!
Full write rights, installing Magisk modules and all.
All thanks to an undocumented flaw in the device security structures, so even without any hidden backdoors or such LOL
Update: Whiteak was so kind to provide a working root solution in post 36, please check it.
I can confirm it is working as promised.
So the credits for this one go to Whiteak and the credits for the idea and use of the DTB file to Zulu99 - great idea!
To prevent any problems I advise to perform a factory wipe after the install and before the first boot.
Switch to the stock recovery to do this then boot as normal an enjoy.
A complete firmware with the required mods is sitting on my PC just waiting for idiot behing the keyboard to figure out how to pack it properly for flashing.
Once that problem is sorted and also TWRP working again things will get a lot easier.
Annoying update:
I was not able to confirm my web findings on the 7.2 firmwares bootloader but it seems other devices running the same type of kernel and bootloader and a bit lost now.
AVB is fully implemented on the latest level.
(Again I am working on confirming or denying these findings!)
This means any alteration to vital parts of the system will fail with a corruption warning or worse.
Custom recovery access is limited if not fully restricted.
But even if it works you still need a firmware to flash that either is able to disable all this crap, hoping the bootloader alone will allow it, or
to hope Nvidia will provide a future bootloader update with these restrictions removed.
We can not downgrade the bootloader and even if there is some old one out there that would actually be flashable the risk is high to end with a brick anyway.
The DTB, at least in my tests gives us the required system wide write access but I have no information about the AVM verfified boot other than that Zulu99's firmware works.
But if it was compiled with the NVidia developer suite then it will be signed accordingly so the bootloader accepts it.
Could not find any info on how his firmware was actually created.
It gives me the hope though that once I have a fully working TWRP again that my modded 7.2 will work as expected and with no restrictions anymore.
Thanks for the info.
Edit: Will use this post to list options to recover the Shield is all seems lost.
As a result of far too much rom cooking and mods I needed a 100% working way to recover the Shield in case things turn very ugly.
So lets sum up what I define as very ugly when playing with firmwares:
1. Firmware installed but the Shield just hangs on the logo.
2. Firmware installed and now the system is corrupt and even it is boots it takes forever to get around the nag screens.
3. Firmware downgrade attempted but now the Shield won't even boot anymore.
4. Anything that would qualify for a soft brick.
My worst case when I only got a flashing white screen after trying to restore a TWRP backup under 7.2.
There any many way that work for a variety of boot problems but it takes too long to list all cases I encountered with a list of fixes that work or a comment that only the below way works.
So just to be clear here: This is not for any recovery purpose other than fixing what can't be fixed through a factory reset or fresh flashing of the firmware!
1. Get the Shield into Fastboot mode: Connect wired controller and male to male USB cable.
2. Power the Shield up while holding A and B on the controller.
Keep holding until you see the fastboot menu on the screen.
3. Install the 7.1 recovery firmware for your Shield type after unpacking it.
With Fastboot connection working type: flash-all.bat and hit enter.
4. Keep an eye on the progess!
5. Once the Shield is finnished and reboots, hold the A and B buttons on the controller again to enter fastboot mode!
Do not let the Shield boot up other than into the fastboot mode!
6. Lock the bootloader! Fastboot oem lock
Confirm with the controller, then go down and select the recovery kernel.
7. Once the dead droid is on the screen press B on the controller to enter the real recovery.
If B does not work try A
8. Select the factory reset option to wipe all!
9. Once the wipe is done you can boot into 7.1 as normal again.
10. With a bit of chance you might even get directly to the homescreen if the previous setup was completed.
If you need the full seup wizard again and are forced to update to 7.2 then at least the update will work fine this time around.
In case you desire to go back to the 7.1:
If you just finnished the above only to end with the 7.2 then set it up and flash the 7.1 - you won't get the setup wizard again and can skip the update.
If you are on a working 7.2 that was update the OTA way but want to go back:
1. Install the 7.1 firmware.
2. Lock the bootloader.
3. Boot and then skip the update to 7.2.
Any idea what to do if the Shield sticks at the NVidia logo when you select Recovery from Fastboot? I reflashed boot and got the same result.
psycho_asylum said:
Any idea what to do if the Shield sticks at the NVidia logo when you select Recovery from Fastboot? I reflashed boot and got the same result.
Click to expand...
Click to collapse
It won't work from fastboot.
Fastboot operates on a different level and calling the recovery from there lets it end up in nowhere with no access to the system.
You need to boot into recovery through ADB as (for the new model) without a power button and usable hardware buttons we can't get into it otherwise.
Having said that, the fastboot way should still work with an unmodified bootloader.
When the dead droid is on the screen the recovery should be available after pressing the A button on the wired up controller.
But during my tests on 7.2 it did not always work, so you might have to try a few times and also try the B button.
Downunder35m said:
It won't work from fastboot.
Fastboot operates on a different level and calling the recovery from there lets it end up in nowhere with no access to the system.
You need to boot into recovery through ADB as (for the new model) without a power button and usable hardware buttons we can't get into it otherwise.
Having said that, the fastboot way should still work with an unmodified bootloader.
When the dead droid is on the screen the recovery should be available after pressing the A button on the wired up controller.
But during my tests on 7.2 it did not always work, so you might have to try a few times and also try the B button.
Click to expand...
Click to collapse
I have not been able to get to the dead droid screen.
Downunder35m said:
For starters, I uploaded a copy of the 7.2 developer firmware here:
7.2 developer ZIP on Dropbox
It is the full 1.1Gb update and not the 422mb block based one.
(snip)
Click to expand...
Click to collapse
Thanks for posting this, but please note that this firmware is only for the 2017 16GB model and cannot be used with a 2015 or Pro model.
I just got a 7.2.1 update that forced me to update. Wouldn't give me an option to skip it... As soon as I turned on my Shield, it said something about the 7.2.1 update and then rebooted and installed.
I was holding off on updating too so I didn't lose root. Now I'm unrooted and am unable to get Magisk working again until I can get my hands on a 7.2.1 bootloader... Bleh.
Weird, I am not getting the 7.2.1 at all here.
And since yesterday the OTA only tries the block based but not the full image.
AthieN said:
I just got a 7.2.1 update that forced me to update. Wouldn't give me an option to skip it... As soon as I turned on my Shield, it said something about the 7.2.1 update and then rebooted and installed.
I was holding off on updating too so I didn't lose root. Now I'm unrooted and am unable to get Magisk working again until I can get my hands on a 7.2.1 bootloader... Bleh.
Click to expand...
Click to collapse
I was able to downgrade using the 7.2 image after setting up the device on 7.2.1 OTA just make sure you disable automatic updates
Thanks downunder this kind of in-depth info is always appriciated man........i like to learn these kind of things, having bits here and bits there gives a better picture of the whole, while also giving us upto date current info.
Thanks for taking the time to write this :good:
---------- Post added at 07:35 AM ---------- Previous post was at 07:27 AM ----------
Edit
Hi downunder, could you confirm i have this correctly
With no access to fastboot thus no twrp or root, are you implying, assuming your able to inject root into stock firmware, that, i'd be able to flash this stock+root rom in STOCK recovery, which i do have access to?
Edit: im under the impression that stock firmware zips are checked by stock recoveries, so modifying a stock firmware zip tends to fail this check and thus wont install/flash.......which makes me think im misunderstanding here......or just hoping im not
If so, im interested
Edit
i just read your second post which near enought answers my curiousity, so that'll teach me to read beyond the first post before asking answered questions ........even if the post excites me............ahhh, who am i kidding, ill probabably do it again........the equivelancy of a mental post boner........not controllable
Sorry for the disgusting analogy
SyberHexen said:
I was able to downgrade using the 7.2 image after setting up the device on 7.2.1 OTA just make sure you disable automatic updates
Click to expand...
Click to collapse
Did I understand it correctly? You successfully downgraded from 7.2.1 to 7.2?
ErAzOr2k said:
Did I understand it correctly? You successfully downgraded from 7.2.1 to 7.2?
Click to expand...
Click to collapse
Yes,
Just ran flash all from the bootloader. For the newly released 7.2 developer_rooted factory image.
As long as we don't jump to Android 9 we should always be able to downgrade through a full factory firmware.
Once Android 9 comes this might not work anymore due to the massive changes involved for the boot and system checks.
@banderos101: Unless you really did something bad you should always be able to enter the fastboot mode to flash a full firmware.
If I have some time after xmas I will have another look on the options of signing the zip properly or simply to fake it.
Biggest problem will be to generate the corret SHA checksums ince all is installed so I can use the same checksums in the check files.
The bootloader needs them to identify the system and vendor as genuine.
The system needs them to confirm all is actually unmodified as otherwise all fails to boot at some stage.
Modding a proper userdebug firmware is not really that hard, but converting a release version that also is a true and secure user release...
Lets just say that it won't be an easy task.
As it looks like the kernel is a keeper I might have to figure something out unless TopJohnWu won't enjoy a break after his exams and works on a way to get Magisk working with out kernel.
At least I figured out why the recovery trick isn't working for me.
The system partition is not mounted for the sideload mode.
To apply an update the stuff is written directly onto the partition, so no file level access left to play with and break things
In comparison you could say the shield is now like a modern car with keyless operation only.
You know you can start it with ease, if you only could the remote that you left in the drivers seat when you locked the door
SyberHexen said:
Yes,
Just ran flash all from the bootloader. For the newly released 7.2 developer_rooted factory image.
Click to expand...
Click to collapse
Just wondering what is achieved by going back to 7.2?
What do you mean "going back"?
Right now the 7.2 is the official and latest firmware.
I was unable to get my hands in the 7.2.1 but guess it might have been a testversion for certain models only.
I wasted a few hours trying to fix the system image.
First stage was only to get the basic "features" back, like full ADB support, enabling the support to use SU and busybox....
Just what is required to actually allow these nice apps we like to gain root to work.
This backfired badly as right after the start the bootloader complained about the system being corrup and no override to get past this worked.
So of course I then removed the known restrictions from the bootloader...
As you guessed it the damn thing then did not even boot at all, just jumped right into the (locked) recovery mode.
A half decent comparision with my last manual root on a tv box that was a success showed I still did the right things...
If anyone wondered why we needed a new bootloader for the support of smart helpers an some codes stuff:
We didn't as all this could have been done with the 7.1 bootloader as well.
Since my root attempts so far all ended either in disaster or in a root access that failed shortly after/corrupted the system, I took a look of the general kernel changes that were published for other devices.
Before I could find anything meaningful I realised the 4.9 kernel is actually a requirement for Android Pie!
With that info sorted I started digging inti the new "security" features Pie can offer.
I will try to keep it simple and to the stuff that actually concerns us for rooting purposes:
The new boot process with Pie is aimed at being secure from the hardware level up and all the way into the system partion once the boot is completed.
So the hardware checks if the bootloader is actually usable - we had that for a long time, nothing new.
Once the bootloader starts and reaches the point of actually getting somewhere, all partitions required will be checks by either a hash check or a trusted certificate gererated at boot time that is compared to the previous certificate.
Only if that is fine the bootloader will call upon the system and vendor partitions.
The handover of control from bootloader to the system is made far more secure as well.
SELinux is called early on to ensure that only trusted apps and tasks can work but also to all a new control level.
System related apps no longer run as root or with special permissions.
Instead every single app and service runs as its own user!
And under SELinux conditions this means nothing can access anything that it is not entitled to unless included as a user for the other app.
And with that sorted the vendor stuff is called to ensure all hardware and vendor related stuff is still genuine - this include the required certs but also the recovery and bootloader hash codes and certs.
So if something is fishy either SELinux will stop us or the vendor stuff will just overwrite it all.
Once we finally reach the system stage the recovery is checked if called from within the system, if fully implemented it could mean that using an official update on a modded firmware will delete all data as the encryption from the old system is declared invalid.
Sadly it does not stop there because even with full rigths (faked or otherwise) to access the system partition with write access we still can not just change things.
If something belongs to a user (a secure app) than a change will corrupt the system.
To overcome all this without using vulnerabilities that so far no one has found, a compatible userdebug release has to be created from the official user firmware.
DM-Verity needs to be disabled as well as all partition encryption stuff.
The bootloader needs to be adjusted to reflect these changes and the required turst certificates generated and included in both system and boot images.
The only problem here is that the kernel won't allow these changes unless it itself is a userdebug kernel.
After that it is only the little efford to go through about 60 different scripts to remove or redirect the calls for all boot and system security related things.
If then by some chance all this actually boots up and goes all the way into a usable homescreen the entire stuff needs to be secured again.
This time so that the final system has a correct cert and checksum that matches those we need to include in the bootloader.
Anyone knows how to gain full access to the trusted keystore on the 4.9 kernel? LOL
For the moment I don't really care about all the stuff above.
I would be happy to figue out what to make out of these new fstab configurations without the vital partitions listed.
The real aprtitions used have not changed but it is impossible include them in the fastab, doing so causes the bootloader to fail.
Presumably because the kernel realised we try to get around the verification process.
This and some other minor things are also the reason TWRP fails so badly, same for the stock recovery by the way.
Since TWRP is toy a lot us like:
TWRP and 7.2....
Without a system partion in the bootloader fastab TWRP can not mount it.
Same for all other things TWRP needs to mount as it simply does not have the right to access these areas.
To make things worse, we need system access to even start TWRP through fastboot.
So, now matter if we flash or start it through fastboot: The bootloader and system will realise our recovery does not match the checksum.
What does al this now mean in terms a lot more people are able to understand?
Let me try...
Imagine the 7.2 in a running version would be just some encrypted file with a lot of folders in it.
And like PGP or other encryptions software we know there is a private and a public key.
With the public key you can see a lot and use most the encrypted file - but only to a level that is required, nothing above your low level clearance.
For every attempt to write into this file or to make changes we need the private key.
If you follow so far then lets just say the recovery (stock) and Fastboot can be, to some extent, used for this access.
But since every folder in the encrypted file also uses private and public keys it is like tracing a tree.
Although it is getting too long, let me give you the example of just adding SU to the sytem partition:
Adding SU into the system image is no big deal.
Singing this image to get a usable key and including this key into the keystore is.
Assume we would just be able to do it....
SU needs to be called quite early in the boot process.
It then elevates the access level for certain things and also intercepts all root related requests from apps and services.
Except of course those that already had these rights by default.
Problem here is that adding the scripts we need plus changing some others means violating the tree of trust on the device and we get locked out.
Finding a spot to add the required rights for SU might be still possible.
On the other hand it will be impossible to give SU any rights or access to "trusted user" owned parts, files, folders, partitions....
The entire concept of SU just fails.
I will have to check how much of the new features are active in the 7.2 kernel that hinder us.
If I find enough it might be possible it enough to call for a Magisk update.
But I guess it is of little use for just one set of devices, so maybe once more devices on the 4.9 kernel fail to work with Magisk it will be easier to spot a usable pattern.
In case someone else if already working ona mdified system: Please let me know how you made it boot after the changes
Shield Tv 16 2017 - OTA update 7.2.1 Ready for updating
Im on 7.1. I have been waiting for 7.2 developer image, which is now out and just noticed 7.2.1 is available OTA. I'm really confused what to do. I want to keep root without bricking my Shield. Should I Stay with what I have as it is running well.
I am not even sure if it is safe trying to update to dev 7.2 image (or if I would want to) by hooking to computer and using ADB Fastboot tools.
Is there any good reason to update to 7.2 or 7.21? and if so how would I go about doing it? Which program is good for flashing developer images or OTA updates. I used to use flash-fire, which seems to be obsolete now and have heard TWRP is incompatible rooting with SU with OREO updates????
Should I play it safe and stay with what I have rather than experiment and end up with a brick? (wouldn't be the first time)
Anyone know if 7.21 is some-kind of bug fix?
Alot of questions but hope someone has some answers.
Thanks for any info.
"You know you can start it with ease, if you only could the remote that you left in the drivers seat when you locked the door "
My fastboot issue
Yeah, i think i busted the microusb somehow with a faulty usb hub, whenever i plug the usb to my raspberrypi/windows box(for adb/fastboot) now, it turns off all usb ports on the pi aswell as the windows box, even when the shield is unplugged, some sort of earth problem maybe
......all i have is adb over network, adb reboot bootloader simply reboots back to system, adb reboot recovery works though.
ive read that fastboot over tcp(ethernet) had been introduced a couple of android versions ago, but i dont think its been implemented in our shields
infact heres a link
https://www.androidpolice.com/2016/...-capabilities-wireless-flashing-isnt-far-off/
Looks like it needs to be specifically added onto a build
As far as you making a stock root build, if you can, that would awesome, more then awesome, but if it becomes more work then you thought dont worry about it, its not like their making it easy
Also, sounds like 4.9/future android is gonna be a nightmare for root......... having the ability to root so that the option is there to see whats going on in the background of these devices, these devices posessing cameras/microphones/old+latest sensors/personal files/personal info, which reside on our personal beings or in our homes........is just one reason why i dont want to see root go away
So what is the purpose of the developer image of 7.2?
Rather, I know the stated purpose of the developer image, but if it is locked in the way described it sounds like the benefit is negated for typical developers.
(e.g. sometimes I debug an application without permissions in order to benchmark or debug a problem).
For casual users of the shield, using ad blockers and whatnot, is there any benefit to derive from installing the developer rom over stock? Does "adb root" still work?
What is left as the difference. It doesn't sound like they produced a userdebug build of the OS.
Thanks
The 2 new updates are horrible. I have gone back to 7.1. They have crippled my shield. I'll wait for a new update.