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.
[GUIDE] [SOLVED] HOW TO FLASH CM11 ON BRAVO (Previously "Cm11 Issue, Status 0 Error")
So, I tried to flash CM11 for the MB520 Bravo, found in this post:
http://forum.xda-developers.com/showthread.php?t=2515036
So I copy the ROM .zip to the SD card in my Bravo, and I reboot into CWM Recovery version 5.0.3.9, with the name "CyanogenDefy Recovery v5.0.3.9-jordan" on the top of the screen. This version of recovery came from josuearisty's one click tool for rooting and putting a recovery on the MB520 Bravo, which can be found here:
http://forum.xda-developers.com/showthread.php?t=1559109
I factory reset/clear cache like I know I am supposed to when flashing a custom ROM, but when I select the "Install zip from sd card" option and select the CM11 MB520 Nightly to flash, it gives me this:
Finding update package...
Opening update package...
Installing update...
E:Error in /sdcard/cm-11-20140407-NIGHTLY-mb520.zip
(Status 0)
Installation aborted.
So then as I read on further in the CM11 install page, it says this: "For CM10,10.1,10.2 < 07.11.13 users: To install KitKat, need update recovery. Do not forget reboot, after install recovery. http://defy.bytekiste.de/cm11-nightl...e-recovery.zip". The thread is for the DEFY+ according to the title, but since I see there's also a Bravo download link, I assume that this means that I should install this updated recovery as well, since I am running the stock rooted 2.2.1, which is in fact "less than" 10.x or 4.x. I select the same "Install zip from sd card" option, and the same Status 0 is presented to me.
Then I go and try putting on CM10.x first, because then according to the thread's instructions I won't have to install this updated recovery if I am running that currently. I find a link for CM10.2 for the Bravo here:
http://forum.xda-developers.com/showthread.php?t=1779324
I download it, do the same install method, and I STILL GET A STATUS 0 saying it is unable to flash the zip!
Now I've done some research, and I THINK the status 0 means the zip is not compatible with my phone. I could see that with the updated-recovery.zip, but I don't see why that is showing up for the ROM's themselves because they are in fact made for the mb520.
Can someone please tell me what I am doing wrong, and if possible post a set of step-by-step instructions as to how I can go installing CM11 on my MB520 Bravo? Thanks.
*BUMP*
UPDATE: I seemed to get around the Status 0 issue in CM10.2 so far. First, I went from 2.2.1 to CM9 4.0.4. Then, I went from CM9 to CM10.1 in quarx2k's "archive" folder on his website. This updated my recovery to TWRP 2.6.0.0. From this new TWRP, I was able to flash the latest 10.2 nightly CM rom. I will keep this posted on how things go, in case anyone out there is actually following this
*BUMP AGAIN, PROBLEM SOLVED*
I got CM11 finally running on the Bravo. Here's the steps I took to get it on there. Some of these steps may be unnecessary, but I'm just going to list EXACTLY what I did in case all of these steps really are necessary:
1) I started out with stock 2.2.1. I rooted it, and used josuearisty's tool for one click root and recovery just to put recovery on it.
2) I flashed a build of CM9 from quarx2k's website. Here is a direct link to download it. Flashing this ROM also updated my cwm recovery. HOWEVER, this new version of recovery had scrolling issues with the volume rocker, so I just rebooted and pressed the vol. down button at the blue flashing LED light to boot into the boot menu. From there, I select to go to recovery, but instead of selecting "Custom Recovery" I select "Stable Recovery". This takes me back to the older recovery I got with the one click tool.
3) I flashed one of quarx2k's builds of CM10.1, which you can get for yourself here. Doing this updated my recovery again. It went from CWM 5 to TWRP 2 (I believe it was 2.6.0.0).
4) I flashed a CM10.2 build for the bravo from quarx2k, which I got from here. This updated my recovery YET AGAIN, to TWRP 2.6.3.0.
5) From here, I was able to flash the update-recvery.zip that is mentioned in the CM11 topic. I don't think this was necessary, because when I then booted into recovery again after flashing the update-recovery.zip, the version number for TWRP still read 2.6.3.0, the exact same as last time. But I just did it anyway to be safe. Here is a direct download link to the update-recovery ZIP mentioned on quarx's CM11 thread.
6) FINALLY, I flash the CM11 nightly zip from quarx2k's website. I get an error, but this time it's not a status 0 error, this tells me that the ZIP is not compatible with my device.
7) I give myself a facepalm, and take 3 deep breaths. "All hope is lost..." I think to myself.
7.5) A GOOGLE SEARCH TELLS ME THAT ALL HOPE IS NOT LOST!!! (that's supposed to signal you to keep reading)
8) Turns out, there is a way to disable the device compatibility check. So what I did was copy the CM11 zip to my pc, and unzip all of its contents. I go to META-INF\com\google\android\, and add a .txt ending to the "updater-script" file, which allows me to open it with Notepad++. It is possible to edit this with plain old Notepad in Windows, but it doesn't format the code very neatly like Notepad++ does. If you open the file in Notepad and Notepad++ and compare them you will see what I mean. Anyway, the line of code that reads...
assert(getprop("ro.product.device") == "mb520" || getprop("ro.build.product") == "mb520" || abort("This package is for \"mb520\" devices; this is a \"" + getprop("ro.product.device") + "\"."); (ignore that winking face in the line of code, that is supposed to be a "; )" but without the space between them.)
... was the one I deleted from the updater-script file. This should be the first line of code. I save, exit Notepad++, and remove the .txt ending from the updater-script so that it returns to an unknown filetype. Now, I take the META-INF, system, and file_contexts files that came from the original CM11 ROM zip and I create a NEW ZIP with all of the NEW files and folders.
9) I reboot to TWRP with the ROM zip copied to my phone's SD card, and I flash the new, fixed ROM zip. "Installation completed."
10) My Bravo is rebooted, it boots up, and i get a "Welcome!" bubble in my brand-new homescreen in KitKat
11) I nearly cried. Seriously.
So looking back I think it was really the recovery that was the issue for the Status 0 problem, and the only real way to update the recovery and solve the Status 0 problem is by flashing all these ROMs in the order I mentioned, but that's as far as I know, there may be a better and quicker way to do this that I just don't know about.
So basically this thread turned into a how-to. I wanted to post the instructions here because on the CM11-for-the-Defy-and-Bravo topic did NOT have any instructions whatsoever for flashing the Bravo CM11 build on the Bravo. If anyone has questions about what I wrote, then you can certainly post them below and I'll respond to them as soon as I can, and I'll answer them to the best of my abilities.
Thanks for the Guide
I just wanted to thank you for this well-written, step-by-step guide. I haven't tried it since I'm a beginner and need some more reading to do. I'm glad you overcame those issues, though.
Anyway, I wanted to ask you how smooth it ran and if it was worth it. Also I'm starting with Android 2.1, would that make a difference?
Gastnow said:
I just wanted to thank you for this well-written, step-by-step guide. I haven't tried it since I'm a beginner and need some more reading to do. I'm glad you overcame those issues, though.
Anyway, I wanted to ask you how smooth it ran and if it was worth it. Also I'm starting with Android 2.1, would that make a difference?
Click to expand...
Click to collapse
I think you should upgrade to 2.2.1 to make sure the one-click tool works with it because I do not know if the one click root and recovery works with 2.1. Upgrade to 2.2.1 just to be safe.
Sent from my SAMSUNG-SGH-I847
Thanks for the guide
Appreciate the work. What gapps are you using.
Doesn't have much support
I tried it. A lot slower then CM7.2 and very difficult to get my most important apps working (and I don't use many).
I would not recommend it for a daily (as mentioned on the Defy link). But, has potential if a developer takes up the task.
ilikepcs said:
Appreciate the work. What gapps are you using.
Click to expand...
Click to collapse
ilikepcs said:
I tried it. A lot slower then CM7.2 and very difficult to get my most important apps working (and I don't use many).
I would not recommend it for a daily (as mentioned on the Defy link). But, has potential if a developer takes up the task.
Click to expand...
Click to collapse
The gapps for this KitKat ROM can be found here. This came from the 4.4 thread:
QUARX2K'S KITKAT GAPPS
I used this as a daily driver for a little bit, until an update (I believe was from April 10th) with the Android 3.0 kernel broke the Camera. Whenever you would try to open the camera it would say "Can't connect to Camera". I'm not sure if this issue was fixed since then, and I know the versions before this had the 2.x kernel which was fine with the camera. I lent my Bravo to a family member because their phone broke, so I can't really do anything with the phone because it is not in my possession.
Anyway, check back at this thread and the link that it gives to the Bravo version of 4.4 to keep up with the latest version. This thread does not give a change log for the BRAVO version, but I assume that it's basically the same as the main version that the majority of the thread is talking about:
ANDROID KITKAT FOR DEFY AND DEFY PLUS (ALSO FOR THE MOTOROLA BRAVO)
Help please
The procedure to install cm11 after October 1 is the same? Or did it change? @jasonmerc
Quarx on their website does not mention cm10 and cm10.1
Sent from my mb520 using XDA Free mobile app
@jasonmerc
You are not using CM11 anymore? Do you know if the camera problem has been solved (I assume that with the 2.6.x kernel the original motorola camera drivers were used which most likely do not work with a 3.x kernel)? What was your general experience (especially regarding performance) with CM11 on the Bravo?
Thanks,
Markus
oldschool63 said:
@jasonmerc
You are not using CM11 anymore? Do you know if the camera problem has been solved (I assume that with the 2.6.x kernel the original motorola camera drivers were used which most likely do not work with a 3.x kernel)? What was your general experience (especially regarding performance) with CM11 on the Bravo?
Thanks,
Markus
Click to expand...
Click to collapse
Its been forever since I've used my Bravo let alone CM11. From what I can remember the new CM11 was EXTREMELY FAST compared to other ROMs. The only issue was the camera.
Sent from my LG-D415 using XDA Free mobile app
can you create a backup of it because some of the downloads don't work i got cm 9 4.0.4 im 12 and i ran into
a problem on cm 10.1 i cannot download it or flash it thx
Hi.
I am not quite sure how to proceed even after going through some threads.
I've got Antares CM12.1 (12.1-20150428-NIGHTLY-jfltexx) on my S4 GT-I9505 plus
CWM v6.0.4.4
Does it make sense to upgrade to CM12.1 optimized or wait for the final version?
It is recommended to use TWRP Recovery v2.8.6.0 instead of CWM.
Can I just flash the TWRP zip via CWM and It'll be fine? (TWRP replaces CWM?)
I don't want to do a clean install, just upgrade.
Thanks!
PePeMoke said:
Hi.
I am not quite sure how to proceed even after going through some threads.
I've got Antares CM12.1 (12.1-20150428-NIGHTLY-jfltexx) on my S4 GT-I9505 plus
CWM v6.0.4.4
Does it make sense to upgrade to CM12.1 optimized or wait for the final version?
It is recommended to use TWRP Recovery v2.8.6.0 instead of CWM.
Can I just flash the TWRP zip via CWM and It'll be fine? (TWRP replaces CWM?)
I don't want to do a clean install, just upgrade.
Thanks!
Click to expand...
Click to collapse
It's not really an upgrade. They are different roms. Sure, they are both by the same developer. But on is stock AOSP and one has Optimizations to make it faster and smoother, I guess.
Doing a clean installation is recommended to avoid issues and bugs. You can, of course, dirty flash, but don't complain about problems
I would recommend you TWRP. It's easier to use and I haven't had any problems with it so far. I use version 2.8.3.0.
Flashing it using the zip should be fine.
GDReaper said:
It's not really an upgrade. They are different roms. Sure, they are both by the same developer. But on is stock AOSP and one has Optimizations to make it faster and smoother, I guess.
Doing a clean installation is recommended to avoid issues and bugs. You can, of course, dirty flash, but don't complain about problems
I would recommend you TWRP. It's easier to use and I haven't had any problems with it so far. I use version 2.8.3.0.
Flashing it using the zip should be fine.
Click to expand...
Click to collapse
Thanks mate!
The TWRP Recovery v2.8.6.0 I've got installed will convert to F2FS automatically?
Because in the instructions it says "To convert cache and data partitions to F2FS look in post above post."
But in the next line it says "System partition is automatically converted to F2FS at ROM's installation"
So I just flash the ROM via TWRP and it will do so?
PePeMoke said:
Thanks mate!
The TWRP Recovery v2.8.6.0 I've got installed will convert to F2FS automatically?
Because in the instructions it says "To convert cache and data partitions to F2FS look in post above post."
But in the next line it says "System partition is automatically converted to F2FS at ROM's installation"
So I just flash the ROM via TWRP and it will do so?
Click to expand...
Click to collapse
F2FS is optional. You don't have to convert. You can just flash it with your default file system (ext4).
But you if do want to convert and flash that rom, then use the recovery provided by the rom developer. There is a link in the thread that takes you to a modified version of TWRP I think
Note: Converting will wipe the internal memory..
GDReaper said:
F2FS is optional. You don't have to convert. You can just flash it with your default file system (ext4).
But you if do want to convert and flash that rom, then use the recovery provided by the rom developer. There is a link in the thread that takes you to a modified version of TWRP I think
Note: Converting will wipe the internal memory..
Click to expand...
Click to collapse
Ok got that.
I flashed the suggested TWRP for that ROM.
But it says in red "System partition is automatically converted to F2FS at ROM's installation"
So doesn't that mean that it will do the converting anyway?
It's the Antares cm12.1 optimized build by the way.
PePeMoke said:
Ok got that.
I flashed the suggested TWRP for that ROM.
But it says in red "System partition is automatically converted to F2FS at ROM's installation"
So doesn't that mean that it will do the converting anyway?
It's the Antares cm12.1 optimized build by the way.
Click to expand...
Click to collapse
As I said, using the TWRP recovery suggested by the developer will convert your file system to F2FS.
IF you WANT to convert, use that one.
IF you DO NOT WANT to convert, then download TWRP from their site or somewhere else. One that is not modified
GDReaper said:
As I said, using the TWRP recovery suggested by the developer will convert your file system to F2FS.
IF you WANT to convert, use that one.
IF you DO NOT WANT to convert, then download TWRP from their site or somewhere else. One that is not modified
Click to expand...
Click to collapse
The OP is right, my 12.1 Optimized automatically converts /system to F2FS at ROM's installation. I will soon revert this to let the user choose between ext4 and F2FS and to fix installation issues on recoveries that don't have mkfs.f2fs binary inside ramdisk
TWRP 2.8.6.0 is suggested because it has the maximum compatibility with Android 5.1
Differences between official TWRP and my F2FS-compatible? Just a plus: management support for this file system, the other things are identical
Inviato dal mio GT-I9505
AntaresOne said:
The OP is right, my 12.1 Optimized automatically converts /system to F2FS at ROM's installation. I will soon revert this to let the user choose between ext4 and F2FS and to fix installation issues on recoveries that don't have mkfs.f2fs binary inside ramdisk
TWRP 2.8.6.0 is suggested because it has the maximum compatibility with Android 5.1
Differences between official TWRP and my F2FS-compatible? Just a plus: management support for this file system, the other things are identical
Inviato dal mio GT-I9505
Click to expand...
Click to collapse
I know he's right.
I was just trying to figure out if he really wants to convert or not.
To me it seemed as if he thought F2FS is obligatory in order to run your rom. So I made sure he gets the point that it isn't
AntaresOne said:
The OP is right, my 12.1 Optimized automatically converts /system to F2FS at ROM's installation. I will soon revert this to let the user choose between ext4 and F2FS and to fix installation issues on recoveries that don't have mkfs.f2fs binary inside ramdisk
TWRP 2.8.6.0 is suggested because it has the maximum compatibility with Android 5.1
Differences between official TWRP and my F2FS-compatible? Just a plus: management support for this file system, the other things are identical
Inviato dal mio GT-I9505
Click to expand...
Click to collapse
Thank you for the answer first of all.
I wanted to root my device again after the 12.1 optimized build installed,
but when I flash the matching tar file (cf-autoroot bye chainfire) via Odin SuperSU is not installed and
when I download it from the playstore it cannot update the binary..
you know why is that?
Ok I've got root access by installing the SUperSU update via TWRP.
But why doesn't it work the other way?
I had no problems with doing so in your 12.1 nightly..
Bye the way, great ROMs!!
PePeMoke said:
Ok I've got root access by installing the SUperSU update via TWRP.
But why doesn't it work the other way?
I had no problems with doing so in your 12.1 nightly..
Bye the way, great ROMs!!
Click to expand...
Click to collapse
The rom is already rooted. But you have to enable root first. The rom developer (AntaresOne in this case) posted instructions in the rom thread on how to do that.
But installing SuperSU from the market or via a flashable zip is also good. I've had problems with the CM Superuser app.
PePeMoke said:
Thank you for the answer first of all.
I wanted to root my device again after the 12.1 optimized build installed,
but when I flash the matching tar file (cf-autoroot bye chainfire) via Odin SuperSU is not installed and
when I download it from the playstore it cannot update the binary..
you know why is that?
Click to expand...
Click to collapse
CF auto-root is only for stock rom. It's NOT for CM 12.1. I would reflash CM 12.1 without wiping just to make sure CF auto-root is gone.
Every CM rom contains root. You just have to enable it like GDReaper told you.
Thanks guys!
Runs smooth and I have root access via cm.
hi guys when I try to flash a rom appears the message "error excecuting updater binary in zip" someone know how to solve it?
Sorry for my bad english
Your English is fine. Check to make sure there are no spaces in the file name, and if there are, replace them with dashes or underscores. Then try running the zip again.
Strephon Alkhalikoi said:
Your English is fine. Check to make sure there are no spaces in the file name, and if there are, replace them with dashes or underscores. Then try running the zip again.
Click to expand...
Click to collapse
there is no space in the name :\ maybe can be a problem of the recovery's version ?
I mentioned it because the presence of spaces was the reason my copy of Optimized CM12 failed to install. What version of TWRP are you running?
2.8.5.0
Upgrade. 2.8.6.0 is available from the TWRP homepage (once the page comes back up), though I believe a customized copy is available for Alucard and Antares One's Optimized CM12 build in I9505 Original Android Development.
EDIT: 2,8.6.0 can be downloaded from here.
AntaresOne's TWRP will convert the system to F2FS automatically when flashing a rom. He said he was going to make it a choice in a future update. Don't know if he gotten around doing so.
GDReaper said:
AntaresOne's TWRP will convert the system to F2FS automatically when flashing a rom. He said he was going to make it a choice in a future update. Don't know if he gotten around doing so.
Click to expand...
Click to collapse
This problem started when I tried to flash cyano 12 based on 5.1.1 (by AntaresOne) before doing this everything was fine. Maybe the recovery couldn't convert system to F2FS, can be this?
Strephon Alkhalikoi said:
Upgrade. 2.8.6.0 is available from the TWRP homepage (once the page comes back up), though I believe a customized copy is available for Alucard and Antares One's Optimized CM12 build in I9505 Original Android Development.
EDIT: 2,8.6.0 can be downloaded from here.
Click to expand...
Click to collapse
Thank you, I will try it
eleonora97100 said:
Thank you, I will try it
Click to expand...
Click to collapse
It doesn't necessarily needs to be converted. It can run with the default ext4 too. Problem with converting is that it will wipe your internal storage. So that into account.
I had the binary updater issue occur on a flashable zip I made. The cause? I accidentally deleted the line that told TWRP to mount the system partition. Restoring the line solved the issue, so check the script. The developer may have accidentally missed a line.
thank you guys I upgraded the recovery and now it works fine thank you very much
I'm already try flash trough TWRP over leaked official nougat version.
Works fine just dalvik and cache wipe after flash.
this is international ver. (not like hydrogen Eng/Chinese only)
original post from official forum
https://forums.oneplus.net/threads/oxygenos-open-beta-1-n-for-oneplus-3t.482846/
If i were to flash over my stock OS, what do I need to delete (without losing pictures etc). I keep forgetting..
I have read that TWRP has some errors when flashing, not sure what this was.
vincedyne said:
If i were to flash over my stock OS, what do I need to delete (without losing pictures etc). I keep forgetting..
I have read that TWRP has some errors when flashing, not sure what this was.
Click to expand...
Click to collapse
Hi
You can try side-load, but you need backup for sure.
my device is root and bootloader is open and I have already Nougat beta ver. before there so my upgrade was quick and all files and settings remains.
hampik said:
Hi
You can try side-load, but you need backup for sure.
my device is root and bootloader is open and I have already Nougat beta ver. before there so my upgrade was quick and all files and settings remains.
Click to expand...
Click to collapse
Ahh. I'll look into this, thanks!
hampik said:
Hi
You can try side-load, but you need backup for sure.
my device is root and bootloader is open and I have already Nougat beta ver. before there so my upgrade was quick and all files and settings remains.
Click to expand...
Click to collapse
So you just flashed the zip in TWRP and SuperSU afterwards? Or did it take additional steps?
bmwbasti said:
So you just flashed the zip in TWRP and SuperSU aftwerwards? Or did it take additional steps?
Click to expand...
Click to collapse
No additional steps. Flash the zip, supersu and wipe cache and everything is working fine.
I'll give it a shot eventhough i'm still on 3.5.4 and not the leaked beta.
I'm guessing as this will have the original boot.img (kernel), as no custom Nougat kernels are yet built (have to wait on the source code) that it will once flashed Encrypt the phone again? Thus the need for the pin/password for twrp?
No point in flashing Open Beta; th official stable OTA is coming tonight too.
https://twitter.com/getpeid/status/815171834345885696
Deleted
So seems there are soon to be two channels beta and stable coming. Great stuff!
Are the sources for ROM and kernel up yet?
Can we side load this over the top of the leaked nougat ROM ?
Moderator Information,
Thread closed, we do not need multiple threads for this.