Related
Hi guys,
1. What is the advantage/disadvantage of flashing a custom kernel?
2. I recently flashed Cyanogenmod. It automatically installs a custom kernel right?
3. Using the Nexus 7 toolkit I reverted my N7 to stock recovery (from CWM) How should I make sure that it's been reverted to the latest stock version?
4. What does N7's stock factory image contain? (Stock ROM + Stock recovery + Stock kernel?) (found here: https://developers.google.com/android/nexus/images)
5. Is this correct? You can install a custom ROM without changing the kernel but in order to have more customization you have to flash a different kernel than the stock one.
6. Is this the correct order? Unlocking bootloader>rooting>Flashing custom recovery>Flashing custom kernel>Flashing custom ROM>...?
7. Difference between unlocking bootloader and rooting.
8. How to find out N7's latest stock kernel version.
Many thanx
Sent from my Nexus 7 using Tapatalk 4 Beta
valapsp said:
1. What is the advantage/disadvantage of flashing a custom kernel?
Click to expand...
Click to collapse
Same as those for a stock kernel. That is to say, every kernel has advantages and disadvantages. Some trade performance for battery life, others do the reverse. Some are more feature-heavy and potentially more unstable, others are feature-light but designed to be rock solid. With custom kernels on a Nexus device, you avoid one of the biggest dangers of custom kernels (instability due to lack of kernel source for developers to base their work on), but you still need to be careful. You don't necessarily know how proficient the author of a given kernel is, and the wrong one can make your device unusable/kill it.
valapsp said:
2. I recently flashed Cyanogenmod. It automatically installs a custom kernel right?
Click to expand...
Click to collapse
I believe it does. I don't remember which one though, since I don't use CM.
valapsp said:
3. Using the Nexus 7 toolkit I reverted my N7 to stock recovery (from CWM) How should I make sure that it's been reverted to the latest stock version?
Click to expand...
Click to collapse
You need to be more specific-- the latest stock ROM, or the latest stock recovery? If you're wondering about the ROM, you can check in Settings > About tablet > Status. When it comes to determining recovery version, I'm not so sure.
valapsp said:
4. What does N7's stock factory image contain? (Stock ROM + Stock recovery + Stock kernel?) (found here: https://developers.google.com/android/nexus/images)
Click to expand...
Click to collapse
I believe it contains stock ROM and kernel.
valapsp said:
5. Is this correct? You can install a custom ROM without changing the kernel but in order to have more customization you have to flash a different kernel than the stock one.
Click to expand...
Click to collapse
Generally correct. There's a subset of features that are kernel-dependent, not ROM dependent, so you should think of it as ROM customizations vs. kernel customizations. Some examples of the former include PIE menus and Paranoid Android's Halo feature. Examples of the latter might include tap2wake (double tap on a powered-off screen to turn it on), NTFS drive support for OTG, and so on.
valapsp said:
6. Is this the correct order? Unlocking bootloader>rooting>Flashing custom recovery>Flashing custom kernel>Flashing custom ROM>...?
Click to expand...
Click to collapse
Yes and no? It's one way of going about it, save for the last two things, which should be reversed. Since some ROMs include custom kernels, flashing a kernel and then a ROM runs the risk of having your kernel choice overwritten.
If all you need to do is flash a different ROM, you can go straight form unlocking the bootloader to flashing a recovery. You can also flash ROMs and kernels independently, so long as whatever kernel/ROM you're running initially doesn't have known incompatibilities with your new ROM/kernel.
valapsp said:
7. Difference between unlocking bootloader and rooting.
Click to expand...
Click to collapse
Unlocking your bootloader is like getting the key to a house. Rooting is getting permission from the landlord to do whatever the heck you want to the house. A locked bootloader means that the device is checking to ensure no unauthorized code is running at boot time, which prevents custom recoveries from being installed. Rooting only really matters when the device is booted up.
valapsp said:
8. How to find out N7's latest stock kernel version.
Click to expand...
Click to collapse
Google. Sorry, can't help you with this one.
That was a great answer @Rirere
Rirere said:
Same as those for a stock kernel. That is to say, every kernel has advantages and disadvantages. Some trade performance for battery life, others do the reverse. Some are more feature-heavy and potentially more unstable, others are feature-light but designed to be rock solid. With custom kernels on a Nexus device, you avoid one of the biggest dangers of custom kernels (instability due to lack of kernel source for developers to base their work on), but you still need to be careful. You don't necessarily know how proficient the author of a given kernel is, and the wrong one can make your device unusable/kill it.
I believe it does. I don't remember which one though, since I don't use CM.
You need to be more specific-- the latest stock ROM, or the latest stock recovery? If you're wondering about the ROM, you can check in Settings > About tablet > Status. When it comes to determining recovery version, I'm not so sure.
I believe it contains stock ROM and kernel.
Generally correct. There's a subset of features that are kernel-dependent, not ROM dependent, so you should think of it as ROM customizations vs. kernel customizations. Some examples of the former include PIE menus and Paranoid Android's Halo feature. Examples of the latter might include tap2wake (double tap on a powered-off screen to turn it on), NTFS drive support for OTG, and so on.
Yes and no? It's one way of going about it, save for the last two things, which should be reversed. Since some ROMs include custom kernels, flashing a kernel and then a ROM runs the risk of having your kernel choice overwritten.
If all you need to do is flash a different ROM, you can go straight form unlocking the bootloader to flashing a recovery. You can also flash ROMs and kernels independently, so long as whatever kernel/ROM you're running initially doesn't have known incompatibilities with your new ROM/kernel.
Unlocking your bootloader is like getting the key to a house. Rooting is getting permission from the landlord to do whatever the heck you want to the house. A locked bootloader means that the device is checking to ensure no unauthorized code is running at boot time, which prevents custom recoveries from being installed. Rooting only really matters when the device is booted up.
Google. Sorry, can't help you with this one.
Click to expand...
Click to collapse
First of all many many thanx to you because of your help. Yes I meant stock RECOVERY in question 3 also the way you explained question #7 is awesome.
Now I'm running stock ROM on CWM recovery and Franco kernel. My question is that will I be able to upgrade to Android 4.3 with this recovery and kernel? Or I have to flash the stock kernel or stock recovery or both?
Also how can I extract the stock kernel from the factory stock image file?
Thanx again.
valapsp said:
First of all many many thanx to you because of your help. Yes I meant stock RECOVERY in question 3 also the way you explained question #7 is awesome.
Now I'm running stock ROM on CWM recovery and Franco kernel. My question is that will I be able to upgrade to Android 4.3 with this recovery and kernel? Or I have to flash the stock kernel or stock recovery or both?
Also how can I extract the stock kernel from the factory stock image file?
Thanx again.
Click to expand...
Click to collapse
The OTA updates are normally only applied to the rom/system, so in theory you should be able to just run the OTA update with the stock rom, the worst that would mainly happen is losing rooting because the system partition gets replaced with a fresh install of the newest operating system (but your /data retains your settings and user data).
I use TWRP recovery instead of CWM, and TWRP when you're bout to exit it will detect if your system has Supersu or not and will offer to install it for you (from there once you boot into the system you can use it to install the su binary for you thus re-rooting).
In the end it's a personal choice. With custom roms like I'm using, there's no real "OTA" update (just a notice that the rom creators use to notify you of new versions which are downloaded to the device, and you just reboot into recovery to flash them). Custom roms typically get updated a few days to a few weeks after google updates if they're AOSP based.
The stock kernel would normally be the boot image, I don't know how you would do it with clockwork mod, but in TWRP you can simply make a backup of the boot partition to retain the original stock kernel. (It will of course only work on AOSP-based roms if you choose to just flash the stock kernel, but the ones that are made for the rom, or custom kernels tend to offer optimizations over the original stock one).
Thanks, I meant extracting the stock kernel from factory image file found here:
https://developers.google.com/android/nexus/images
By the way I don't have the stock kernel anymore to back it up.
Sent from my Nexus 7 using Tapatalk 4 Beta
valapsp said:
Thanks, I meant extracting the stock kernel from factory image file found here:
https://developers.google.com/android/nexus/images
By the way I don't have the stock kernel anymore to back it up.
Sent from my Nexus 7 using Tapatalk 4 Beta
Click to expand...
Click to collapse
Ahh I see, well if your's is the Wifi-only version then would be something like this https://developers.google.com/android/nexus/images#nakasijdq39
The firmwares are basically gzipped tarballs (in a linux system tar zxvf would normally unpack em, otherwise 7zip for windows does a good job of unpacking it into a folder).
Alternatively you can just download the kernel itself (Post #3) http://forum.xda-developers.com/showthread.php?t=2151154
Edit: Yes if you un-gzip/untar the original firmware, then unpack image-nakasi-jdq39.zip inside of that, there will be a boot.img that's where the kernel lives. The boot.img can be flashed via fastboot to the boot partition (I'd advise reading up on this first before actually doing it). Though like linked above, there are some recovery-flashible versions of the stock kernel you can use instead.
kbeezie said:
Ahh I see, well if your's is the Wifi-only version then would be something like this https://developers.google.com/android/nexus/images#nakasijdq39
The firmwares are basically gzipped tarballs (in a linux system tar zxvf would normally unpack em, otherwise 7zip for windows does a good job of unpacking it into a folder).
Alternatively you can just download the kernel itself (Post #3) http://forum.xda-developers.com/showthread.php?t=2151154
Edit: Yes if you un-gzip/untar the original firmware, then unpack image-nakasi-jdq39.zip inside of that, there will be a boot.img that's where the kernel lives. The boot.img can be flashed via fastboot to the boot partition (I'd advise reading up on this first before actually doing it). Though like linked above, there are some recovery-flashible versions of the stock kernel you can use instead.
Click to expand...
Click to collapse
thanks, I actually did unzip the stock firmware seconds ago and was posting the results then I saw your edit.
Just there are some confusions here: what is that userdata.img? also what is bootloader-grouper-4.18.img
valapsp said:
thanks, I actually did unzip the stock firmware seconds ago and was posting the results then I saw your edit.
Just there are some confusions here: what is that userdata.img? also what is bootloader-grouper-4.18.img
Click to expand...
Click to collapse
bootloader img would be the original stock bootloader for the Nexus 7, chances are you never replaced it, you only unlocked it. There's usually no reason to replace the bootloader with a custom one since all you need to do is unlock it.
userdata.img would be the /data partition. The firmware download basically has a image for all of the partition in the original out-of-the-box stock state. Technically you don't even to flash it, as long as you wiped /data before rebooting (since that would be the same as a clean install if you instead flashed the system and boot partition).
Edit: If I were messing with it to get back stock rom (but not messing with recovery, cuz custom recovery is still handy to have), I would only flash the boot.img and system.img , then log into Recovery and wipe data (ie: factory reset which wipes cache and /data but doesn't touch /data/media), Then I would be able to reboot into a clean stock install of the rom.
(from there I could just make a backup from recovery so I wouldn't have to do a fastboot flash again).
kbeezie said:
The OTA updates are normally only applied to the rom/system, so in theory you should be able to just run the OTA update with the stock rom, the worst that would mainly happen is losing rooting because the system partition gets replaced with a fresh install of the newest operating system (but your /data retains your settings and user data).
I use TWRP recovery instead of CWM, and TWRP when you're bout to exit it will detect if your system has Supersu or not and will offer to install it for you (from there once you boot into the system you can use it to install the su binary for you thus re-rooting).
In the end it's a personal choice. With custom roms like I'm using, there's no real "OTA" update (just a notice that the rom creators use to notify you of new versions which are downloaded to the device, and you just reboot into recovery to flash them). Custom roms typically get updated a few days to a few weeks after google updates if they're AOSP based.
The stock kernel would normally be the boot image, I don't know how you would do it with clockwork mod, but in TWRP you can simply make a backup of the boot partition to retain the original stock kernel. (It will of course only work on AOSP-based roms if you choose to just flash the stock kernel, but the ones that are made for the rom, or custom kernels tend to offer optimizations over the original stock one).
Click to expand...
Click to collapse
Unfortunately, how many times does should matter? Theoretically, you should be able to do OTAs while rooted by downloading the ZIP and flashing in recovery, but if you've made changes to /system (uninstalling a system app, or adding a helper), you might get the stupid script_assert error. Of course, you could just push the whole /system back to your device...although that can be just as annoying.
I wish there were away to turn off the script_asserts safely, but they do exist for a reason.
@valapsp
Small but important clarification.
valapsp said:
5. Is this correct? You can install a custom ROM without changing the kernel but in order to have more customization you have to flash a different kernel than the stock one.
Click to expand...
Click to collapse
Essentially 100% of custom ROMs install a kernel. (Actually, a kernel plus a ramdisk packaged together as a single ("bootable image") file, typically named "boot.img".) So your preexisting boot image containing the kernel is always overwritten during a ROM installation. See next answer.
valapsp said:
6. Is this the correct order? Unlocking bootloader>rooting>Flashing custom recovery>Flashing custom kernel>Flashing custom ROM>...?
Click to expand...
Click to collapse
Almost, but not quite. If you want to use a different kernel than what ships with a given ROM, you flash it after you have installed the ROM, not beforehand. See prior answer.
One more thing. Since you are new to this stuff, I'll make a suggestion:
Learn how to create and restore full Nandroid backups (using the custom recovery) immediately. And get in the habit of copying them off your tablet to your PC. You will thank me later for this advice.
have fun
Rirere said:
Unfortunately, how many times does should matter? Theoretically, you should be able to do OTAs while rooted by downloading the ZIP and flashing in recovery, but if you've made changes to /system (uninstalling a system app, or adding a helper), you might get the stupid script_assert error. Of course, you could just push the whole /system back to your device...although that can be just as annoying.
I wish there were away to turn off the script_asserts safely, but they do exist for a reason.
Click to expand...
Click to collapse
Hi, Rirere...
This is my understanding as well... (sort of! - I've always been a bit hazy on this topic).
My take on it is this...
The OTA would only fail, if it found files in /system that SHOULD BE THERE, but have been removed, modified, or replaced by the user (or via some app run by the user).
Logically (one would think), the OTA can't check for files THAT SHOULDN'T BE THERE (How would it know what to look for?) but have been ADDED by the user... like the su binary that confers root.
So, an OTA on pure ROOTED (but in all other regards, unadulterated) stock you would expect to succeed... you'd just lose root (and from what I've read elsewhere, your Custom Recovery). Both of which are trivial to recover.
Is my understanding correct... or have I missed something?
Rgrds,
Ged.
GedBlake said:
Hi, Rirere...
This is my understanding as well... (sort of! - I've always been a bit hazy on this topic).
My take on it is this...
The OTA would only fail, if it found files in /system that SHOULD BE THERE, but have been removed, modified, or replaced by the user (or via some app run by the user).
Logically (one would think), the OTA can't check for files THAT SHOULDN'T BE THERE (How would it know what to look for?) but have been ADDED by the user... like the su binary that confers root.
So, an OTA on pure ROOTED (but in all other regards, unadulterated) stock you would expect to succeed... you'd just lose root (and from what I've read elsewhere, your Custom Recovery). Both of which are trivial to recover.
Is my understanding correct... or have I missed something?
Rgrds,
Ged.
Click to expand...
Click to collapse
I believe you are correct! Theoretically, the script could rather easily check for added files by checksumming the entire /system partition before running the update (using a fast hash algorithm-- you're only looking for the presence of any changes, afterall). And I did have one OTA that went fine, other than losing root back on my Galaxy Nexus.
Again though, it's a classic case of should versus real life. Some root methods might alter things in /system without your knowing, or root actions might alter permissions. Either way, it's a tricky, nasty little game.
So far as recoveries go: yeah, OTAs have a nasty habit of trying to do that. Some of the more advanced recoveries can resist being overwritten though/slipstream a root ZIP into the update process.
GedBlake said:
The OTA would only fail, if it found files in /system that SHOULD BE THERE, but have been removed, modified, or replaced by the user (or via some app run by the user).
Click to expand...
Click to collapse
Typically the OTAs also update the boot image, so the boot partition (LNX) is also checked. The stock recoveries almost always use the same kernel (with a different ramdisk) as the boot image, so they are usually rewritten too.
Owners of tilapia N7 devices have reported successful flashing of everything but radio firmware images when they used a custom recovery to process the OTA bundle. Not a disaster, as their devices will still function with old radio firmware, but it puts them in an unusual position of being unable to use the OTA to subsequently update the radio, even if they restore the stock recovery (the system files and boot images will have been changed, so almost all of the checksums will fail). At that point, using fastboot is an alternate option, but then the newbs will need to read about OTA images, unpack them, yadda yadda yadda.
IMO it is just a dumb idea applying OTAs to anything but a pure stock device. And when I say pure stock, I mean including the stock recovery. The boot loader can be left unlocked, but that's about it.
There are a lot of ways to skin the cat, but IMO the best way to proceed is to operate with two parallel but independent tracks of Nandroid backups/restores: one track is a sequence of pure stock, and the other your customized ROM du jour.
Let's presume you have a Nandroid backup of the pure stock ROM. Make a backup of your current (customized) ROM & get it copied off the tablet (in the event of a disaster), restore the pure stock ROM nandroid backup, flash the stock recovery back to the tab, and then take the OTA.
At this point:
[ unlocked bootloader ] soft-boot (no flashing) a custom recovery using fastboot, and then make yet another Nandroid backup of the newly updated stock ROM including the recovery image. (This becomes the new baseline for future OTAs)
[ locked bootloader ] re-root with motochopper, capture the (new) stock recovery partition using 'dd', flash a custom recovery ('dd' or other method), make a Nandroid of this. (These two backups become the new baseline for future OTAs)
Then, repeat any rooting customizations (if you are a "lightly customized rooted stock" kinda person), and restore apps (Market apps only!) with TiBu.
This may seem like a great deal of work, but it is the only way to insure that you can revert to a prior starting position. Look: after going down a road like this you can even restore the old customized ROM backup to make TiBu app backups after the fact, simply because you can return to any point in time if you have made a backup (and kept a copy of it off the tablet).
Everybody makes mistakes - even the experts. But the lazier folks are (read: toolkit user) the more likely is a disaster. Everybody needs to make backups.
What will happen if I change some values in build.prop editor? I won't be able to install stock ROMs anymore? Or what?
Sent from my Nexus 7 using xda app-developers app
valapsp said:
What will happen if I change some values in build.prop editor? I won't be able to install stock ROMs anymore? Or what?
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
Depends on how you mean "install", you can always install via .img or recovery flashing method, but course that will overwrite your build.prop with the provided version and you would just have to re-edit the values again.
Did you mean OTA wise? If the update doesn't check for the hash of the build.prop, it will likely just replace it with a newer version if anything has changed from the last version to the new version.
As others have said, worse case scenario, the OTA fails to proceed due to errors and you would just have to manually update it yourself, as you could just flash a new boot.img and system.img from google's site (just have to remember anything you added on top of system or custom kernels will of course be reverted, so they will need to be reapplied).
Settings and user apps and such all live in /data , so it should just simply boot up as an upgraded system but with everything else intact (course I always make a backup via my custom recovery just in case).
kbeezie said:
Depends on how you mean "install", you can always install via .img or recovery flashing method, but course that will overwrite your build.prop with the provided version and you would just have to re-edit the values again.
Did you mean OTA wise? If the update doesn't check for the hash of the build.prop, it will likely just replace it with a newer version if anything has changed from the last version to the new version.
As others have said, worse case scenario, the OTA fails to proceed due to errors and you would just have to manually update it yourself, as you could just flash a new boot.img and system.img from google's site (just have to remember anything you added on top of system or custom kernels will of course be reverted, so they will need to be reapplied).
Settings and user apps and such all live in /data , so it should just simply boot up as an upgraded system but with everything else intact (course I always make a backup via my custom recovery just in case).
Click to expand...
Click to collapse
Thanks, and does backing up thru cwm also back up the build.prop?
valapsp said:
Thanks, and does backing up thru cwm also back up the build.prop?
Click to expand...
Click to collapse
Yes, but not in the way you're thinking. If you back up the whole system, CWM will package each partition up (/system /data , etc), so when you flash a new rom or system on, you can't just selectively restore build.prop since restoring in CWM Would also restore the entire system partition.
You can while in recovery, mount /system and do something like
adb pull /system/build.prop , and save a copy of it on your computer, so you can go back in and change the affected values back if for some reason you needed to.
If you're familiar with ghosting, nandroid backups (what CWM and most others do, minus some variations), are basically exact clones of all the files on each partition. Older recoveries actually took an image snapshot, newer ones basically pack all the files in a compressed archive (With some kind of note of what partition type it was, ext4, etc). The latter can easily be unpacked with tar, or 7zip, etc, but disk images are a different matter.
I can't remember which one CWM does exactly since on my DZ I use 4EXT, and on my Nexus devices I use TWRP.
kbeezie said:
Yes, but not in the way you're thinking. If you back up the whole system, CWM will package each partition up (/system /data , etc), so when you flash a new rom or system on, you can't just selectively restore build.prop since restoring in CWM Would also restore the entire system partition.
You can while in recovery, mount /system and do something like
adb pull /system/build.prop , and save a copy of it on your computer, so you can go back in and change the affected values back if for some reason you needed to.
If you're familiar with ghosting, nandroid backups (what CWM and most others do, minus some variations), are basically exact clones of all the files on each partition. Older recoveries actually took an image snapshot, newer ones basically pack all the files in a compressed archive (With some kind of note of what partition type it was, ext4, etc). The latter can easily be unpacked with tar, or 7zip, etc, but disk images are a different matter.
I can't remember which one CWM does exactly since on my DZ I use 4EXT, and on my Nexus devices I use TWRP.
Click to expand...
Click to collapse
Thanks, an easier way is to copy the build.prop thru a file manager.
But since I'm on my geek mood today I wanna know if it's possible to extract the backed up (Nandroid) file and find the build.prop somewhere there.
Sent from my Nexus 7 using xda app-developers app
valapsp said:
Thanks, an easier way is to copy the build.prop thru a file manager.
But since I'm on my geek mood today I wanna know if it's possible to extract the backed up (Nandroid) file and find the build.prop somewhere there.
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
If it's a backup done with 4EXT or TWRP most certainly since it's just a tarball package (or tar+gzipped if you enabled compression) and can be easily unpacked by tar, or any popular archive utility like 7Zip for windows. (restoration generally just looks at the file info to see what partition type it's supposed to be, formats the partition as such, and then just un-tars the content, with the permissions and such retained).
If it's older where it's an actual jaffs (may have spelled that wrong) disk image, I'm not sure off the top of my head how you would mount it as a disk , and then mount the ext4 or ext3 partition in order to get to it. I would assume ClockworkMod would have upgraded their backup method to the same as TWRP or 4EXT, but it's possible that they didn't for compatibility reasons.
Hi all,
I've been doing a lot of experimenting with my new 6P and have really enjoyed running Pure Nexus in place of the stock ROM on it. But the thing is, I bought the 128 GB version mainly because I was interested in experimenting with several different ROMs concurrently. I've used MultiROM in the past with no difficulty and right now I have it installed along with TWRP 3.0.2-0--the latest I could find with MultiROM support.
The problem is, I've been able to successfully install only a few secondary ROMs, either because flashing fails or I can't get them to boot after a successful flash. I suspect that this has to do with a mismatched vendor image, because the one I flashed for PN, I presume, is what any secondary is forced to look to, because MultiROM functionality apparently doesn't extend to multiple vendor images.
Am I correct about the way MultiROM works in this instance? Is there a workaround that would allow me to run ROMs that rely on different vendor images?
Thanks!
KT71
KilgoreTrout71 said:
Hi all,
I've been doing a lot of experimenting with my new 6P and have really enjoyed running Pure Nexus in place of the stock ROM on it. But the thing is, I bought the 128 GB version mainly because I was interested in experimenting with several different ROMs concurrently. I've used MultiROM in the past with no difficulty and right now I have it installed along with TWRP 3.0.2-0--the latest I could find with MultiROM support.
The problem is, I've been able to successfully install only a few secondary ROMs, either because flashing fails or I can't get them to boot after a successful flash. I suspect that this has to do with a mismatched vendor image, because the one I flashed for PN, I presume, is what any secondary is forced to look to, because MultiROM functionality apparently doesn't extend to multiple vendor images.
Am I correct about the way MultiROM works in this instance? Is there a workaround that would allow me to run ROMs that rely on different vendor images?
Thanks!
KT71
Click to expand...
Click to collapse
It sounds like you might be right about the vendor image. There is only one partition for the vendor image and whatever rom you run will use the vendor image that is flashed in that partition.
Hello,
Just got it and already bricked it, hooray.
I did the Nougat update and allowed modifications (the swipe in TWRP). I'm dumb
So here's everything I did :
First I used the Axon 7 Toolkit by BKORES to unlock bootloader and flash TWRP.
At step 9), It failed to boot TWRP even tho I could access it with power+volume.
It eventually would get stuck at the ZTE logo when I wanted to boot system.
I flashed SuperSU with an SD card in recovery.
So : Fastboot and system won't work. Recovery would, and so does bootloader from this.
What should I do ?
CiT42 said:
Hello,
Just got it and already bricked it, hooray.
I did the Nougat update and allowed modifications (the swipe in TWRP). I'm dumb
So here's everything I did :
First I used the Axon 7 Toolkit by BKORES to unlock bootloader and flash TWRP.
At step 9), It failed to boot TWRP even tho I could access it with power+volume.
It eventually would get stuck at the ZTE logo when I wanted to boot system.
I flashed SuperSU with an SD card in recovery.
So : Fastboot and system won't work. Recovery would, and so does bootloader from this.
What should I do ?
Click to expand...
Click to collapse
Nah this is a soft brick, nothing to worry about
Maybe your SuperSU did some bad stuff on the rom. For exampls if you flash SuperSU 2.79 or higher on Android 6 (at least in the stock rom) it won't boot. Maybe try flashing Magisk B13? I think it gets rid of SuperSU
There's a no-verity-opt-encrypt file too, somewhere in this forum, maybe in Kernels, ROMs thread. Maybe give it a shot
Another way is going back to the stock recovery and flash an official package. I have made an easy guide for the A2017G, not sure if it works on the U or chinese. you can find it over at Guides, should be pretty close to the top
If you have an A2017U you can get the DrakenFX system files and install them, maybe you can fix the stuff
Or take the easy way, and install a custom ROM. Not the best choice unless you're willing to withstand some small bugs and stuff. The way to install them is get the A2017X_Universal_Bootstack and corresponding modem for your model, plus the ROM and OpenGApps 7.1.2 arm64 (Or beansgapps if the rom specifies), and of course the ROM itself. You wipe system, data, caches (not necessarily internal) then flash the Universal Bootstack and tbe modem, then the ROM, then GApps if you want to have them, then Magisk or SuperSU if you want root (some roms come with self-installing Magisk in the same package, too).
Or use MiFlash and flash a complete stock image of your phone's system. That one works like a charm
Choose an username... said:
Nah this is a soft brick, nothing to worry about
Maybe your SuperSU did some bad stuff on the rom. For exampls if you flash SuperSU 2.79 or higher on Android 6 (at least in the stock rom) it won't boot. Maybe try flashing Magisk B13? I think it gets rid of SuperSU
There's a no-verity-opt-encrypt file too, somewhere in this forum, maybe in Kernels, ROMs thread. Maybe give it a shot
Another way is going back to the stock recovery and flash an official package. I have made an easy guide for the A2017G, not sure if it works on the U or chinese. you can find it over at Guides, should be pretty close to the top
If you have an A2017U you can get the DrakenFX system files and install them, maybe you can fix the stuff
Or take the easy way, and install a custom ROM. Not the best choice unless you're willing to withstand some small bugs and stuff. The way to install them is get the A2017X_Universal_Bootstack and corresponding modem for your model, plus the ROM and OpenGApps 7.1.2 arm64 (Or beansgapps if the rom specifies), and of course the ROM itself. You wipe system, data, caches (not necessarily internal) then flash the Universal Bootstack and tbe modem, then the ROM, then GApps if you want to have them, then Magisk or SuperSU if you want root (some roms come with self-installing Magisk in the same package, too).
Or use MiFlash and flash a complete stock image of your phone's system. That one works like a charm
Click to expand...
Click to collapse
I flashed DrakenFX's B29 stock rom. Didn't thought it would work with recovery but anyway ! Thank you.
Do you recommend some ROMs, kernels, etc ?
CiT42 said:
Do you recommend some ROMs, kernels, etc ?
Click to expand...
Click to collapse
Nah, they are all mostly bad. The best of the bunch seems to be NucleaRom, it has an okay kernel (Radioactive, not too good battery-wise but I've never seen so little UI lag, like, ever) and okay features (like 1/3 of what ResurrectionRemix has), an awesome maintainer (OrdenKrieger) and boots in like 15 seconds
But the stock ROM is currently the best of them all, not battery wise (you can get some obscenely high SOT numbers on LineageOS with Substratum black themes) but it's fluid and stuff runs well on it. The status bar is hideous though, and MiFavor is white themed, on an AMOLED screen, what the crap ZTE?
Don't try PureNexus, permanent hard brick from the looks of it.
LineageOS works okay but it has some compatibility problems with some apps I use, dunno
I think you could try the dual-boot patcher, that way you can test the roms and keep a working stock rom to use it as your daily driver without losing data. i never used the dual boot patcher though, so good luck if you will use it
I've bad experiences with Dual boot on my old 1+.
I created this thread in order to get some discussion going with the possibility to use DualBootPatcher for our Device. The device is supported and so far i got roms to patch but no luck to get it booting.
I hope we can share some information here to get us some dual booting.
Device must be rooted and decrypted for starters.
Got now rr as primary rom and will try later on to flash some roms on the second space... Let you know if that works out.
Tried to dual RR and liquid rom ..No luck. Just reboots to twrp..
Skickat från min ONEPLUS A5010 via Tapatalk
superior8888 said:
Tried to dual RR and liquid rom ..No luck. Just reboots to twrp..
Skickat från min ONEPLUS A5010 via Tapatalk
Click to expand...
Click to collapse
I have also rr as primary but second rom install ended in error 1 in twrp. Maybe you can try to reset data of second rom with the dualboot patcher zip.
It might be helpful to read the Dual Boot Patcher thread for the OP5, as there may be some important info there that is relevant for getting it to work on the 5T.
I tried rr as primary, no problem. Tried adding 2nd rom as secondary, as data slot 1, and no dice. Even tried removing assert lines in the updater script as suggested in op5 with rr as 2nd rom but that didn't work either; either booted back to twrp or booted to a black screen. If anyone makes it work please document and share your work. I'm encrypted by the way, even though you're "supposed" to be decrypted I was able to switch between primary and the non-booting rom just fine.
Anyone having any luck with this?
matteosaeed said:
Anyone having any luck with this?
Click to expand...
Click to collapse
Nope primary install goes good with a oos rom not stock. But when you try to install a second rom it gives error 1 in twrp and rom don't boot up.
That's great! Old MultiROM user here!
Ok, so I was able to successfully patch and boot into LOS and RR. LOS as primary and as slot 1 ROM, and RR as slot 2 ROM while encrypted. This wouldn't allow me to access any files in the phone via file managers for either slot ROMs, only in primary, so you must be decrypted if you're wanting to use/see the data in your internal memory on secondary ROMs. By the way I was only able to boot Nougat ROMs, dualpatcher doesn't work for Oreo ROMs yet. I'll do a small write up tomorrow, it's 1 am here ?
superior888 said:
I created this thread in order to get some discussion going with the possibility to use DualBootPatcher for our Device. The device is supported and so far i got roms to patch but no luck to get it booting.
I hope we can share some information here to get us some dual booting.
Device must be rooted and decrypted for starters.
Click to expand...
Click to collapse
Here is what I did:
IF YOU DON'T KNOW HOW TO DECRYPT, BACK UP YOUR STUFF, FLASH, ROOT, ETC, STOP READING NOW, THIS IS SOME HEAVY STUFF GETTING READY TO HAPPEN ?
If you want functional internal storage and have access to it on all secondary ROMs you must be decrypted. This guide assumes you have all required files on phone and/or computer
1. Flash bluspark recovery (wouldn't work on codeworkx for me)
2. Back up all your data, including internal storage somewhere safe
3. Wipe system, cache, and data (not internal)
4. Coming from Phoenix, so I flashed the Nougat firmware and then LOS 14.1 and booted it
5. Flash magisk 14.0, then install dualbootpatcher app
6. After granting root permission to dualbootpatcher go ahead and go to ROMs and set kernel now
7. Now you must patch another Nougat ROM as data-slot, ID 1 or 2 or 3, whatever you want. You can use the same LOS 14.1 as a test, or the RR Nougat version
8. Transfer the patched ROM to your PC or laptop and without unzipping/extracting the zip go to META-INF/com/google/android and open updater-script with notepad++. Delete the first two lines that's start with the word "assert" and save
9. It should now ask you if you want to update the zip, hit yes. Then transfer the updated patched ROM back to your phone
(you can do this from your phone too using winrar and your favorite file manager; it s a tad easier on your computer as you don't have to extract anything)
10. Now reboot into recovery and flash the patched ROM (do not flash from within the app)
11. Now flash the dualboot utilities in recovery and it should take you to an Aroma menu where you can see both primary and and data slot ROM. Tap the data slot ROM and choose "switch to". If you did everything right it should say "succeeded" and now you can reboot your phone and should boot into the secondary ROM.
12. To root data slot ROMs you must patch the magisk zip for that data slot ROM and then flash it in recovery, the same goes for gapps. Make sure whatever you patch does not have the "assert" lines in the updater script after patching it, else you must delete these lines.
Try it and report back. I can hardly debug my own device so I can't provide much support for you. The above is what I did while encrypted, so again, if you want functional internal storage for the additional ROMs must be decrypted before you try this.
cubandanger05 said:
Ok, so I was able to successfully patch and boot into LOS and RR. LOS as primary and as slot 1 ROM, and RR as slot 2 ROM while encrypted. This wouldn't allow me to access any files in the phone via file managers for either slot ROMs, only in primary, so you must be decrypted if you're wanting to use/see the data in your internal memory on secondary ROMs. By the way I was only able to boot Nougat ROMs, dualpatcher doesn't work for Oreo ROMs yet. I'll do a small write up tomorrow, it's 1 am here ?
Click to expand...
Click to collapse
Thanks for updating us, I'm an old multirom user as well and I'm going to keep my eye on this.
cubandanger05 said:
Here is what I did:
IF YOU DON'T KNOW HOW TO DECRYPT, BACK UP YOUR STUFF, FLASH, ROOT, ETC, STOP READING NOW, THIS IS SOME HEAVY STUFF GETTING READY TO HAPPEN
If you want functional internal storage and have access to it on all secondary ROMs you must be decrypted. This guide assumes you have all required files on phone and/or computer
1. Flash bluspark recovery (wouldn't work on codeworkx for me)
2. Back up all your data, including internal storage somewhere safe
3. Wipe system, cache, and data (not internal)
4. Coming from Phoenix, so I flashed the Nougat firmware and then LOS 14.1 and booted it
5. Flash magisk 14.0, then install dualbootpatcher app
6. After granting root permission to dualbootpatcher go ahead and go to ROMs and set kernel now
7. Now you must patch another Nougat ROM as data-slot, ID 1 or 2 or 3, whatever you want. You can use the same LOS 14.1 as a test, or the RR Nougat version
8. Transfer the patched ROM to your PC or laptop and without unzipping/extracting the zip go to META-INF/com/google/android and open updater-script with notepad++. Delete the first two lines that's start with the word "assert" and save
9. It should now ask you if you want to update the zip, hit yes. Then transfer the updated patched ROM back to your phone
(you can do this from your phone too using winrar and your favorite file manager; it s a tad easier on your computer as you don't have to extract anything)
10. Now reboot into recovery and flash the patched ROM (do not flash from within the app)
11. Now flash the dualboot utilities in recovery and it should take you to an Aroma menu where you can see both primary and and data slot ROM. Tap the data slot ROM and choose "switch to". If you did everything right it should say "succeeded" and now you can reboot your phone and should boot into the secondary ROM.
12. To root data slot ROMs you must patch the magisk zip for that data slot ROM and then flash it in recovery, the same goes for gapps. Make sure whatever you patch does not have the "assert" lines in the updater script after patching it, else you must delete these lines.
Try it and report back. I can hardly debug my own device so I can't provide much support for you. The above is what I did while encrypted, so again, if you want functional internal storage for the additional ROMs must be decrypted before you try this.
Click to expand...
Click to collapse
Thanks! I'll try this next days.
Thanks. Nothing works with Oreo as of yet i suppose :/
superior888 said:
Thanks. Nothing works with Oreo as of yet i suppose :/
Click to expand...
Click to collapse
It may be possible to have oreo as primary and flash Nougat as data slot roms. I tried with Phoenix as primary and I could boot into rr Nougat in data slot but Phoenix wouldnt boot. If someone can try rr oreo as primary and report back. I'm tempted to try with otg and see if I can install secondary roms using extsd option
*Quick update*
I was able to keep latest Phoenix oreo ROM as primary and install and boot Nougat RR as data-slot and as secondary using the latest dualbootpatcher app which may have fixed the "failed to update mbtool" error I was getting on Phoenix ROM. Also I used Magisk 14.0 for root as the latest version 16.0 kept booting back to recovery on non primary ROMs.
I'm still unable to flash Oreo ROMs as data-slot or secondary. At least we're able to keep Oreo as primary and test Nougat ROMs until dualbootpatcher app is compatible with Oreo or until some other fix is released.
Internal storage/data is still encrypted and unreadable on all non-primary ROMs; you must be decrypted prior to installing additional ROMs to have access to it, which I haven't tested yet.
See screenshots
Thanks for keeping up with this. I'm really interested but traveling without my PC so don't want to get stuck without a backup plan. Hopefully it's sorted by the time I get back home or I'll help test some more too.
es0tericcha0s said:
Thanks for keeping up with this. I'm really interested but traveling without my PC so don't want to get stuck without a backup plan. Hopefully it's sorted by the time I get back home or I'll help test some more too.
Click to expand...
Click to collapse
It's been relatively "safe" all the testing that I've done, not many scares, but you can never be too careful.
Edit: Now that it's working almost as intended we should make an official "how to" thread
cubandanger05 said:
It's been relatively "safe" all the testing that I've done, not many scares, but you can never be too careful.
Click to expand...
Click to collapse
If I wasn't out of the country, it'd probably be different. I've customized 100s of phones, 1000s of times but sometimes it's better safe than sorry. I'm great at fixing stuff because I've broken about everything I can (sometimes on purpose, sometimes not lol) but I need navigation and translation more than another custom rom I suppose.
es0tericcha0s said:
If I wasn't out of the country, it'd probably be different. I've customized 100s of phones, 1000s of times but sometimes it's better safe than sorry. I'm great at fixing stuff because I've broken about everything I can (sometimes on purpose, sometimes not lol) but I need navigation and translation more than another custom rom I suppose.
Click to expand...
Click to collapse
? understandable
Hello y'all,
I've noticed that on the Pixel 2 and on many other A/B devices, there is a twrp zip available that can be flashed after flashing the twrp image to boot and booting into recovery and flashing the stock boot image (like we do on the Essential) which patches the ramdisk in the stock boot.img to add twrp to it so that twrp can be permanently installed on the device.
If I could make something like this myself, I would have a long time ago, but unfortunately, it's over my head. Just curious why something like this has never been made for the Essential. Also, but much less important, TWRP 3.2.3-0 is about to be released (code is on GitHub), yet the latest available to us is version 3.2.1-1.
I know one of you smart devs could make the zip to install twrp to the ramdisk (and possibly build the latest version of twrp also) probably in almost no time at all. I love my Essential, but having to connect it to a PC just to get into TWRP is very irritating.
When one of you guys have the time, could you give it a try? I'd be happy to test whatever you come up with.
Much thanks!
starcms said:
Hello y'all,
I've noticed that on the Pixel 2 and on many other A/B devices, there is a twrp zip available that can be flashed after flashing the twrp image to boot and booting into recovery and flashing the stock boot image (like we do on the Essential) which patches the ramdisk in the stock boot.img to add twrp to it so that twrp can be permanently installed on the device.
If I could make something like this myself, I would have a long time ago, but unfortunately, it's over my head. Just curious why something like this has never been made for the Essential. Also, but much less important, TWRP 3.2.3-0 is about to be released (code is on GitHub), yet the latest available to us is version 3.2.1-1.
I know one of you smart devs could make the zip to install twrp to the ramdisk (and possibly build the latest version of twrp also) probably in almost no time at all. I love my Essential, but having to connect it to a PC just to get into TWRP is very irritating.
When one of you guys have the time, could you give it a try? I'd be happy to test whatever you come up with.
Much thanks!
Click to expand...
Click to collapse
It's definitely possible but I don't know how many Devs would want to take this up. I'm all for the idea, I really miss having TWRP permanently, but you kinda get used to the whole PC flashing thang.
I don't know how different the Pixel 2 is in comparison to the Essential phone, but they both share A/B partitions, so it wouldn't be too outlandish if someone were able to port something like this over to our Mata's down the road.
?
starcms said:
Hello y'all,
I've noticed that on the Pixel 2 and on many other A/B devices, there is a twrp zip available that can be flashed after flashing the twrp image to boot and booting into recovery and flashing the stock boot image (like we do on the Essential) which patches the ramdisk in the stock boot.img to add twrp to it so that twrp can be permanently installed on the device.
If I could make something like this myself, I would have a long time ago, but unfortunately, it's over my head. Just curious why something like this has never been made for the Essential. Also, but much less important, TWRP 3.2.3-0 is about to be released (code is on GitHub), yet the latest available to us is version 3.2.1-1.
I know one of you smart devs could make the zip to install twrp to the ramdisk (and possibly build the latest version of twrp also) probably in almost no time at all. I love my Essential, but having to connect it to a PC just to get into TWRP is very irritating.
When one of you guys have the time, could you give it a try? I'd be happy to test whatever you come up with.
Much thanks!
Click to expand...
Click to collapse
MoistPicklez said:
It's definitely possible but I don't know how many Devs would want to take this up. I'm all for the idea, I really miss having TWRP permanently, but you kinda get used to the whole PC flashing thang.
I don't know how different the Pixel 2 is in comparison to the Essential phone, but they both share A/B partitions, so it wouldn't be too outlandish if someone were able to port something like this over to our Mata's down the road.
?
Click to expand...
Click to collapse
The problem lies in the way our touch driver is implemented. For lack of a better explanation, what good would it do to need to carry a type c mouse around to use twrp if touch doesn't work. Many many people have tried and failed getting touch to work on Oreo source, let alone P. That is why twrp resides on a nougat kernel meant for LOS. Someone I know even rewrote the driver in c, no go. It's gonna be tough sledding.
Does it have to be touch though? Could it be more old school clockworkmod recovery where you use the buttons or really like default recovery. I don't know enough about it but just a thought. You definitely get use to just downloading and flashing in twrp and it would be cool to find that with the PH-1.
Atleaset there is a way to use TWRP on the fly.
1) Root the phone the first time using the PC.
2) Copy the TWRP and boot.img(rooted) files to the Phone.
3) While booted and rooted, use apps like Rashr - Flash Tool or Flashify available on the playstore to flash TWRP and boot to it.
4) Once you are done using TWRP, flash the boot.img and boot to the phone.
Gundabolu SC said:
Atleaset there is a way to use TWRP on the fly.
1) Root the phone the first time using the PC.
2) Copy the TWRP and boot.img(rooted) files to the Phone.
3) While booted and rooted, use apps like Rashr - Flash Tool or Flashify available on the playstore to flash TWRP and boot to it.
4) Once you are done using TWRP, flash the boot.img and boot to the phone.
Click to expand...
Click to collapse
Been waiting for someone to share this for 6 months.. thanks lol
aer0zer0 said:
The problem lies in the way our touch driver is implemented. For lack of a better explanation, what good would it do to need to carry a type c mouse around to use twrp if touch doesn't work. Many many people have tried and failed getting touch to work on Oreo source, let alone P. That is why twrp resides on a nougat kernel meant for LOS. Someone I know even rewrote the driver in c, no go. It's gonna be tough sledding.
Click to expand...
Click to collapse
Thanks for the explanation. Now I understand why it hasn't been done before.
But why the issue with touch in TWRP with an Oreo kernel in the first place? What's so special/different/difficult about the touch driver that the Essential uses? And why does it work fine with TWRP with a Nougat kernel? No other devices (to my knowledge) have this issue.
Edit: I wonder if since TWRP worked with the touch driver from the Nougat kernel, if it could work with the P kernel? Maybe whatever was changed in Oreo that prevented it from working has been fixed?
starcms said:
Thanks for the explanation. Now I understand why it hasn't been done before.
But why the issue with touch in TWRP with an Oreo kernel in the first place? What's so special/different/difficult about the touch driver that the Essential uses? And why does it work fine with TWRP with a Nougat kernel? No other devices (to my knowledge) have this issue.
Click to expand...
Click to collapse
Hbtp_daemon (touchscreen) doesn't work in twrp on 8.x and newer sources.
Hbtp_daemon runs in userspace iirc, which is the problem. So an entire driver needs to be hogged together in order to get twrp to work. same process that worked on N doesn't work now.
aer0zer0 said:
Hbtp_daemon (touchscreen) doesn't work in twrp on 8.x and newer sources.
Hbtp_daemon runs in userspace iirc, which is the problem. So an entire driver needs to be hogged together in order to get twrp to work. same process that worked on N doesn't work now.
Click to expand...
Click to collapse
Not possible to use the driver in userspace after TWRP decrypts the device (userspace) using the default password (after any patterns or pins are removed from the lockscreen)?
Edit: And what the heck is the driver doing in userspace anyway? Shouldn't it be in /vendor? If the driver is in userspace, then how can the touchscreen work after a factory reset?
The new Lineage Recovery is not bad but I see no way to apply other zips like Magisk. Maybe it can be worked on and adapted. No touch , just button control.
galakanokis said:
The new Lineage Recovery is not bad but I see no way to apply other zips like Magisk. Maybe it can be worked on and adapted. No touch , just button control.
Click to expand...
Click to collapse
It doesn't after you lets say flash magisk and gapps they create a script in /system/addon....and when updatting lineage it runs the scripts in the addon folder which is how gapps and magisk get installed to the new updated system and boot.....first magisk and gapps have to be flashed in twrp....after that u shudnt need it on dirty flashes
galakanokis said:
The new Lineage Recovery is not bad but I see no way to apply other zips like Magisk. Maybe it can be worked on and adapted. No touch , just button control.
Click to expand...
Click to collapse
@aer0zer0
This seems like the easiest solution to getting TWRP working on the Oreo and P boot images and being able to keep it permanently installed in ramdisk. Make TWRP use the volume up/down keys for scrolling and the power key to select. If the touchscreen is soooo difficult to get working, forget it. If someone really wants to use the touchscreen, they can use the existing TWRP version built on the Nougat boot image.
galakanokis said:
The new Lineage Recovery is not bad but I see no way to apply other zips like Magisk. Maybe it can be worked on and adapted. No touch , just button control.
Click to expand...
Click to collapse
What can you do in Lineage recovery if you can't flash zips? Can you make backups? What else can you do? If you have it installed, could you attach a pic (assuming you have another phone/camera)?
Has anyone looked in the stock P kernel? I was poking around and noticed some twrp residual files. This was straight from the images zip from essential. I didn't touch it.Wth are they in there for? Could they have a better twrp on the back burner for kernel development purposes for Essential? It was in the ramdisk, ill look again tomorrow when I unpack the boot.img. it would make sense to have it in ramdisk, pixel 2 has it like that. Ill post screenshots after work. But, the conversation looks good folks, you are on to something. We could always bust out some phillz recovery, or clockwork mod.
starcms said:
What can you do in Lineage recovery if you can't flash zips? Can you make backups? What else can you do? If you have it installed, could you attach a pic (assuming you have another phone/camera)?
Click to expand...
Click to collapse
I would say it is more stock-ish as far as recoverys go. It's a stock LOS recovery. You can factory reset, flash or sideload update.zips or signed zips no regular custom ROM zips or magisk. It is meant to run on LOS, it only runs on LOS actually and not made for the flashaholics out there. It's a good start though.
Sorry, out right now and no other phone/camera handy.
Gundabolu SC said:
Atleaset there is a way to use TWRP on the fly.
1) Root the phone the first time using the PC.
2) Copy the TWRP and boot.img(rooted) files to the Phone.
3) While booted and rooted, use apps like Rashr - Flash Tool or Flashify available on the playstore to flash TWRP and boot to it.
4) Once you are done using TWRP, flash the boot.img and boot to the phone.
Click to expand...
Click to collapse
Just wanted to mention this works perfectly, tried it last night was able to get into TWRP and then back into my P Beta 3 with root, no issues. Thanks for this!
One could also theoretically copy a copy of the twrp boot. Img to the ex kernel manager backup file, and while booted into the system, hit restore kernel and since its in the boot partition it will flash it then reboot into recovery. Then from there flash your normal kernel and boot back to system/android.. i backup all my kernels after rooting them so after flashing otas, i can just flash my prerooted kernel and reboot without having to flash magisk
Edit. This works, i just did it, but u must make it reboot to bootloader to then tell it to reboot recovery. I dont know if flashify is the same
MoistPicklez said:
Just wanted to mention this works perfectly, tried it last night was able to get into TWRP and then back into my P Beta 3 with root, no issues. Thanks for this!
Click to expand...
Click to collapse
Hey, I'm just curious, before I try it, anyway when using flashify and selecting flash zip - does a recovery other than stock need to be present?
dirtyreturn said:
Hey, I'm just curious, before I try it, anyway when using flashify and selecting flash zip - does a recovery other than stock need to be present?
Click to expand...
Click to collapse
Not sure what you mean by that but to be honest all I did was take the TWRP11.img, and flashed it to boot (kernel) using Rashr, Flashify didn't load up oddly, then reboot to bootloader, select Recovery and bam, there was TWRP. Then to get back I just flashed my boot.img, and Magisk and all my modules and everything were all good to go. No issues at all. ?
Edit: as long as you have TWRP.img, your boot.img, and Magisk, you can easily get to TWRP and back, just make sure you have the img's you need and boom we all got TWRP on the fly.
Wish I had tried this sooner.
MoistPicklez said:
Not sure what you mean by that but to be honest all I did was take the TWRP11.img, and flashed it to boot (kernel) using Rashr, Flashify didn't load up oddly, then reboot to bootloader, select Recovery and bam, there was TWRP. Then to get back I just flashed my boot.img, and Magisk and all my modules and everything were all good to go. No issues at all. ?
Edit: as long as you have TWRP.img, your boot.img, and Magisk, you can easily get to TWRP and back, just make sure you have the img's you need and boom we all got TWRP on the fly.
Wish I had tried this sooner.
Click to expand...
Click to collapse
Hey, Rashr doesn't support this device(phone). I get a reboot to recovery option and if I tap cancel the app just closes. Did the app identify what it needed to?
In Flashify there are 3 options ,Flash - kernel,boot, and zip. What I'm curious about is , when choosing just the zip option - would twrp first need to be flashed to the boot partition?