Develop Bugs

[Q] What does a nandroid backup contain?

When I perform a backup from recovery (or via a front-end such as ROM Manager), what exactly is saved?
Is it like a clone of a hard drive in the PC world?
Does it contain only data, and not the actual ROM?
How should I go about using such a backup when doing a restore? Should a ROM be installed first, followed by the restore? If so, must the ROM match the backup exactly -- that is, must it be the ROM under which the backup was performed in the first place?

kirkers said:
When I perform a backup from recovery (or via a front-end such as ROM Manager), what exactly is saved?
Is it like a clone of a hard drive in the PC world?
Click to expand...
Click to collapse
That's a pretty close analogy. Only difference is I don't think it captures partitions...but I'm not sure about that. (It's not clear to me, for instance, if you did a nandroid of a phone with the EXT4 mod implemented and tried to install it on a phone without the EXT4 mod, exactly how that would play out.)
As an example, though, I took a nandroid of my stock phone immediately after I rooted it and got S-off. I then played around with various CM7, CM9, and JB ROMs for a weekend, but reloaded the stock nandroid Sunday night before going back to work on Monday. (I need a reliable phone for work.)
My phone was restored to exactly the way it was when I took the nandroid snapshot. I had to re-download a handful of app updates and email that had arrived since the time I took the nandroid to "catch up" to the present time, but that's all.

kirkers said:
When I perform a backup from recovery (or via a front-end such as ROM Manager), what exactly is saved?
Is it like a clone of a hard drive in the PC world?
Does it contain only data, and not the actual ROM?
How should I go about using such a backup when doing a restore? Should a ROM be installed first, followed by the restore? If so, must the ROM match the backup exactly -- that is, must it be the ROM under which the backup was performed in the first place?
Click to expand...
Click to collapse
It is everything on your phone at the current time when you made a backup. Including your rom, apps, files, boot animation and e.t.c.
Sent from my EVO using Tapatalk 2

Impact of EXT4 partition on nandroid backup + restore?
sully9292 said:
It is everything on your phone at the current time when you made a backup. Including your rom, apps, files, boot animation and e.t.c.
Click to expand...
Click to collapse
MysticCobra said:
[The PC clone image is] a pretty close analogy. Only difference is I don't think it captures partitions...but I'm not sure about that. (It's not clear to me, for instance, if you did a nandroid of a phone with the EXT4 mod implemented and tried to install it on a phone without the EXT4 mod, exactly how that would play out.)
Click to expand...
Click to collapse
Thanks for the clarifications and the personal experience story. It helps calm my nerves. :fingers-crossed: Now it is clear that the nandroid is a full snapshot, close to being a clone image.
Can anyone address MysticCobra's point about the EXT4 partition?
As a rule, I have followed ROM Manager app's recommendation to partition the sdcard to allow apps to be stored on it. This is what the EXT4 partition is designed to do, as far as I understand such things.
If I format the sdcard with EXT4 (which in my experience wipes out all data on the card), and then restore a nandroid that came from an older EXT4-formatted sdcard of the same size or smaller than the new sdcard, would the nandroid restoration go smoothly?
What would happen if the new sdcard did NOT have an EXT4 partition?
Thanks in advance for further advice.
:good: Cheers!

kirkers said:
Thanks for the clarifications and the personal experience story. It helps calm my nerves. :fingers-crossed: Now it is clear that the nandroid is a full snapshot, close to being a clone image.
Can anyone address MysticCobra's point about the EXT4 partition?
As a rule, I have followed ROM Manager app's recommendation to partition the sdcard to allow apps to be stored on it. This is what the EXT4 partition is designed to do, as far as I understand such things.
If I format the sdcard with EXT4 (which in my experience wipes out all data on the card), and then restore a nandroid that came from an older EXT4-formatted sdcard of the same size or smaller than the new sdcard, would the nandroid restoration go smoothly?
What would happen if the new sdcard did NOT have an EXT4 partition?
Thanks in advance for further advice.
:good: Cheers!
Click to expand...
Click to collapse
Nandroid backup/restores don't touch the sdcard. They backup to the sdcard but the nandroid only handles /system, /data, /data/data, /cache, boot, and recovery.
The ext4 partition is not the same as the ext4 mod that MysticCobra mentioned. The mod converts /data, and /cache to ext4 and changes the ramdisk to mount them as ext4. The no data limit one also disables the mounting /data/data so the phone will share the apps and app data with a 750MB. Your app data is intact with the no data limit mod but a backup is still advised. No wipe updates don't touch the filesystem in /data or /cache but the mod may need to be flashed again for the ROM to boot correctly as the ramdisk is overridden on all updates. Technically with the normal data one you are good on later cm7 and ICS/JB ROMs as it's already ext4.
If you want to undo the mod the best thing is to wipe /data and /cache and reflash the ROM.
For further reading check the first link in the link below:
http://forum.xda-developers.com/showthread.php?t=1623038

[TASKER/CWM]Full NAND while you sleep!

DISCLAIMER: <insert generic XDA disclaimer here>
Hey guys, first things first. I'm not a programmer/dev or even clever so bear this in mind when trying this.
I wanna share a Tasker with you all that when used in conjunction with PhilZ Touch 4.88.5 Touch Enhanced CWM 6.0.2.9 Recovery and anopen recovery script can allow your phone to perform a NAND backup while you sleep or whenever you want.
Philz has managed to get ors working in his recovery which means that the recovery with be able to perform custom backup jobs once you select them in recovery and run them. Now, READ this aboutopen recovery script to find out about ors because I'm not one for giving fish to men, rather teach them to fish! Read it? Good... moving on...
The ors support is great but having to select them and run them is not so great for me and that is where this trick comes in handy.
What this task does...
It copies an already created (user created) ors script to /cache/recovery, deletes the previously backed up backup folder (if any), reboots into recovery (provided you have 50% battery). Recovery then runs the script, backs up and reboots into the ROM. If at boot, the backup was made, a notification comes up telling you this and the time it was done at and also writes this to a log file in /mnt/sdcard0/clockworkmod.
I'll leave it up to you to figure the tasks out and how they work if you want a better understanding.
Quick tip:
The backup folder is set to clockworkmod>backup BUT the sdcard to which the backup is made is selectable in recovery under: Backup and restore>Misc Nandroid Settings>ORS Backup Target. So in other words you can't define /mnt/sdcard0/SILLY/NOOB as the backup folder, it can only be either /mnt/sdcard0/clockworkmod/backup/*my folder* or /mnt/extsdcard/clockworkmod/backup/*my folder*. This being said, all you need to do is define the *my folder* name under /mnt/*/clockworkmod/backup/*my folder* in the script which could just be /Tasker_Backup Capeesh?
Another thing that I must mention is my reason for creating a openrecoveryscript file and copying it to /cache/recovery rather than just writing a file directly into /cache/recovery is that it seems like either Tasker or Android doesn't like creating a file directly in /cache/recovery but doesn't seem to mind copying a file to the location.
Instructions:
1.You need to create a file on your sdcard called openrecoveryscript.txt in a place you will remember (I put mine in the mnt/sdcard0/clockworkmod)
2.Once you created the file, open it and enter your backup job, the order in which you enter your commands aren't important, any permutation will do (BDASC or ASDBC).
3.When you're done, save the file and REMOVE the ".txt" extension.
4.Import my Tasker profiles (NAND backup and NAND notify) into Tasker and open the task "NAND backup" and edit the path in the 9th and 11th action to the clockworkmod folder on either the local or external sdcard. (depending on the selection that you made under: Backup and restore>Misc Nandroid Settings>ORS Backup Target)
5.Set the time and date that you want the backup happen on.
6.Thats it!
Suggestions:
I would advise against setting the internal sdcard as the backup location because replacing an external sd is far easier than replacing an internal one when it burns out from large amounts of writes in addition to this, I would recommend backing up about once per week (depending on your addiction to flash) to reduce the strain on the sdcard. But this is only my suggestion.
Attached is a zip of the profiles and the ors that I use, just remember to remove the ".txt" from the "openrecoveryscrip.txt" before using it.
DON'T FLASH IT, IT IS NOT A CWM ZIP!!
This is by no means perfect but rather to provide a point of departure in helping others create similar tasks to automate their backups to their preference so please rename, delete and add as much as you like. Maybe post your findings too!
Remember, if you don't understand do the following (in order): search, read, think, SEARCH, READ, THINK, SEARCH!, READ!, THINK! ask.
Good luck
I would like to give credit to
Phil3759 for developing a great recovery that makes the whole party possible.
rootSU for his post which is far more thought out than mine but none the less got me'a thinkin.

Thank you for the guide (my 8 :good: are done today...)
I just add this so people do not browse much:
The file /cache/recovery/openrecoveryscript
Code:
backup SDCR123BAEOM foldername_not_full_path
S System partition
D Data partition
C Cache partition
R Recovery partition
1 Special partition 1
2 Special partition 2
3 Special partition 3
B Boot (kernel) partition
A .android_secure
E sd-ext partition
O Enable backup compression
M Do not create MD5sums
foldername Optional (if not specified, a folder with timestamp is created, so you do not have to delete previous folder)
Currently, 1, 2 and 3 are not supported. I could assign modem and efs to them later, but I do not think it is really useful

How to create a custom partition? (Not related to the SDCARD)

Hi,
I am trying to figure out ways to create a new partition additionally to the standard ones, like system, boot or data. As the title indicates, my intention is not to create an ext4 partition inside the sdcard to put apps into it, my end goal is completely different as the first sentence indicates.
Do I need to do it at build time? Or can it be done at boot time (by starting a service that uses fdisk via init.rc)? Any resources that could help me understand what needs to be done?
Thanks!

[Q] Function of Nexus 5X partitions, and which to back up

Hi,
Where can I find an explanation of the Nexus 5X partitions, and which of those are changed during use and are a good idea to back up?
Coming from Nexus 7 3G 2012, I see the 5X has quite a few more partitions. I've searched this site and the wider Internet for their purpose but have come up only with a parted listing without explanation.
E.g. what typically goes into "vendor", why do "system" and "vendor" have "... image" counterparts, and what exactly goes into the crucial "EFS" partition?
Following from that, it seems that an unlocked but otherwise unmodified device can be fully restored from the factory image and a data partition backup (apart from perhaps needing to restore EFS in extreme cases), right?
Or are there other partitions that may get modified during normal use and need to be backed up too?

I've come across one of the answers.
It seems the vendor partition contains the platform-specific drivers/binaries that were previously stored in the /system partition: https://plus.google.com/+JeanBaptisteQueru/posts/akHWypRNEn3.

...and according to this the "... image" selections aren't device partitions, but TWRP options to add fastboot flashable image backups of the corresponding partitions.

fvisagie said:
what exactly goes into the crucial "EFS" partition?
Click to expand...
Click to collapse
Continuing the monologue, although I haven't found a definitive source, most authorative-sounding ones like this one and this one claim it contains device-specific IDs, mostly connectivity, such as IMEI/ESN, Wi-Fi and Bluetooth MAC addresses, network unlock information etc.
fvisagie said:
Following from that, it seems that an unlocked but otherwise unmodified device can be fully restored from the factory image and a data partition backup (apart from perhaps needing to restore EFS in extreme cases), right?
Or are there other partitions that may get modified during normal use and need to be backed up too?
Click to expand...
Click to collapse
I recall from a previous experience that to be completely safe, user data/internal storage (/sdcard) needs to be backed up and restored too. Most Android apps that had been run and had created data on /sdcard before the backup will fail to run if restored without their /sdcard content.

Installing LOS 15.1 on Nexus 4 with open GApps no longer possible??

Hi, what are the storage requirements for the /system partition for LOS 15.1?
I tried upgrading LOS 14.1 + opengapps nano to 15.1 + opengapps nano after the updater notified me of availability.
Initial attempt to upgrade the system ended in failure (made apparent with opengapps installer, not LOS) which I tracked down to the LOS installer completely exhausting the free space on /system - the build.prop file was empty and opengapps refused to install, citing incorrect SDK version.
So next I tried wiping the /system partition and then installing both again - LOS installer finished successfully, but this left free space of only ~120 MiB, not enough for opengapps nano. Is it expected that a fresh install of LOS without opengapps takes ~700MiB?

I used pico. Wipe the system area, install the nightly, Mount system, delete system/app/jelly or system/app/email and then install gapps.

st3v3ntehl33t said:
I used pico. Wipe the system area, install the nightly, Mount system, delete system/app/jelly or system/app/email and then install gapps.
Click to expand...
Click to collapse
Sorry, can't quickly try that - already reverted the device to the backup of 14.1 Do you mean you had to delete stock LOS apps to even install the pico opengapps package?
According to description, the diff between pico and nano is Health services and Google search, neither of which is installable from the play store, AFAICT (and would prefer to leave them in). Is there an option for a proper solution, eg. repartitioning the flash so that the system partition is big enough to hold it all? (How big is the system partition on phones factory-shipped with Android 8.1, anyway?)

Yes, that's correct there's not enough space to install gapps with all the factory apps installed. It was asked how this ROM could even go official with lineage when you have to do this work around to get play store functionality but technically having the play store is not a requirement for lineage os. (There's other options). Afaik it's only an issue because of the size of the actual system allocated area (call it a partition if you want) on the Nexus 4 itself. After you get it installed you can install apps to replace the ones you deleted.

Glad I found this post. Thanks for the details, because I was going around in circles trying to figure out what could be wrong.
While GApps are technically not "required", not allowing space for their install - which is likely very common - seems very short-sighted. Furthermore, the Install page offers the option (instructions) of flashing the GApps zip. If they're not going to leave any room for it, they should either document that, or mention that they didn't leave any room for you to do it. And really, the partition should just be sized big enough to allow for it.

st3v3ntehl33t said:
I used pico. Wipe the system area, install the nightly, Mount system, delete system/app/jelly or system/app/email and then install gapps.
Click to expand...
Click to collapse
Thank you, pico actually worked!

To anyone is still not on LOS 15:
Repartitioning is fairly simple (although time-consuming, expect the data transfers to/from PC to take ~90 minutes in total), as the device's storage uses plain GPT as a partitioning scheme. Reposting my answer on stackexchange:
I eventually found this thread, where the author prepared an archive with gdisk and a few other tools.
Requirements:
Computer/VM with adb, fsck.ext4 and resize2fs
This zip file
Overview
The relevant partitions (system and userdata) are 21st and 23rd on the storage. The 22nd partition is just cache, so there's no harm nuking it, and making a new one after data from the other 2 are in place.
The TL;DR version of the procedure is:
boot into recovery, unmount everything
pull the data partition to computer
Code:
[PC] adb pull /dev/block/mmcblk0p23 userdata.img
put gdisk on the phone, and use it to modify the partition table - grow system while retaining its starting sector, shrink userdata by the same amount, and re-create cache between them
Code:
[PC] adb push gdisk /tmp/
[adb-shell] /tmp/gdisk /dev/block/mmcblk0
...
use resize2fs on the phone with the system partition to grow it
use resize2fs on the computer with the userdata partition's image to shrink it to appropriate size
push the modified data image to the phone
Code:
[PC] adb push userdata.img /dev/block/mmcblk0p23
format the cache partition, reboot into system
EDIT: I'm intentionally leaving out the details of what to do with gdisk, as I think using sgdisk's output and a text editor to just change the partition boundaries is the proper way to do this. If you really want and need some hints though:
On the phone, all of the affected partitions started on 8MiB-aligned sectors, and I maintained the alignment after the resize. It also makes specifying the new size to resize2fs straightforward
Partition name in the GPT, and unique GUID should be maintained after resize.

Oh, and regarding LOS-15 installation, the installer will image the system partition with original, 840MiB filesystem, and won't grow it, so subsequent g-apps installation will fail. It's necessary to grow the filesystem manually and then install g-apps.

myxal said:
push the modified data image to the phone
Code:
[PC] adb push userdata.img /dev/block/mmcblk0p23
Click to expand...
Click to collapse
putting aside missing information about how to get and use sgdisk (or gdisk) you're also not saying what modification has to be done to userdata.img and if this modification works with encrypted /data

rotanid said:
putting aside missing information about how to get and use sgdisk (or gdisk) you're also not saying what modification has to be done to userdata.img and if this modification works with encrypted /data
Click to expand...
Click to collapse
The modification referred in point 6 is the shrinking done in point 5. I have no experience with encrypted /data (or knowledge how that is implemented, for that matter), so I don't know what extra steps would be needed in that setup.

myxal said:
The modification referred in point 6 is the shrinking done in point 5. I have no experience with encrypted /data (or knowledge how that is implemented, for that matter), so I don't know what extra steps would be needed in that setup.
Click to expand...
Click to collapse
oh, thanks for the fast reply!
in that case, i think it's not possible to keep the data if it's encrypted, because you can't decrypt it on the PC to be able to shrink it