Database Info

[UTIL] [NEW] switchrom.sh V1.1 - One step bookmark, store and restore your ROMs

Changelog:
1.1 - Allow delete/restore without a name. Choose from the list.
1.0 - Use nandroid to make it one step process.
Currently, nandroid backups do not contain the a2sd app folders. It has been painful to say the least to jump between ROMs.
This script does two things:
1. Store and tag a ROM's nandroid backup and its apps data. You can provide any name for tagging while storing.
2. Restore a tagged ROM's app data and its latest nandroid backup.
The nice side effect of this is that you have complete environments you have created nicely bookmarked with easy to understand names and version numbers, ready to be restored easily.
Requirements:
1. Two partitions in order: fat32, ext2/3
2. cyanogen's recovery image 1.4. 1.3.1 will not work with V1.0.
3. Attached script called switchrom.txt downloaded and stored in folder /system/sd/ and renamed as switchrom.sh
Usage:
1. Boot into recovery using Home + End buttons together.
2. To bookmark and tag current ROM,
Go into console with Alt+X (or do adb shell from PC)
mount /system/sd
sh /system/sd/switchrom.sh -s <name>
e.g.
I am backing up soulife-1.2.3 with
sh /system/sd/switchrom.sh -s soulife-1.2.3
3. To restore a ROM,
Go into console with Alt+X (or do 'adb shell' from PC)
mount /system/sd
sh /system/sd/switchrom.sh -r
It will give you a list of available ROMs to restore and you can choose the one you want to restore using the corresponding number.
e.g.
I am restoring soulife-roger-new-3.9.1-latest with
Code:
sh /system/sd/switchrom.sh -r
1. JACMyTouchSkiV2-mod
2. JACxROM-1.3r3
3. cm-3.9.7-best-setup
4. drizzy-hero-2.8-best
5. soulife-ion-1.2.3-mod
6. soulife-roger-new-3.9.1-latest
Choose a ROM (type in the number and press enter)...6
Restoring ROM soulife-roger-new-3.9.1-latest, proceed? (y/n) y
Cleaning up /system/sd ...
Restoring soulife-roger-new-3.9.1-latest app data in /system/sd ...
Restoring nandroid backup...
Done restoring the ROM soulife-roger-new-3.9.1-latest.
Note that no extra steps are necessary. No wipe! No nandroid restore!
Note that options have changed since last version. Make sure to read the help with '-h' or '--help' option. Compression (-c option) is supported for both the apps partition and the nandroid but the way it is done in nandroid is dumb and takes like 17 minutes, so I would not recommend it at this time but you can definitely try it. I will post patches for nandroid script to fix that.
Code:
# sh /system/sd/switchrom.sh -h
Usage: /system/sd/switchrom.sh OPTIONS <rom_name>
Options are:
-h --help
-c --compress, only used with -s
-d --delete
-l --list
-r --restore
-s --store
-v --version
Always specify options as separate words
e.g. -c -r instead of -cr. Its required!
Don't use blanks or special characetrs in rom_name.
Compress will take longer but image will be smaller.
<rom_name> is optional with -r and -d. Choose from a list.
NOTES:
Note that this is not storing the whole backup of your EXT2/3 partition. This is just storing app* and dalv* folders needed to restore the ROM behavior, apps and settings only. If you wipe your EXT2/3 partition with a formatter or manually with 'rm -rf /system/sd/*', you will loose everything on that partition and won't get it back from this backup. This backup will only restore app* and dalv* folder.
It was reported that certain versions of 'adb' hangs in the sub-shell created and it doesn't pass through the commands that are typed. Make sure to upgrade the SDK to 1.5r3.

Awesome work, I'll try this out on my next rom switch. Can't ever have too many scripts I say.

added to my collection of scripts

This may sound like a silly question but please forgive me as I have not yet flashed the haykuro spl.
Once you've flashed the new spl, instead of flashing the update.zip of the cyanogen rom, can't you use nandroid restore? Or will that restore the previous spl as well (in my case HARD SPL)?
I ask because I would like to try the spl, but I'm so comfortable with my rom and settings that I would hate to wipe just to try Hero which is still in development. Call me crazy, but I like stable and finished builds. But I am curious and with a lot of time on my hands but not so much that I'm willing to lose everything just to try something that I'm not going to keep.
With this script, it would make it so much easier and would allow us to switch roms on the fly... but would it work from Hero builds and non-Hero builds?

I don't think I know enough about the SPL image contents to comment on this. But as far as I know SPL is not touched by nandroid restore. I upgraded the radio and SPL (haykuro) first, and then went with updating my ROM. I will never flash radio and SPL unless and until I really need to.
This script is just taking the pain out of switching between ROMs (whether Hero or Cyano or official) and nicely organizes your ROM backups. So, to answer your question:
would it work from Hero builds and non-Hero builds?
Click to expand...
Click to collapse
Yes. It would! I have switched between drizzy's Hero ROM and JACMyTouchSki (my favorite) many times using this. The restore is perfect!

Binary100100 said:
Once you've flashed the new spl, instead of flashing the update.zip of the cyanogen rom, can't you use nandroid restore? Or will that restore the previous spl as well (in my case HARD SPL)?
Click to expand...
Click to collapse
Considering the most amount of bricks come from radio/spl updates, I dont think this script would integrate backing up and restoring them. Same reason why rom's themselves dont include the latest radio/spl in the update.zip when it is required by the rom.

rondey- said:
Considering the most amount of bricks come from radio/spl updates, I dont think this script would integrate backing up and restoring them. Same reason why rom's themselves dont include the latest radio/spl in the update.zip when it is required by the rom.
Click to expand...
Click to collapse
Okay... so I'm running cyanogen's rom now with hardspl.
I back it up and lable it "Cyan 3.9"
I install the Haykuro spl (I already have the radio)
I install a Hero rom.
I try the Hero rom.
I backup the Hero rom and lable it "Hero"
I can then restore "Cyan 3.9" and still have the Haykuro spl.
Correct?

Binary100100 said:
Okay... so I'm running cyanogen's rom now with hardspl.
I back it up and lable it "Cyan 3.9"
I install the Haykuro spl (I already have the radio)
I install a Hero rom.
I try the Hero rom.
I backup the Hero rom and lable it "Hero"
I can then restore "Cyan 3.9" and still have the Haykuro spl.
Correct?
Click to expand...
Click to collapse
Make sure you use labels which don't have whitespace or other special characters in the name like use Cyan-3.9 instead of "Cyan 3.9". I don't think script likes it much at this time. I need to fix that.

Binary100100 said:
Okay... so I'm running cyanogen's rom now with hardspl.
I back it up and lable it "Cyan 3.9"
I install the Haykuro spl (I already have the radio)
I install a Hero rom.
I try the Hero rom.
I backup the Hero rom and lable it "Hero"
I can then restore "Cyan 3.9" and still have the Haykuro spl.
Correct?
Click to expand...
Click to collapse
The only difference between this and a "typical" nandroid restore should just be that it copies your ext2/3/4 partition for the app data. It wasnt listed anywhere that it would backup/restore your spl/radio.
Prior to flashing the haykuro spl I made a nandroid backup of the cyanogen rom I was using. I tested a hero rom and restored a nandroid backup of the cyanogen rom I was running and the new radio/spl were in place.

I think you need to dump all of mtd6ro and extract radio/spl by hand if you need to. Nandroid doesn't touch either of them.

rondey- said:
Prior to flashing the haykuro spl I made a nandroid backup of the cyanogen rom I was using. I tested a hero rom and restored a nandroid backup of the cyanogen rom I was running and the new radio/spl were in place.
Click to expand...
Click to collapse
Sweet! This was the exact answer that I was hoping and searching for for hours. Thank you very much. I've been getting guesses and theories this whole time and I knew someone out there just had to have personal experience with it. Thank you.

WOW amazing script!! just downloaded and used it
works very well!! can't wait to see what else you can do with it.

the perfect addition to a world that includes xda devs. nice work!

This may a dumb question, but why is it necessary to do this if your app data is still sitting on your ext partition, isnt it going to look for apps there anyway if you have apps2sd setup automatically like in a CM rom?
Cheers

The current version of nandroid lets you switch
Between backups, but not all options are yet connected to the UI.
devsk said:
Currently,
A. nandroid backups do not contain the a2sd app folders.
B. nandroid backups are not tagged but instead are time stamp based, so if you forget you backed up your most stable ROM with all the setup done and apps installed at 11:01pm on Friday, you will have tough time getting it back.
It has been painful to say the least to jump between ROMs.
This script does two things:
1. Store and tag a ROM's nandroid backup and its apps data. You can provide any name for tagging while storing.
2. Restore a tagged ROM's app data and make its nandroid backup the latest so that the recovery console can restore from it.
The nice side effect of this is that you have complete environments you have created nicely bookmarked with easy to understand names and version numbers, ready to be restored easily. Eventually, this should be part of the nandroid in recovery image itself.
Requirements:
cyanogen's recovery image 1.3.1
attached script (only txt extension is allowed) downloaded to /sdcard/switchrom.sh
Usage:
1. Boot into recovery using Home + End buttons together.
2. To bookmark and tag current ROM,
Do a nandroid backup first
Go into console with Alt+X (or do adb shell from PC)
mount /sdcard
sh /sdcard/switchrom.sh store <name>
e.g.
I am backing up soulife-1.2.3 with
sh /sdcard/switchrom.sh store soulife-1.2.3
3. To restore a ROM,
Go into console with Alt+X (or do 'adb shell' from PC)
mount /sdcard
sh /sdcard/switchrom.sh restore <name>
e.g.
I am restoring soulife-1.2.3 with
sh /sdcard/switchrom.sh restore soulife-1.2.3
Go back to recovery screen (by typing 'recovery' on the shell prompt if you are on console)
Alt+w to wipe
Do a nandroid restore from latest backup
I have tested this script with cyanogen 3.9, soulife 1.2.3, drizzy's hero and JACMyTouchSki.
Click to expand...
Click to collapse

I must be missing something...
I would like to say first, I am sure there is something I am missing, but to me it would just seem easier to do this in the terminal:
Make a copy of whatever ROM you want to use and rename it to update.zip. I will use Soulife's Ion for example. Also using the assumption you have an update.zip file on hand. You can use the ls command to see what all ROMs you have on your sdcard.
$ su
# cd /sdcard
# rm -r update.zip
# cp soulife.ion.v.1.2.2.zip /sdcard/update.zip
# reboot recovery
Flash as normal
I usually keep my phone backed up using backup for root users. So I just restore all my text messages and settings from the SD card and that is it.
I guess that is more typing, but to me each individual command it simpler.

mookie3three said:
This may a dumb question, but why is it necessary to do this if your app data is still sitting on your ext partition, isnt it going to look for apps there anyway if you have apps2sd setup automatically like in a CM rom?
Cheers
Click to expand...
Click to collapse
Apps data is not portable between ROMs. You need to clean it up otherwise expect random FCs.

ccunningham83 said:
I would like to say first, I am sure there is something I am missing, but to me it would just seem easier to do this in the terminal:
Make a copy of whatever ROM you want to use and rename it to update.zip. I will use Soulife's Ion for example. Also using the assumption you have an update.zip file on hand. You can use the ls command to see what all ROMs you have on your sdcard.
$ su
# cd /sdcard
# rm -r update.zip
# cp soulife.ion.v.1.2.2.zip /sdcard/update.zip
# reboot recovery
Flash as normal
Click to expand...
Click to collapse
And lose all that you did with your current ROM. I think you did not get the point of this script.... This is for people who have setup their phone well with a ROM and don't want to lose its goodness but still want to test other ROMs and possibly have a couple of them on their phone which they can switch to & from.

ccunningham83 said:
I would like to say first, I am sure there is something I am missing, but to me it would just seem easier to do this in the terminal:
Make a copy of whatever ROM you want to use and rename it to update.zip. I will use Soulife's Ion for example. Also using the assumption you have an update.zip file on hand. You can use the ls command to see what all ROMs you have on your sdcard.
$ su
# cd /sdcard
# rm -r update.zip
# cp soulife.ion.v.1.2.2.zip /sdcard/update.zip
# reboot recovery
Flash as normal
I usually keep my phone backed up using backup for root users. So I just restore all my text messages and settings from the SD card and that is it.
I guess that is more typing, but to me each individual command it simpler.
Click to expand...
Click to collapse
The thing you are missing is that many apps do not have an option to export their settings, nor do they store them in an easily accessible place. Even if you manage to pull their settings off /data/data/ folders, you still have problems with restoring them. First off, you have to worry about their Linux permissions since they don't get preserved on the Fat32 partition. Second, simply pushing back the setting folders won't work for apps that use SQLlite database to store account info, so you're stuck with re-entering everything manually.
Take K9 Mail for example. I have 4 accounts (both IMAP and POP3) that I have to set up every time I wipe my phone or reformat the Ext partition. Same with progress on most games. A tar of the entire Ext partition combined with a Nandroid image resolves most of these issues.

I get an error during backup.
I take a nandroid backup, enter recovery terminal, type in "mount /sdcard" enter "sh /sdcard/switchrom.sh store lastramjet" type in yes at the confirmation prompt and the script starts it's magic.
However, after the "moving nandroid (or something)" I get an error saying "Cannot umount /sdcard device/resource in use/busy". After that I get a successfully bookmarked the backup message.
Not sure if this matters, but just wanted to let you know

[HOW-TO] ROM-HACKING: init.rc ext2-auto-mount / ROM Signing / ROM Kitchen

AS MENTIONED IN THE INTRODUCTION TEXT THIS HAS ONLY BEEN TESTED ON AMON RA ROM 1.6.2 BUT SHOULD REALLY WORK ON ANY ROM THAT HAS NO EXT2 AUTO-MOUNT. AND YEAH THIS WHOLE PROCESS HAS BEEN DONE ON A 32a BOARD. FOR THOSE THAT TRY THIS ON OTHER ROMS LET ME KNOW HOW IT GOES.
I've searched and shuffled through the entire forum and made inquiries to ROM authors without much light being shed on this issue. I doubt I am the only one who has been looking for a way of doing this so I decided to do a small HOW-TO. Here I will explain step by step as to how you can implement a script to be part of your ROM that will auto mount an ext2 partition on boot up if such partition is present. I have included all the tools I've used in order to pull this off, and as the title suggests this has only been done on Amon Ra's latest 1.6.2 ROM. In order to follow these instructions you are expected to allready have set up an adb enviroment on your linux box and for the signing process to work you must have sun-java present, the gnu java wont work. And of course a microSD card with an ext2 partition
1. Download install.sh to your home directory
Code:
wget http://www.grindhouse.no/androidtools/install.sh
chmod a+x install.sh
2. Now execute the install.sh script which will create a directory to work in and download a tool and script package and unpack it.
Code:
./install.sh
When the install.sh script is done you need to move the mkbootimg preferebly to your tools directory of your SDK.
Code:
mv toolstomove/mkbootimg <path/to/sdk/tools/mkbootimg>
3. Unpack the RA1.6.2 ROM into a directory in your home dir. In this HOW-TO we will use directory name "ra1.6.2" as an example through out the entire process.
4. Copy the boot.img from ra1.6.2 to the ROM-cooker dir
Code:
cp $HOME/ra1.6.2/boot.img $HOME/ROM-cooker/boot.img
cd $HOME/ROM-cooker
5. Use unpack.pl to extract the ramdisk from the boot image. I've modified the script a little so it automates the entire process and decompresses the ramdisk to a directory
Code:
./unpack boot.img
6. Now you can either replace the init.rc file here with the one I've included in this package or you can add these lines by yourself. In wich case do the following
Code:
cd boot.img-ramdisk
pico init.rc
Press CTRL+w and then CTRL+t and input 27. hit enter. This will take you to line 27 of init.rc so you can add a line right before the init process remounts the rootfs in read-only mode. Add following line:
Code:
mkdir /sdext2 0771 system system
Now scroll down to the end of the init.rc file and add the following:
Code:
service mountsdext2 /system/bin/mountsd
user root
group root
oneshot
7. You have now edited (or replaced) your init.rc file and prepared it to execute a script on boot that will detect an ext2 partition and boot it if there is one to be found. Now you have to make the mountsd script a part of the ROM. Do the following:
Code:
cd $HOME/ROM-cooker
mv toolstomove/mountsd $HOME/ra1.6.2/system/bin/mountsd
rm -rf toolstomove
8. Now that the init.rc file is sorted out and mountsd has been placed in /system/bin of the ROM so it is time to re-pack the boot.img:
Code:
cd $HOME/ROM-cooker
./repack boot.img-kernel boot.img-ramdisk boot.img
rm $HOME/ra1.6.2/boot.img
mv boot.img $HOME/ra1.6.2/boot.img
9. Your ROM now has a new boot image with an updated init.rc and the /system/bin dir has the script needed to auto-mount the microsd ext2. Now you must re-zip the ROM and sign it. Do the following:
Code:
cd $HOME/ra1.6.2
zip -r update.zip *
mv update.zip $HOME/ROM-cooker/update.zip
cd $HOME/ROM-cooker
./sign.pl update.zip
10. The ROM is now signed and you now have a file called update-signed.zip. Connect the phone to your computer and execute thus:
Code:
./push update-signed.zip
11. Now you are ready to flash the modified ROM which will auto-mount an ext2 partition on your microSD. There is no need to wipe before flashing. If you have no prior experience with ROM flashing or whatever just backup your current install. If you're using OpenHOME or anything similar, nothing will be changed or damaged but if you're using MontAlbert's themes with the ROM you will have to flash them again after flashing this modified ROM.
Code:
adb reboot recovery
12. Flash from choose zip and of course choose update-signed.zip. Reboot. After the system boots up again you can now check whats what with either one of the commands:
Code:
[email protected]:~$ adb shell mount | grep sdext2
/dev/block/mmcblk0p2 on /sdext2 type ext2 (rw,noatime,nodiratime,errors=continue)
[email protected]:~/boot$ adb shell busybox df -h | grep sdext2
/dev/block/mmcblk0p2 893.7M 13.0K 846.0M 0% /sdext2
13. Voila! Your RA 1.6.2 ROM now detects and mounts your microSD ext2 partition on boot. Woohoo?
I hope the HOW-TO was easy reading and that you have succeeded in hacking up your ROM. I know that certain ROMs have this as a built-in function but Amon Ra's does not. But since alot of people including myself use his ROM because of the high speed and stability I thought I should contribute to his project and add a cool (and missed?) function to it.
Mind you that you can use the ROM-cooker set to further adjust and hack up the ROM as you see fit. Happy learning!

Very nice!
Now the question many people will ask : why would you automount ext2 if you don't use apps2sd ?

I personally have ubuntu on my ext2 And besides this approach can be used for a number of things, people who have had the need, or wanted to experiment with init.rc doing things on boot, the mountsd script can easily be altered to do what ever needed.
For me its been a learning curve finding these things out, so by sharing it I may spare some people breaking their backs over this whole init.rc thing. people may want to modify init.rc for whatever reason, so I'm sure people wont have a problem finding a way of putting this to use, and its a subject that isnt all that covered on the forum .. and hey .. at least they get a rom kitchen out of the whole shabang

Very interesting! Thank you.
I used your unpack-program to unpack a recovery-image. It seems to work fine. What I am trying to do is change the state the recovery-image returns the phone to. Would it be possible to just replace your mountsd-script with, for example, a script that installs apps? Or is there a better way to do what Im trying to achieve?
Cheers,
edit: I noticed that on the emulator it is sufficient to just place an apk-file in "data/app" to get it installed. Could it be possible that this is all I need a script to do? :O or could I hurt my poor phone by doing so you think?

sandis84 said:
edit: I noticed that on the emulator it is sufficient to just place an apk-file in "data/app" to get it installed. Could it be possible that this is all I need a script to do? :O or could I hurt my poor phone by doing so you think?
Click to expand...
Click to collapse
That's indeed all you need to do.

Hi!
So I tried to create a signed update.zip, but it failed. It didnt create a "update-script"-file, so my device refused to install it. I wrote my own "update-script"-file, but then it complained "no digest" for the file. How do I solve this?

post the contents of your script people might see whats up

so is this all on linux?
also where are the script files for your tutorial
thanks for the time to put together

sitimber said:
so is this all on linux?
also where are the script files for your tutorial
thanks for the time to put together
Click to expand...
Click to collapse
Says where its at in the first line : )
Code:
wget http://www.grindhouse.no/androidtools/install.sh
But now that I checked, I have to apologize, I see I have a missed payment with my hosting, I'll fix that within the day. Also sorry I havent been answering the few questions here I've been afk cause of surgery.

sitimber said:
post the contents of your script people might see whats up
Click to expand...
Click to collapse
well, I looked in another "update-script" file and found this:
assert compatible_with("0.2") == "true"
assert getprop("ro.product.device") == "dream" || getprop("ro.build.product") == "dream"
show_progress 0.5 0
write_radio_image PACKAGE:radio.img
show_progress 0.5 10
Click to expand...
Click to collapse
So I figured that nothing was essential other then the line "write_radio_image PACKAGE:radio.img". Also ofcourse I made sure it contained the name of my image-file instead of "radio.img". This gave me the "no digest" message, so now I feel unsure on how to create a working update.zip.
edit:
SOLVED! How silly of me. When you sign the update, a hash of each file is put in manifest.mf. Since I added the update-script after signing the file, ofcourse the digest(hash) was missing. Now everything works alot better and I can proceed... until I get stuck again
Cheers,
edit2:
Just to get a better understanding, what exactly does each line do here? Or where can I read about this?
Code:
service mountsdext2 /system/bin/mountsd
user root
group root
oneshot
edit3:
Ok, so I have experimentet, but I still dont manage to solve those last steps. I tried to edit init.rc and just add "mkdir /testdir 0000 system system" where the other directories were created. I then repacked it, zipped it, signed it, put it on my sdcard, started up a custom recovery, installed the update and rebooted. Everything seems to work fine. But when I start adb and check around, I dont see the "testdir"-directory. Also when I check in init.rc my line is gone. Do you guys have an idea of where I went wrong?

sitimber said:
so is this all on linux?
also where are the script files for your tutorial
thanks for the time to put together
Click to expand...
Click to collapse
it doesnot necesarily have to be linux ...you can also do it in windows using cygwin and dsxda's android rom kitchen

[Script] Turn off Apps2SD on CM 4.2+

The script does a one time copy of the apps from /system/sd to /data for mytouch phones (since we don't need a2sd!). After that, a2sd is just disabled
Attachment: Update zip (takes about 20sec lol)
Pastebin: http://pastebin.com/d108b98f8
Rough info:
Cyanogen & Twisted A2SD modded for Hero (by Maxisma)
Remodified for CM 4.2+ by Wes Garner
This finds out if it is running on Magic or G1 and decides if A2SD is used or not
Mounts EXT for Magic and G1

Or you could just delete your ext2 partition...

but then no userinit

Didn't work for me. I have CM 4.2.5, downloaded mt3g-noa2sd-signed.zip and flashed it in recovery. Then when I rebooted I got to the CM bootscreen, after a few seconds the screen went black. I let it load for 45-60 minutes (watching tv) but nothing happened. Tried to flash again and the same thing.
ls -l in /data showed app and app-private was still linked to sd. I removed the links, made the directories and copied over the data from sd. Then it worked.

Kaptur said:
Didn't work for me. I have CM 4.2.5, downloaded mt3g-noa2sd-signed.zip and flashed it in recovery. Then when I rebooted I got to the CM bootscreen, after a few seconds the screen went black. I let it load for 45-60 minutes (watching tv) but nothing happened. Tried to flash again and the same thing.
ls -l in /data showed app and app-private was still linked to sd. I removed the links, made the directories and copied over the data from sd. Then it worked.
Click to expand...
Click to collapse
I'm having the same issue here, after flashing, I get Cyanogen boot screen and then it moves to black and sits there - since there's no way it's taking that long to copy the data, I'm guessing this script is broken as of 4.2.5.

From CyanogenMod Wiki http://wiki.cyanogenmod.com/index.php/Removing_Apps2SD
Removing Apps2SD
From CyanogenMod Wiki
Jump to: navigation, search
You'll probably have to re-install any paid apps (app-private) but normal apps should run fine after this.
For Terminal Emulator
Code:
su
mount -o rw,remount /system
Then proceed to the ADB instructions from after 'adb shell'
ADB Instructions
Code:
adb remount
adb shell
Code:
rm /data/app
mkdir /data/app
cp /system/sd/app/* /data/app/
rm /data/app-private
mkdir /data/app-private
cp -r /system/sd/app-private/* /data/app-private
rm /data/dalvik-cache
mkdir /data/dalvik-cache
reboot recovery
In Recovery Mode console, you will have to delete the ext partition:
Code:
parted /dev/block/mmcblk0
rm 2
quit
Note: If you had a 3rd partition for swap it will now be partition 2. Adjust your userinit.sh accordingly.
After rebooting, you can confirm that it worked by running:
ls -l /system
From Terminal Emulator (no need to remount/su) and you should see 'app' and 'app-private' as directories (and not app -> /system/sd/app).
Click to expand...
Click to collapse

yea oops, forgot to delete old symlinks on it

It doesn´t work for me...
I´m trying to disable A2sd because of my partition layout (Swap+Fat32) on my HTC Magic 32B but nothing happens after applying the update. My phone it just keeps in the bootloop forever....

[DEV][SCRIPT] First-Boot App Install

First-Boot Install System​
I have searched Far and wide for something like this since i first put out SleeperROM in November and always come up empty.
So with the latest release, i decided it was finally time to do it myself.
All you have to do is, using the following package as a template either on its own or in your ROM, make sure your batch folder with the .apk's to install are in /data/.firstboot/
Why
Some apps like QuickPic, ConnectBot, TinyFlashlight, Flash, Google Goggles and others that rely on linked libs don't like to simply be copied to their install dir because many won't install their own libs unless the PackageManager does it and/or they won't add themselves to the packages list (like QuickPic). The old solution is to include the lib either in the /data/data/appdir/lib with the rom install OR in /system/lib but this is quite wasteful especially in the case of big apps like Flash where including the libs separately from the app effectively doubles the space taken up on the rom by that single app since the apk still contains the lib files within.
So the solution is to install on first boot by including the apps in a batch folder for the script to process.
How it works
What it does is run from the init scripts, as one of the last scripts to run, it waits until the Android core system is up (checks to be sure by waiting for the SystemUI process is running then waits for an additional 10 seconds)
Then runs /data/.firstboot.sh, which is where you should put your first boot routines. Included in this script is the batch app installer which looks for the apps in /data/.firstboot/ and stores temporary app backups in /cache/tmp -- so be mindful that on MTD roms, the cache partition is smaller so may have to modify the $tmp variable to wherever you want to store temporaries
After installing, it sleeps for a proportional number of seconds (5 seconds per app installed) to ensure there is no race condition between installs or the final permissions_fix, zipalign and tmp cleanup. The /data/.firstboot.sh script removes itself when everything is complete.
The remaining components are kept in there for additional use by the /etc/init.d/Y02firstboot script in the future, so then all that needs to be put on the phone is a new /data/.firstboot/ dir and replacement /data/.firstboot.sh to run a batch of updates.
The Apps MUST be named by their package name.
I.e. Titanium Backup MUST be named com.keramidas.TitaniumBackup.apk
the file name must correspond with the name of the data dir in /data/data/ the script is lazy in that way, i didn't feel like keeping a file manifest of installs, instead just like to drop in apps to install.
The installer
consists of the following components:
- /system/etc/init.d/Y02firstboot
- /system/xbin/rsync
- /system/xbin/fix_permissions
- /system/xbin/batch_zipalign
- /system/xbin/sleeperlog (echos, logcats, and writes a log of activity to /sdcard/sleeperlog.txt)
- /data/.firstboot.sh
- /data/.firstboot/ (batch app directory)
- NOT INCLUDED, there must be a busybox bin somewhere in $PATH - this is not a problem for most roms
See the package link for a ready to use first-boot installer [CWM] flashable. Just drop your apks into /fs/data/.firstboot/ for a batch app updater
Download the template/usable package
DOWNLOAD MOD_CWM-FirstBoot-20120112.zip
File size: 341.07 KB / MD5 23d88c349b8d2fa3cd2f9958ae99a1f6
​
THE MAIN COMPONENTS:
/system/etc/init.d/Y02firstboot
Code:
#!/system/bin/sh
# execute post-install script on First boot
# 01022012 SENSEISIMPLE
SLEEP=3
FBSCR="/data/.firstboot.sh"
BB="busybox"
pg () {
$BB ps | $BB grep "[email protected]" | $BB grep -v "$( echo $BB grep [email protected] )"
}
if [ -f "$FBSCR" ]; then
#install apps on first boot after system services have started
sleeperlog "Found $FBLOC"
sleeperlog "Waiting for system"
$BB chmod 0755 $FBSCR
while : ; do
if pg systemui; then
$BB sleep 10
sleeperlog "system loaded."
log -p i -t boot "Executing $FBSCR script"
sleeperlog "Running FirstBoot init"
$FBSCR
break
fi
sleeperlog "WAITING FOR SYSTEM SERVICE: sleeping for $SLEEP s..."
$BB sleep $SLEEP
done
fi
/data/.firstboot.sh
Code:
#!/system/bin/sh
#
# 20120107 - SENSEISIMPLE
#
log -p i -t init:firstboot "INIT.firstboot BEGIN: USER SCRIPT $FBLOC.sh"
sleeperlog "FirstBoot Script OK TO RUN"
FBLOC="/data/.firstboot"
tmp="/cache/tmp/firstboot"
bak="$tmp/bak/data/data/"
BB="busybox"
RM="$BB rm"
CP="$BB cp"
MV="$BB mv"
MKDIR="$BB mkdir"
LS="$BB ls"
CHMOD="$BB chmod"
SLEEP="$BB sleep"
GREP="$BB grep"
pg () {
$BB ps | $BB grep "[email protected]" | $BB grep -v "$( echo $BB grep [email protected] )"
}
$CHMOD 0777 /data
#install apps on first boot
if [ -d $FBLOC ]; then
sleeperlog "Found $FBLOC"
if [ "$($LS $FBLOC)" ]; then
cd $FBLOC
$MKDIR -p $bak
for pkg in *.apk; do
log -p i -t init:firstboot "INIT.firstboot INSTALLING: $pkg"
sleeperlog "PREPARING: $pkg"
pkgname=${pkg%.*}
sleeperlog "BACKING UP APP DATA - $pkgname"
#back up data, delete the original data dir to prevent install errors (pm isn't very good at what it does)
if [ -d /data/data/$pkgname ]; then
$CP -a /data/data/$pkgname $bak/$pkgname
$RM -rf /data/data/$pkgname
fi
#WAIT, then install, then WAIT SOME MORE
$SLEEP 2
sleeperlog "INSTALLING $pkgname"
pm install -r $FBLOC/$pkg &
$SLEEP 10
#REIntegrate application data
if [ -d "$bak/$pkgname" ]; then
sleeperlog "\nSYNCING APP DATA \n\n$(/system/xbin/rsync -auv --exclude=lib $bak/$pkgname/ /data/data/$pkgname/)\n"
fi
i=$((i+1))
#Move the install .apk to tmp
if $LS /data/app | $GREP "$pkgname"; then
sleeperlog "Package appears to have installed."
$MV "$pkg" $tmp/
fi
#If the firstboot batch dir is empty, delete it now
! [ "$($LS $FBLOC)" ] && $RM -rf $FBLOC
done
#WAIT for [#ofapps x 5 seconds each] to avoid a race condition
waitsecs=$(( i * 5 ))
sleeperlog "Waiting for ${waitsecs}s before Fixing Permissions"
$SLEEP $waitsecs
sleeperlog "Fixing Permissions $(/system/xbin/fix_permissions)"
sleeperlog "Running batch zipalign \n\n $(/system/xbin/zipalign)"
sleeperlog "Clearing tmp $tmp"
fi
fi
sleeperlog "FIRSTBOOT SCRIPT COMPLETE"
log -p i -t init:firstboot "INIT.firstboot SELF DESTRUCT FIRSTBOOTSCRIPT"
if ! [ "$($LS $FBLOC)" ]; then
$MV $0 $tmp/.firstboot
# COMMENT THIS OUT FOR DEBUGGING, TO NOT REMOVE THE TMP DIR
$RM -r $tmp
echo ""
fi
echo -e "#\n#COMPLETED ON $(date)\n#" >> $0
sleeperlog "FirstBoot Apoptosis"
log -p i -t init:firstboot "INIT.firstboot END: USER SCRIPT $FBLOC.sh"
THANKS
CyanogenMod team for the Fix_permissions script
DarkyROM for the Batch Zipalign script

Saving this seat . . .

does this work with a bml rom?

^^^^In theory, it would work with an NTFS rom, if one existed - different filesystems don't [usually] create any changes on the surface... if you try to copy a file from a partition of any file system to a partition of any other file system, you don't have to explicitly tell the system the fs types involved. I haven't looked through the entire script, but if there are any commands that must specify the partition type, it would be a simple matter of changing any occurances of EXT4 to YAFFS2, etc.
This could be a great way to make a clean reinstall with all of your apps intact (minus app data, do a separate backup with your backup app of choice) - first, backup your installed apps by copying them to the appropriate directory, then do a full wipe and install, with the script automatically reinstalling your apps on first boot...
EDIT: I just looked through the script more closely. First, it appears that data is backed up. Second, I can confirm that the standard, non-file system-specific linux commands are used for file operations (cp to copy, etc), so this script shouldn't need any adjustment to accomodate different file systems
Sent from my SPH-D700 using XDA App

Is it possible for someone to develop an application to backup your personal apps and then running a script in clockwork or on first boot that does the same thing as this, alllowing for personal apps to be in the rom directly after flashing. I understand that sometimes apps may not be compatible, but can randomroms rdu script be modified to choose to do this?
Sent From My Cyan4g

Good looking script SenseiSimple!!

Okay, I'm trying to use this script, but you said to put the apps in fs/data/firstboot/ but where is "fs"? I found the "firstboot.sh" file, but I'm sure I can't put the apk's in there...
In loving memory of my son "Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 :'(

sniperkill said:
Okay, I'm trying to use this script, but you said to put the apps in fs/data/firstboot/ but where is "fs"? I found the "firstboot.sh" file, but I'm sure I can't put the apk's in there...
In loving memory of my son "Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 :'(
Click to expand...
Click to collapse
If you look at the folder structure inside the SleeperROM zip, you'll see he uses an fs directory to hold his system and data folders for installation. If you're developing a ROM, you can adapt the script to point to wherever your data folder is (most other ROMs just have system and data in the root directory of the zip, so the path would just be data/firstboot/).
EDIT: no need to look in SleeperROM zip, the firstboot zip in the OP has the same folder structure. It just doesn't seem to have the firstboot directory inside data. You'll need to add that.
Sent from my SPH-D700 using XDA App

bbelos said:
If you look at the folder structure inside the SleeperROM zip, you'll see he uses an fs directory to hold his system and data folders for installation. If you're developing a ROM, you can adapt the script to point to wherever your data folder is (most other ROMs just have system and data in the root directory of the zip, so the path would just be data/firstboot/).
EDIT: no need to look in SleeperROM zip, the firstboot zip in the OP has the same folder structure. It just doesn't seem to have the firstboot directory inside data. You'll need to add that.
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Thanks for the reply buddy, so what I THINK your saying is to create a folder called "first boot" in my data folder?
In loving memory of my son" Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 - RIP :'(

sniperkill said:
Thanks for the reply buddy, so what I THINK your saying is to create a folder called "first boot" in my data folder?
In loving memory of my son" Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 - RIP :'(
Click to expand...
Click to collapse
Are you trying to do this in a ROM or on the phone? Sorry if that's a dumb question, but I just want to be sure we're on the same page.
Sent from my SPH-D700 using XDA App

sniperkill said:
Thanks for the reply buddy, so what I THINK your saying is to create a folder called "first boot" in my data folder?
In loving memory of my son" Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 - RIP :'(
Click to expand...
Click to collapse
bbelos said:
Are you trying to do this in a ROM or on the phone? Sorry if that's a dumb question, but I just want to be sure we're on the same page.
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
i hadn't noticed my zip routine apparently skips empty .folders
in the zip, there SHOULD have been /fs/data/.firstboot into which you place whatever apk files named according to their actual package name i.e. com.keramidas.TitaniumBackup.apk for Titanium Backup, com.alensw.PicFolder.apk for QuickPic and so on...
you can find out this info in Titanium Backup by finding the app in the list and tapping its name to show the data store location.
it HAS to correspond to the actual package name in order to properly back up the data files because the package manager binary as run from a script won't overwrite the data dir so the old data has to be synced back into the new install (rsync)
I am currently refactoring the script to reduce the number of dependencies... the system will then consist of the init.d script, zipalign and rsync bins, and the /data/.firstboot.sh, /data/.firstboot dir all in one place rather than scattered throughout the system.

irule9000 said:
Is it possible for someone to develop an application to backup your personal apps and then running a script in clockwork or on first boot that does the same thing as this, alllowing for personal apps to be in the rom directly after flashing. I understand that sometimes apps may not be compatible, but can randomroms rdu script be modified to choose to do this?
Sent From My Cyan4g
Click to expand...
Click to collapse
it would be possible to create an app to do this, and i considered it because of the need to make sure the android system is fully loaded for package manager to work, but given the requirement for full root access to start running before the system is up without having to worry about android permissions or getting SuperUser approval it's easier/more effective to do it as part of the system init in a script.
as far as randomking's rdu script, they would be compatible, but they exist separately as in one shouldn't interfere with the other, because the firstboot script runs long after install once the system is up and running.
you could modify the rdu setup to include/exclude the /data/.firstboot dir and .firstboot.sh script based on the selected config, since the init script does nothing if it doesn't see the /data/.firstboot.sh file, and the .firstboot.sh script does nothing if it doesn't see the .firstboot dir

SenseiSimple said:
it would be possible to create an app to do this, and i considered it because of the need to make sure the android system is fully loaded for package manager to work, but given the requirement for full root access to start running before the system is up without having to worry about android permissions or getting SuperUser approval it's easier/more effective to do it as part of the system init in a script.
as far as randomking's rdu script, they would be compatible, but they exist separately as in one shouldn't interfere with the other, because the firstboot script runs long after install once the system is up and running.
you could modify the rdu setup to include/exclude the /data/.firstboot dir and .firstboot.sh script based on the selected config, since the init script does nothing if it doesn't see the /data/.firstboot.sh file, and the .firstboot.sh script does nothing if it doesn't see the .firstboot dir
Click to expand...
Click to collapse
Expanding on the rdu script idea, how about a prop variable in the config to specify a user apps directory on the sdcard (best if standardized)? The user can store the apks to be installed after a clean flash in this directory. The rdu script would be modified to copy those apks to the firstboot directory. Although how to handle data? Maybe another script to be run before flashing that checks the apks in the sdcard folder, and copies the current data folder to the sdcard. This data is then restored somehow with the firstboot script. This all can be in addition to the firstboot apps included with the rom.
Sent from my SPH-D700 using XDA App

app
I honestly have no developing experience. To clarify, I was I simply asking if the app could back up the users personal apps/data to the specified folders, to make this script fool proof. Then when a rom is flashed the randomromkings rdu script which currently decides on lite roms or full roms could be modified to either install apps or not install apps depending on the rom compatibility. Finally data is wiped, rom flashes, and your script runs on boot allowing the apps to all be there. Expanding on that if the ROM allows apps to be re installed via your script, through the modified rdu, your script could be moved from one directory to another allowing the process to happen and at the end moves itself back to the original directory. This means that the end user who has no clue how to do anything but flash roms (like myself, but I want to learn) has done nothing accept backing up their apps. I know this is all hypothetical, but would this be possible, and also I have another idea that is probably impossible. If a script could be written so that the apps are backed up when the rom flashes, then the rom automatically does a factory restore and wipes the various caches, meaning that less people are going to have force close issues or other avoidable bugs because they didnt wipe. thanks for all your hard work

Clear Me Here !!
You said that the script (.firstboot.sh) removes itself, but does it remove Y02firstboot script from init.d?? I don't think so, also, there are no disadvantages of this after first boot, as it won't find .firsboot.sh and skip the operation, but why shud it execute unneccesarily everytime??
@OP--Plz. tell me if i am right or wrong.......If right, plz. add a function to remove that script from init.d. However files in /xbin are OK though, so no need to remove them............

Everybody is writing and making this appear as complicated as possible! So let me clarify what I believe the idea is here. First of all, the 'RDU script' I assume you're referring to is simply a flash-able zip to set you phone for a lite or full installation. It sets a config file. I use it in my rom, and I also currently use that config file to set several other features upon installation, and changeable at anytime one of my themes is flashed.
RDU was simply meant to jump start the idea of developers making installations more uniform. Which has happened to various extents, for example, I've used this first-boot install to solve my quickpic(I love the app) and flash pre-install problems. It also fixes usb tether, vlingo, terminal, etc.
SO, what are we saying here? We'd like to be able to backup our apps to the sd card, as many apps can do for us. Then, we'd like to either:
A. Build a script into a rom to restore these apps prior to or upon installation.
or
B. Build a separate script which would be run AFTER a rom installation to restore these apps from CWM.
Yes?
P.S. I see this is very late to the game, didn't realize this thread was being revived...
Still. Neat idea, sorry I hadn't noticed it yet.

+1 Thanks
After integrating this into my custom ROM, my phone (Galaxy S 4G) would only install the first .apk file in the .firstboot directory. After I removed the code which tells it to backup/restore the /data/data directories, it worked fine. I won't need that code since the ROM does a full wipe of /data every time anyway, but I'm not sure why it doesnt work when it's there. I'm not well versed enough with Java's syntax yet to comprehend why.
Also, your first post says that it should record logs to \sdcard\sleeperlog.txt but the script tries to record it to \sdcard\sleeperromlog.txt and neither one of those files actually appear on the sd card.
Edit: I had to remove the check to make sure the .firstboot directory is empty before deleting it, but it works fine on my Galaxy S 4G ROM as long as there are no /data/data directories for the programs I am installing.

does anyone still have a template of this? The link is down.
Edit: nevermind I don't need it anymore.

Android 12 and Nandroid Backup.... ???

Using a Xiaomi Mi11 (rooted). Recently upgraded to MIUI 13 which is based on Android 12. Was going to do my usual TWRP backup before bringing the phone in to fix some minor problems with sticky volume keys, when I realized (!) my TWRP cannot even mount the /data partition, let alone decrypting and doing any backup.
So I started reading up on TWRP developments, and realized TWRP for now has lost its ability to see anything under /data if your phone is on Android 12.
Never a fan of things like Titanium backup where the backup is done on an app-by-app basis, so a lot of of settings like magisk modules / phone behavior, etc etc cannot be retained (at least that was my impression of it when I briefly tried those solutions). So when I decided to bring my phone in for repair anyway, I went ahead and wiped the phone clean, and had to live with losing 10 day's worth of my data - 10 days because fortunately I did a backup just before I upgraded from MIUI 12 to MIUI 13 10 days ago... (yeah could have done a lot of manual work to salvage some of the data before I wiped it clean, but I didn't bother with the tedious processes).
So I now have a fixed phone, no more sticky buttons, and restored my nandroid backup with the older MIUI 12 system (android 11 based), and not even considering moving back to MIUI 13 until there is a feasible way to do a TOTAL backup of the /data partition, in others words a nandroid backup on Android 12....
Question - is there any feasible method of doing a Nandroid Backup on an Android 12 system, with or without TWRP?
Thank you !!!

A NANDroid-backup is the bitwise 1:1 copy of existing Android system.
If phone's Anndroid OS is rooted then you always can launch a NANDroid-backup.
This can get achieved by pure ADB commands what of course requires ADB is enabled on phone.

xXx yYy said:
A NANDroid-backup is the bitwise 1:1 copy of existing Android system.
If phone's Anndroid OS is rooted then you always can launch a NANDroid-backup.
This can get achieved by pure ADB commands what of course requires ADB is enabled on phone.
Click to expand...
Click to collapse
Could you elaborate?
I can picture this issue -
if you do "adb shell" to enter terminal (or plain adb pull?) while your phone is switched on, a lot of files are being locked and/or being modified while the phone OS is running so how can someone just take a snapshot of everything under /data even with proper adb commands?
And if you go to recovery mode first, well at the present time no TWRP can access the data partition it seems. So again even with the appropriate adb commands, no copying is possible....?
Any clarification appreciated !

You would run
Code:
adb wait-for-device
adb root & adb shell "stop"
adb shell "mount -o rw,remount /data"
: run the backup command here
adb shell "start" & adb unroot

xXx yYy said:
You would run
Code:
adb wait-for-device
adb root & adb shell "stop"
adb shell "mount -o rw,remount /data"
: run the backup command here
adb shell "start" & adb unroot
Click to expand...
Click to collapse
Dear Android export @xXx yYy - wow ! This looks really promising !!
I just did a quick test by going straight to adb shell, "su", then "stop". My phone screen totally went blank, and I was amazed ! This is awesome !!! "start" and after a while the phone boots up again.
I then tried "top" while the phone is stopped. It seems to still have a few android related processes running, so I am not 100% sure if the whole system has been frozen. But you obviously know what you are talking about, and I have faith in you.
(by the way, I cannot "adb root", seems like after doing a quick search I will need to make my phone think it is a development build by patching the adbd daemon first on my phone.. suggestions on what to do appreciated)
You have just made me decide to spend the coming hours to test the following. Let me know if I should skip any of the steps below because you know it works so I don't need to waste time to validate:
1. Do a proper backup with TWRP first in case I screw up anything
2. start a terminal session with adb shell
3. "su", "stop"
4. "cd /data"
5. "tar -cvpzf /data/backup.tar.gz -C /data"
(If no error, this should be my nandroid backup...?)
6. flash phone and wipe everything clean, so it is back to brand new status, non-rooted
7. reboot phone, see if it is starting new as if I have just bought the phone
8. root the phone, then try and "stop", "delete everything under /data except /data/media", "delete everything under /data/media", "copy backup.tar.gz back to /data", "tar -xvzf /data/backup.tar.gz -C /"
9. If phone works and is back to the state immediately before backup, then restore successful

Take note that
Code:
adb root
is giving root access to adb ( adbd - read: adb daemon )
what has nothing to do with giving root access to current Android user with following shell command
Code:
adb shell "su"
Also take note that Android services aren't located in /data partition, the partition you want to back up.

With @xXx yYy 's help I think I am getting somewhere.
So essentially a "stop" command in android will stop Zygote (i.e. the mother of all app processes if I am not mistaken). Once you have stopped Zygote, I believe you are then free to make a duplicate of the entire /data environment.
So far that's exactly what I have done. Created a tar.gz file with a size of around 40GB. I believe I am halfway there in my quest to do Nandroid without TWRP, but what I still need to try is to restore the tar file after factory resetting the phone. Will be a time consuming process (as obviously I will also need to have a tried-and-true real backup created first in case I screw something up... I am doing everything on my main phone that I actually use everyday), so I will continue my experiment in the coming days.
One question I have already encountered however - I still cannot do "adb root", which would have allowed me to directly create the backup tar file AND pipe it to my PC all in one go. So far I have had to tar all within the phone, which means space will be a constraint, and it is more time consuming creating the backup file THEN think of a way to transfer that file out of the phone. Already posted a question here asking for help, and if anyone knows of a good way to get adbd to grant adb root request, please let me know.
Above all else, once I have a working method, and I have polished the process, I will be happy to share. I suspect many others are also yearning for a good backup / restore procedure on Android 12.

one can't backup /data partition this way, because tar is just a toybox applet not cabable of preserving secontext. get a gnu tar binary (for example from opengapps installer), set mount namespaces to global, set selinux permissive (if kernel allows it, important) and run from su
/storage/1234-5678 is exFAT and has enough free disk space
Code:
tar --selinux --xattrs --numeric-owner -vcpPf /storage/1234-5678/data.tar /data
/storage/1234-5678 is vfat or less free disk space
Code:
tar --selinux --xattrs --numeric-owner -vcpP /data | gzip | split -a 1 -b 1024m - /storage/1234-5678/data.tar.gz.
another approach would be loop mount some file and busybox cp -avc everything where the -c flag is responsible for secontext (proper busybox required)
--numeric-owner flag is recommended if you are planning to extract it on linux PC later
you could also exec-out straight to PC if no MicroSD Card available, but requires gzip or other compressed stream, otherwise windows will mess up linefeed with carriage return and render your file unreadable
Code:
adb exec-out "su -c 'tar --selinux --xattrs --numeric-owner -vcpP /data | gzip'" > data.tar.gz
restoring .tar.gz from TWRP is absolutely possible, it's just that TWRP can't handle encrypted userdata partition (yet)
Code:
cat /external_sd/data.tar.gz.* | gzip -d | tar --selinux --xattrs -vxpPC /
(where tar must called with full path to binary like /cache/tar or /tmp/tar, or unlink /sbin/tar applet and place binary /sbin, or just rename it gtar)
Note: bitwise 1:1 copy of apps is not possible/sufficient if you factory reset your device, because apps might save data in TEE TrustZone (which is flushed on factory reset)

Hi @seemebreakthis, very interesting discussion on Android 12 backup!
Did you reach a workable solution with this?
Since we can restore most apps from a Google backup, it seems the real issue is to recover the user settings etc. after the Google restore.

Interested in this. Any success thus far?

aIecxs said:
one can't backup /data partition this way, because tar is just a toybox applet not cabable of preserving secontext. get a gnu tar binary (for example from opengapps installer), set mount namespaces to global, set selinux permissive (if kernel allows it, important) and run from su
/storage/1234-5678 is exFAT and has enough free disk space
Code:
tar --selinux --xattrs --numeric-owner -vcpPf /storage/1234-5678/data.tar /data
/storage/1234-5678 is vfat or less free disk space
Code:
tar --selinux --xattrs --numeric-owner -vcpP /data | gzip | split -a 1 -b 1024m - /storage/1234-5678/data.tar.gz.
another approach would be loop mount some file and busybox cp -avc everything where the -c flag is responsible for secontext (proper busybox required)
--numeric-owner flag is recommended if you are planning to extract it on linux PC later
you could also exec-out straight to PC if no MicroSD Card available, but requires gzip or other compressed stream, otherwise windows will mess up linefeed with carriage return and render your file unreadable
Code:
adb exec-out "su -c 'tar --selinux --xattrs --numeric-owner -vcpP /data | gzip'" > data.tar.gz
restoring .tar.gz from TWRP is absolutely possible, it's just that TWRP can't handle encrypted userdata partition (yet)
Code:
cat /external_sd/data.tar.gz.* | gzip -d | tar --selinux --xattrs -vxpPC /
(where tar must called with full path to binary like /cache/tar or /tmp/tar, or unlink /sbin/tar applet and place binary /sbin, or just rename it gtar)
Note: bitwise 1:1 copy of apps is not possible/sufficient if you factory reset your device, because apps might save data in TEE TrustZone (which is flushed on factory reset)
Click to expand...
Click to collapse
You are a genius! That's excactly what i was searching for! Thank you!

This is a bit beyond me.. though I'm looking for a full ROM backup on Android 12. Does this work?

TWRP 3.7.0 is for Android 12 including Encryption Support (except for Samsung)