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.
I am getting into development more and have a new load of questions. And yes, I searched first.
Do all Roms include firmware(OS), kernal, baseband, and boot loader?
Do over-the-air updates include the baseband and boot loader, or only the kernal and firmware/(OS).
I once used the Wugfreth toolkit to reinstall the stock ROM. It flashed the baseband with the same version and then attempted to flash the boot loader with the same version, but failed. How can I JUST flash the kernal and firmware/os.
This may be dumb question, but what language is the boot loader and baseband written in? Is it encrypted, or can anyone edit it and flash?
What happens if the boot loader, baseband, kernal, and firmware versions do not match?
I did not know the ROM included the bootloader, and I almost purposely flash the ROM of another device to see what would happen, figuring I could have restored using fastboot. But that probably would have hard-bricked it, right? I thought flashing a ROM was completely safe because it did not touch the boot loader, and could always be undone with fastboot?
How do you developers test out modified bootloaders without making a simple coding mistake and ruining your device?
How can you flash a bootloader using itself (fastboot)?
I saw a post for a different device for changing the boot loader logo. Not the firmware's boot animation. I don't want mine to say "Google" with an unlock icon. Can this be done on the Nexus 7?
I read the partition sizes are determined by the boot loader, and not adjustable. Is this correct? I am running stock 4.4.3 and only have 11MB free on the system partition. How do custom Roms fit within this limit? I am worried this will prevent a custom ROM based in 5.0 Lollipop, and the Nexus 7 2012 will be stuck on Kitkat. Maybe the firmware could be loaded on the data partition with a symbolic link to the system partition?
Thank you
I'm not a developer, but can answer some of your questions (at least as they relate specifically to the Nexus 7).
Custom ROMS typically just include the firmware/kernel (and i believe the radio/baseband if it's for a 3g/mobile device, though these can also be flashed separately, and i could be wrong on this part.) Bootloader is typically untouched, but this might differ on other devices.
As for OTA updates and what all they include, well that depends on the device, manufacturer, carrier, and even the specific OTA. It could potentially include everything (firmware/kernel updates, bootloader, radio/baseband, etc.), but may be any combination of the different components.
Available free space on the system partition doesn't really matter if you're flashing a new ROM, because you'll be wiping the partition as part of the flashing process. ROMs typically don't include GAPPS either (unless it's just a modified version of stock), so will actually take up much less room than the stock ROM on their own. Then you can decide which GAPPS to flash separately, there are various packages available in different sizes; some just include the basic google play services needed to have the play store and related basic functionality, others will mirror the stock pre-installed apps.
If you're using a custom recovery to flash a ROM, they typically contain a script to first verify the device matches, if not, it won't even flash. If you do manage to flash an incompatible ROM (via fastboot maybe, or if it doesn't include a verification script), with a Nexus this typically is not a big deal, you just won't ever actually boot into the ROM, but should still be able to boot into recovery or bootloader and then flash a compatible ROM.
If you flash an incompatible kernel on top of a ROM, you'll likely get a bootloop/softbricked device.
Flashing an incompatible bootloader may brick the device. Any tinkering with the bootloader is always risky.
Hope that helps a little, I'll take another look when I'm not at work
flyoffacliff said:
I am getting into development more and have a new load of questions. And yes, I searched first.
Do all Roms include firmware(OS), kernal, baseband, and boot loader?
Do over-the-air updates include the baseband and boot loader, or only the kernal and firmware/(OS).
I once used the Wugfreth toolkit to reinstall the stock ROM. It flashed the baseband with the same version and then attempted to flash the boot loader with the same version, but failed. How can I JUST flash the kernal and firmware/os.
This may be dumb question, but what language is the boot loader and baseband written in? Is it encrypted, or can anyone edit it and flash?
What happens if the boot loader, baseband, kernal, and firmware versions do not match?
I did not know the ROM included the bootloader, and I almost purposely flash the ROM of another device to see what would happen, figuring I could have restored using fastboot. But that probably would have hard-bricked it, right? I thought flashing a ROM was completely safe because it did not touch the boot loader, and could always be undone with fastboot?
How do you developers test out modified bootloaders without making a simple coding mistake and ruining your device?
How can you flash a bootloader using itself (fastboot)?
I saw a post for a different device for changing the boot loader logo. Not the firmware's boot animation. I don't want mine to say "Google" with an unlock icon. Can this be done on the Nexus 7?
I read the partition sizes are determined by the boot loader, and not adjustable. Is this correct? I am running stock 4.4.3 and only have 11MB free on the system partition. How do custom Roms fit within this limit? I am worried this will prevent a custom ROM based in 5.0 Lollipop, and the Nexus 7 2012 will be stuck on Kitkat. Maybe the firmware could be loaded on the data partition with a symbolic link to the system partition?
Thank you
Click to expand...
Click to collapse
1. roms dont include a bootloader.
2. no
3. easily in a custom recovery.
4. i have no idea, and its the most secure part of the device.
5. nothing.
6. roms DO NOT EVER include bootloaders.
7. developers on nexus devices never modify the bootloader. first off, its extremely tedious and difficult. secondly, there is no need, as our bootloaders are unlockable and lockable.
8. it overwrites itself, but you are on your computer using fastboot, phone is just plugged into it.
9. no.
10. each partition has its own size. roms go into a partition that also holds your storage, and is separated from the storage. another reason why you dont have 16gb storage when you buy a 16gb device, because some of it gets allocated to the system.
Hi guys,
I've seen this question asked a few times, but no one ever answers it. I tried looking around on other sites, but can't seem to find an answer.
I just came over from a Galaxy S5, and I don't think we ever used those. Is there anybody who'd be willing to point me in the direction of knowing?
It holds proprietary binaries for the Nexus 5x, 6p and 9, from what I've read.
Hey OP, did you find out what a vendor.img is yet? Have also come to Nexus from Samsung. Flashing my first rom, and don't know what this vendor file is. Or if I even need it. Like you, have found threads where people ask, but no definitive answers...
I've been curious about this, too.
Also wondering how the Vendor partition differs from System. What do the data/functions in the Vendor partition do?
EFS partition seems to be specific to the individual device (unique IMEI). Is Vendor specific to each phone too, or do all Nexus 6Ps have the same thing in the Vendor partition (assuming they're on the same build of Android)?
The vendor.img is important to this device if you upgrade your OS. You might have to flash it with every update too or your camera won´t work. This IMG is indeed strange if you´re used to older devices which are not as complicated.
Gorgtech said:
The vendor.img is important to this device if you upgrade your OS. You might have to flash it with every update too or your camera won´t work. This IMG is indeed strange if you´re used to older devices which are not as complicated.
Click to expand...
Click to collapse
OK cool, so the vendor file is Nexus specific. And the OS won't operate properly without it? So I assume it's not possible to bake the vendor file straight into a custom rom? Just flashed pure nexus vendor.img along with the rom. Still not exactly sure what it does, but hey, if I need it, I'll flash it if I change roms.
Gorgtech said:
The vendor.img is important to this device if you upgrade your OS. You might have to flash it with every update too or your camera won´t work. This IMG is indeed strange if you´re used to older devices which are not as complicated.
Click to expand...
Click to collapse
Supplemental information about Vendor from a former member of the Android team
SlimSnoopOS said:
Supplemental information about Vendor from a former member of the Android team
Click to expand...
Click to collapse
Thanks for the link. So from my understanding, all the proprietary nexus files are stored on it's own 'vendor' partition, separate from the OS. And is updatable with it's own .img. Which is different to touchwiz (for eg.), which merges it's own files with android into the one partition.
Edit: FYI, just found this in PureNexus FAQ's:
Q: What is the vendor.img/vendor.zip? (5X and 6P only)
A: The vendor partition is new to Nexus phones with the 5X and 6P. Previous devices had the vendor files (proprietary binaries and drivers) within the system partition (/system/vendor); on these devices, they now have it in their own partition (/vendor). If this is not up to date, you will get an error message and need to flash the latest one so your phone continues to work properly. Beans has made this a TWRP flashable file available in the OP of the 5X and 6P threads (also linked below) so you do not have to fastboot it.
I'm a bit late on this one, but does anyone know if updating OTA (stock android updater) updates the vendor partition as well or do you specifically have to flash it?
So, with this partition for drivers ROMs can keep the same camera quality as stock?
Llaver said:
I'm a bit late on this one, but does anyone know if updating OTA (stock android updater) updates the vendor partition as well or do you specifically have to flash it?
Click to expand...
Click to collapse
No, the vendor.img does not need to be flashed independently of the OTA update.
I have seen it in many phones other than mentioned in the thread, it is even in infinix phones. what i think is it contains apps from google like maps, drive, gmail, photos, and also some apps from the manufacturer of the phone. why i think this is the case? here is the my guess.
yesterday when i tried to remove google bloatware and manufacturer bloatware with root permissions etc. it didn't work.
i have magisk root, i had set selinux permissive as someone told me it would help BUT i was still unable to remove bloatware. they were removed for now but whenever i rebooted my phone, they were reinstalled and i think this vendor file does that.
as per google's android documents here is the difinitoin.
vendor: The vendor partition contains any binary that is not distributable to the Android open source project.
means, google apps are never distributed with AOSP but manufacturers does that via vendor.img to make it non-removable? i guess.
jameeldroid said:
I have seen it in many phones other than mentioned in the thread, it is even in infinix phones. what i think is it contains apps from google like maps, drive, gmail, photos, and also some apps from the manufacturer of the phone. why i think this is the case? here is the my guess.
yesterday when i tried to remove google bloatware and manufacturer bloatware with root permissions etc. it didn't work.
i have magisk root, i had set selinux permissive as someone told me it would help BUT i was still unable to remove bloatware. they were removed for now but whenever i rebooted my phone, they were reinstalled and i think this vendor file does that.
as per google's android documents here is the difinitoin.
vendor: The vendor partition contains any binary that is not distributable to the Android open source project.
means, google apps are never distributed with AOSP but manufacturers does that via vendor.img to make it non-removable? i guess.
Click to expand...
Click to collapse
????? This is a nexus, it contains no bloat because its a google device, its not a Motorola , lg, samjunk etc. Those devices contain "bloat" there are zero applications installed from the mfg, its stock android.
Not sure why you can't remove system apps, sounds like user error. I have never had an issue removing something with root and titanium backup.
The vendor contains what it says it does the binarys, blobs and other interworking's of the device that are needed for it to operate.
Hello. I'm a new to Android world. I have a Moto G4 (XT1622) and I install AOSiP-8.1-Derp-athene-20180501/Android Open Source Illusion Project ROM (arm64).
I see 'your vendor image does not match the system' message on every boot with a prompt to flash npjs25.93-14-13.
I download latest Nougat ROMs (arm32) (both adb and twrp flashable). Try both methods of flashing with success.
Then I install custom ROM again (with TWRP, clean) and see the same message again.
I search regarding this problem and everything ends with flashing Stock ROM and perform installing custom one again, what I done and mention of vendor.img file.
I try to find such file but no luck, my device has only vendor folder.
So my question is: how to remove this message in the custom ROM?
I post it here because ROM's thread is closed
Thanks.
I just got my N6P and am coming from the N6 and I have to say I love this phone. I unlocked and rooted my N6P right away. I am no stranger to root and custom Roms. Right now I am on the stock ROM because something is throwing me off a little.
What is the deal with the vendor images? The N6 didn't have them (at least you didn't have to mess with them when you flashed a ROM). My question is this, do you have to flash a vendor image in fastboot each time you flash a ROM? I want to flash some Roms, but until I know more about the vendor images I am holding off on any flashing.
Sent from my Nexus 6P using XDA-Developers mobile app
You only need to flash the vendor image once per new build number. So say you are on a ROM with build XXXXXX and you are updating to YYYYYY. You still flash the ROM then the YYYYYY vendor image. If there is another ROM you want to try on YYYYYY, you don't have to flash the YYYYYY vendor image again.
The vendor image files are a bunch of proprietary binaries and drivers that allow your phone to run properly. These vendor files were originally in /system on all previous Nexus devices but starting with the Nexus 9, they were moved to their own partition, /vendor. Super convenient for ROM developers since they no longer have to include those files from the factory images; instead, people can just flash the images directly from Google.
nathanchance said:
You only need to flash the vendor image once per new build number. So say you are on a ROM with build XXXXXX and you are updating to YYYYYY. You still flash the ROM then the YYYYYY vendor image. If there is another ROM you want to try on YYYYYY, you don't have to flash the YYYYYY vendor image again.
The vendor image files are a bunch of proprietary binaries and drivers that allow your phone to run properly. These vendor files were originally in /system on all previous Nexus devices but starting with the Nexus 9, they were moved to their own partition, /vendor. Super convenient for ROM developers since they no longer have to include those files from the factory images; instead, people can just flash the images directly from Google.
Click to expand...
Click to collapse
Thank you for your reply. That makes sense. I appreciate it very much.
Sent from my Nexus 6P using XDA-Developers mobile app
nathanchance said:
You only need to flash the vendor image once per new build number. So say you are on a ROM with build XXXXXX and you are updating to YYYYYY. You still flash the ROM then the YYYYYY vendor image. If there is another ROM you want to try on YYYYYY, you don't have to flash the YYYYYY vendor image again.
The vendor image files are a bunch of proprietary binaries and drivers that allow your phone to run properly. These vendor files were originally in /system on all previous Nexus devices but starting with the Nexus 9, they were moved to their own partition, /vendor. Super convenient for ROM developers since they no longer have to include those files from the factory images; instead, people can just flash the images directly from Google.
Click to expand...
Click to collapse
That might not be entirely accurate. Layers installs to the vendor partition, and I believe some aspects of gapps might too. It's best just to flash the vendor whenever flashing a ROM to ensure there's no residual data that could cause problems.
Heisenberg said:
That might not be entirely accurate. Layers installs to the vendor partition, and I believe some aspects of gapps might too. It's best just to flash the vendor whenever flashing a ROM to ensure there's no residual data that could cause problems.
Click to expand...
Click to collapse
Yes, I'll give you that. Just not strictly necessary but it is good practice
nathanchance said:
Yes, I'll give you that. Just not strictly necessary but it is good practice
Click to expand...
Click to collapse
I'd totally define it as being necessary, not flashing the vendor is very much like dirty flashing one ROM over another. Plus, it's things like failing to flash the vendor that cause bogus bug reports in ROM threads and waste everyone's time.
Heisenberg said:
That might not be entirely accurate. Layers installs to the vendor partition, and I believe some aspects of gapps might too. It's best just to flash the vendor whenever flashing a ROM to ensure there's no residual data that could cause problems.
Click to expand...
Click to collapse
Some gapps packages may install to /vendor? Do you have any info on what packages or types of files from gapps package would get installed in /vendor?
Sent from my Nexus 5X using Tapatalk
SlimSnoopOS said:
Some gapps packages may install to /vendor? Do you have any info on what packages or types of files from gapps package would get installed in /vendor?
Sent from my Nexus 5X using Tapatalk
Click to expand...
Click to collapse
I honestly don't know, I believe I read it somewhere but I can't remember where.
Heisenberg said:
I honestly don't know, I believe I read it somewhere but I can't remember where.
Click to expand...
Click to collapse
No worries, I'm sure one of us will stumble on it soon enough
Sent from my Nexus 5X using Tapatalk
SlimSnoopOS said:
Some gapps packages may install to /vendor? Do you have any info on what packages or types of files from gapps package would get installed in /vendor?
Sent from my Nexus 5X using Tapatalk
Click to expand...
Click to collapse
Looking at the installer script in OpenGapps, nothing gets added to the /vendor partition. Google apps are installed onto the system, while vendor is a list of proprietary blobs.
DJBhardwaj said:
Looking at the installer script in OpenGapps, nothing gets added to the /vendor partition. Google apps are installed onto the system, while vendor is a list of proprietary blobs.
Click to expand...
Click to collapse
Yeah I looked at the same thing just before. We can disregard that portion of what I said, the information I read was obviously wrong.
Is it necessary to flash vendor images when using the stock ROM from Google then rooting after clean flash it?
Thanks!
fresnogamer said:
Is it necessary to flash vendor images when using the stock ROM from Google then rooting after clean flash it?
Thanks!
Click to expand...
Click to collapse
Nope. Flashing vendor is only required when switching to a different security update. The root and/or clean flash process does not touch the /vendor partition.
Sent from my Nexus 5X using Tapatalk
Thank you for the info.
Hi, All . . .
I believe it would be appropriate to label me as an intermediate-to-advanced newbie. That is, I'm not clueless, but there are lots of blind spots in my knowledge.
I just bought a 6P and while I've been waiting for my SIM card to arrive, I've gone ahead and rooted, installed TWRP 3.0.3-0, and made a few customizations here and there. One thing I don't understand is the significance of the vendor image now. I'm coming from a 6 where that wasn't an issue. Also, in the rooting instructions it indicates that one should "find the correct vendor image," without really indicating how one can go about learning which one is "right." In the end, I took the latest one I could find, because my phone did an OTA update and I simply reasoned that I should match latest with latest.
In any case, I want to install MultiROM and I keep running into this problem:
The MultiROM version of TWRP doesn't load. It hangs on the splash screen. The version it uses is 3.0.2-0, so I suspected it was an issue with that. I flashed the TWRP-only recovery version 3.0.2-0 after having no luck, and it wouldn't load beyond the splash screen, either. Finally, I re-flashed the stock system recovery and tried flashing both the 3.0.2-0 TWRP-only recovery and the MultiROM-integrated version, both without success.
Is there something about the move from 3.0.2-0 to 3.0.3-0 that makes a rollback impossible. Is it even necessary?
Re-flashing 3.0.3-0 solved the problem of basic functionality. TWRP comes right up after I do that. But I can't get the MultiROM recovery or the 3.0.2-0 TWRP recovery to work no matter what I try.
My phone says that the vendor version is N4F26J and my "build number" is N6F26Q, and I'm running PureNexus 7.1.1. Those two numbers appear like a mismatch to me, but everything I could find indicated that the vendor version I have, being the latest, is the right one.
What am I missing? Can someone with more experience solve this puzzle, or at least lead me in a direction where I know which questions to ask on my own and can get things to start making sense again?
I appreciate your help! Thanks!
KilgoreTrout71 said:
Hi, All . . .
I believe it would be appropriate to label me as an intermediate-to-advanced newbie. That is, I'm not clueless, but there are lots of blind spots in my knowledge.
I just bought a 6P and while I've been waiting for my SIM card to arrive, I've gone ahead and rooted, installed TWRP 3.0.3-0, and made a few customizations here and there. One thing I don't understand is the significance of the vendor image now. I'm coming from a 6 where that wasn't an issue. Also, in the rooting instructions it indicates that one should "find the correct vendor image," without really indicating how one can go about learning which one is "right." In the end, I took the latest one I could find, because my phone did an OTA update and I simply reasoned that I should match latest with latest.
In any case, I want to install MultiROM and I keep running into this problem:
The MultiROM version of TWRP doesn't load. It hangs on the splash screen. The version it uses is 3.0.2-0, so I suspected it was an issue with that. I flashed the TWRP-only recovery version 3.0.2-0 after having no luck, and it wouldn't load beyond the splash screen, either. Finally, I re-flashed the stock system recovery and tried flashing both the 3.0.2-0 TWRP-only recovery and the MultiROM-integrated version, both without success.
Is there something about the move from 3.0.2-0 to 3.0.3-0 that makes a rollback impossible. Is it even necessary?
Re-flashing 3.0.3-0 solved the problem of basic functionality. TWRP comes right up after I do that. But I can't get the MultiROM recovery or the 3.0.2-0 TWRP recovery to work no matter what I try.
My phone says that the vendor version is N4F26J and my "build number" is N6F26Q, and I'm running PureNexus 7.1.1. Those two numbers appear like a mismatch to me, but everything I could find indicated that the vendor version I have, being the latest, is the right one.
What am I missing? Can someone with more experience solve this puzzle, or at least lead me in a direction where I know which questions to ask on my own and can get things to start making sense again?
I appreciate your help! Thanks!
Click to expand...
Click to collapse
Hey there,
Regarding your TWRP 3.0.2-0/MultiRom 3.0.2-0 and TWRP 3.0.3 issues, check out post #1152 in the official TWRP 6P thread. If there is an update to MR to support Nougat encryption, you'll just have to follow the MR thread or Github for updates.
Here's a brief explainer from my guide in the Nexus 5X forums about Vendor.img:
9. After updating my ROM, I get this message on every boot: "There's an internal problem with your device. Contact your manufacturer."
This warning signifies a mismatched vendor and system partition. The vendor partition was integrated in the system partition for previous Nexus devices but is now a separate partition that must be flashed for each Google security update. Download a factory image and update your vendor partition using fastboot so that it matches your rom's OS base. If you have a file explorer installed on your phone, you can determine which vendor.img is installed by navigating to /vendor/build.prop and clicking on the build.prop. The specific vendor installed will be a combination of six numbers and letters listed in all capitals (example: NMF26F) in the ro.vendor.build.fingerprint line.
Vendor.img is specific to each OTA and contains proprietary binaries for the phone. The phone will fail to boot if you mismatch the vendor.img with a different OS base. For instance, a 6.0 Marshmallow vendor.img will not allow your phone to boot on 7.0 Nougat.
Click to expand...
Click to collapse
Hope this clears things up for you!
Edit: Also, certain rom teams keep an up to date listing of vendor.img available on their websites. Usually this is detailed in the rom thread OP. Find a reliable thread and bookmark their vendor.img downloads, if not download the factory image each month and extract the img.
SlimSnoopOS said:
Hey there,
Regarding your TWRP 3.0.2-0/MultiRom 3.0.2-0 and TWRP 3.0.3 issues, check out post #1152 in the official TWRP 6P thread. If there is an update to MR to support Nougat encryption, you'll just have to follow the MR thread or Github for updates.
Here's a brief explainer from my guide in the Nexus 5X forums about Vendor.img:
Hope this clears things up for you!
Edit: Also, certain rom teams keep an up to date listing of vendor.img available on their websites. Usually this is detailed in the rom thread OP. Find a reliable thread and bookmark their vendor.img downloads, if not download the factory image each month and extract the img.
Click to expand...
Click to collapse
Thanks so much for the swift reply! I'll check these links out right away. I'm sure they will fill in the gaps for me.
Best,
KT
KilgoreTrout71 said:
Hi, All . . .
I believe it would be appropriate to label me as an intermediate-to-advanced newbie. That is, I'm not clueless, but there are lots of blind spots in my knowledge.
I just bought a 6P and while I've been waiting for my SIM card to arrive, I've gone ahead and rooted, installed TWRP 3.0.3-0, and made a few customizations here and there. One thing I don't understand is the significance of the vendor image now. I'm coming from a 6 where that wasn't an issue. Also, in the rooting instructions it indicates that one should "find the correct vendor image," without really indicating how one can go about learning which one is "right." In the end, I took the latest one I could find, because my phone did an OTA update and I simply reasoned that I should match latest with latest.
In any case, I want to install MultiROM and I keep running into this problem:
The MultiROM version of TWRP doesn't load. It hangs on the splash screen. The version it uses is 3.0.2-0, so I suspected it was an issue with that. I flashed the TWRP-only recovery version 3.0.2-0 after having no luck, and it wouldn't load beyond the splash screen, either. Finally, I re-flashed the stock system recovery and tried flashing both the 3.0.2-0 TWRP-only recovery and the MultiROM-integrated version, both without success.
Is there something about the move from 3.0.2-0 to 3.0.3-0 that makes a rollback impossible. Is it even necessary?
Re-flashing 3.0.3-0 solved the problem of basic functionality. TWRP comes right up after I do that. But I can't get the MultiROM recovery or the 3.0.2-0 TWRP recovery to work no matter what I try.
My phone says that the vendor version is N4F26J and my "build number" is N6F26Q, and I'm running PureNexus 7.1.1. Those two numbers appear like a mismatch to me, but everything I could find indicated that the vendor version I have, being the latest, is the right one.
What am I missing? Can someone with more experience solve this puzzle, or at least lead me in a direction where I know which questions to ask on my own and can get things to start making sense again?
I appreciate your help! Thanks!
Click to expand...
Click to collapse
Your vendor image and build number do sound like they are mismatched. If you can't find the vendor image you need on XDA you can find the matching build on the Google site, download the whole factory image and unzip it and get the vendor image that way.
I believe TWRP 3.0.2-0 was buggy. I'm not familiar with Multi rom and I don't know why they would use that build. You should be using 3.0.2-3 or 3.0.3-0.
I personally wouldn't install a custom ROM before activating the phone. I know a couple people have reported in the past that they were unable to activate their phone on a custom ROM. Hopefully you won't have that issue.
jhs39 said:
I believe TWRP 3.0.2-0 was buggy. I'm not familiar with Multi rom and I don't know why they would use that build. You should be using 3.0.2-3 or 3.0.3-0..
Click to expand...
Click to collapse
MultiRom support for this device was released when Marshmallow was out. So MR33 is based on the Marshmallow branch and ships with 3.0.2. The developer just isn't ready to release support for Nougat 7.0 and couple that with the issues of TWRP 3.0.2-x. He's actively pushing commits to support Nougat.
Sent from my Nexus 5X using Tapatalk
jhs39 said:
Your vendor image and build number do sound like they are mismatched. If you can't find the vendor image you need on XDA you can find the matching build on the Google site, download the whole factory image and unzip it and get the vendor image that way.
I believe TWRP 3.0.2-0 was buggy. I'm not familiar with Multi rom and I don't know why they would use that build. You should be using 3.0.2-3 or 3.0.3-0.
I personally wouldn't install a custom ROM before activating the phone. I know a couple people have reported in the past that they were unable to activate their phone on a custom ROM. Hopefully you won't have that issue.
Click to expand...
Click to collapse
Thanks for the input! I actually just got my card and some of the activation seems complete. (I got my voice mails and so on, but no data connection yet.) I didn't have a problem with the Nexus 6 on PureNexus, but we'll have to see how this one plays out. I'm not able to call over WiFi yet.
KilgoreTrout71 said:
Thanks for the input! I actually just got my card and some of the activation seems complete. (I got my voice mails and so on, but no data connection yet.) I didn't have a problem with the Nexus 6 on PureNexus, but we'll have to see how this one plays out. I'm not able to call over WiFi yet.
Click to expand...
Click to collapse
It might just take a while for the service to go through. Good luck.