Develop Bugs

[Q] How to repartition KindleFire

So I got to the part where know I know my partitions are off. Heres what I get with the print command in parted:
Code:
/dev/block/platform/mmci-omap-hs.1 # parted /dev/block/mmcblk0
parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
print
print
Model: MMC M8G2FA (sd/mmc)
Disk /dev/block/mmcblk0: 7734MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Number Start End Size File system Flags
1 0.00B 7734MB 7734MB ext2
I have the mmcblk0p1.img, mmcblk0p2.img, ect... on my computer. How would one use these to restore the partitions so I can install twrp and install stock os?

Messing with the partition table is one slip away from brickage...
Sent from my SAMSUNG-SGH-I777 using xda premium

Well, I am bricked.

I just said screw it and got a new one free from bestbuy.

http://forum.xda-developers.com/showthread.php?t=1388996
a good reading on cold night. also factory cable is not a bad thing

danij3l said:
http://forum.xda-developers.com/showthread.php?t=1388996
a good reading on cold night. also factory cable is not a bad thing
Click to expand...
Click to collapse
The partition tables got nuked while being stuck in fastboot mode, so a factory cable isn't gonna help anything. Repartitioning when there aren't any partition tables built can't help either.

Hoping to rev FIREFIREFIRE sometime this weekend with a partition table initializer. This plus the USB boot should give people a way out. It's already in there but I don't think the partition map is right. Maybe I could add an extra command for alternate partitioning so we don't run into this problem...

pokey9000 said:
Hoping to rev FIREFIREFIRE sometime this weekend with a partition table initializer. This plus the USB boot should give people a way out. It's already in there but I don't think the partition map is right. Maybe I could add an extra command for alternate partitioning so we don't run into this problem...
Click to expand...
Click to collapse
How would we install a new version of FFF if we don't have any partitions?

You don't. If the partition table is broken, then likely the CPU will default to USB boot, where you can use Rekindle to run FFF.

pokey9000 said:
You don't. If the partition table is broken, then likely the CPU will default to USB boot, where you can use Rekindle to run FFF.
Click to expand...
Click to collapse
Ah. I see what you mean. I'm sending mine back tomorrow anyway, so this will definitely help people who get nuked partition tables from booting unstable-ish kernels.

And FFF can now restore your partition table. Custom partitions is still TBD.
Get it here.

It's best to set "unit mib" in parted!
Thanks to to all for this useful thread. But I have an additional suggestion:
When starting parted and before issuing a 'print' command, one should issue the command:
Code:
unit MiB
which causes parted to print sizes and boundaries in binary megabytes, i.e., 1MiB = 1024KiB, where 1KiB = 1024 bytes, which is the numbering system still used for RAM chips, but not much else, since marketers prefer the numbering system that makes their product appear bigger. That way, the numbers given by parted are exact and non-overlapping. When numbers are entered in conformity with this presentation, they should be written with the suffix MiB, without any space after the number. Please keep in mind that, in this format, the end of one partition is the 1MiB block before the start of the next one. When the default decimal format is used, the end of one partition will be the in the same 1MB block as the start of the next partition, which hides the actual point of division, which could be anywhere in that 1MB block, depending on where an actual binary boundary falls.
Also note that each block is specified by its offset (in MB or MiB) from the beginning of some larger space, probably /dev/block/mmcblk0. It would make more sense to specify the end of a partition as the offset in MiB to the first byte following the partition, as most disk management programs do. I don't know why parted does it differently.

[Q] Flash baseband Without Odin?

Hello guys, I'm back.
And as I said in title, does anyone here have an alternative to flash a baseband without Odin?
Regards, Kreaz.

http://forum.xda-developers.com/showthread.php?t=2098679
Here You are. You can flash in CWM.
Sent from my GT-I8150 using xda premium

skrillex13 said:
http://forum.xda-developers.com/showthread.php?t=2098679
Here You are. You can flash in CWM.
Sent from my GT-I8150 using xda premium
Click to expand...
Click to collapse
Tested? Because in the thread itself OP stated that they are flashable via Odin.

Oh sorry my bad. I rembered wrong. I thought that you can flash it via CWM Sorry again.

i believe you can issue dd command to /dev/block/mmcblk0p6 for the baseband
in flashable zip of kernel i used, it issue command to extract the amss.mbn to /dev/block/mmcblk0p6

hadidjapri said:
i believe you can issue dd command to /dev/block/mmcblk0p6 for the baseband
in flashable zip of kernel i used, it issue command to extract the amss.mbn to /dev/block/mmcblk0p6
Click to expand...
Click to collapse
So we'll use the dd if="/path/to/amss.mbn" of="/dev/block/mmcblk0p6" then?
Will try it later, thanks!

Kreaz said:
So we'll use the dd if="/path/to/amss.mbn" of="/dev/block/mmcblk0p6" then?
Will try it later, thanks!
Click to expand...
Click to collapse
Don't forget to backup the partition first.
Code:
su
bbpart="/dev/block/mmcblk0p6"
blksz=$((128*1024))
dd if=$bbpart of=/mnt/sdcard/orig-baseband.img bs=$blksz
dd if=/path/to/amss.mbn of=$bbpart bs=$blksz
As you can see, I specified a block size of 128 KiB, because many flash memory are 'zoned' into 128-KiB blocks.
By matching the bs= of the dd command with the blocksize of the flash memory, the process becomes faster and also less stressing to your flash memory: instead of cycling through "read-modify-write" process 8192 times per block, it can use a single "direct-overwrite" for each block.
And here's an empirical proof of the importance of matching bs= with blocksize: http://kim.oyhus.no/FlashBlockSize.html
(In the latter article, the writer's flash memory apparently had 8 KiB blocks instead of 128 KiB, but that's allright; as you can see, specifying higher bs= does not result in slowdown).

pepoluan said:
Don't forget to backup the partition first.
Code:
su
bbpart="/dev/block/mmcblk0p6"
blksz=$((128*1024))
dd if=$bbpart of=/mnt/sdcard/orig-baseband.img bs=$blksz
dd if=/path/to/amss.mbn of=$bbpart bs=$blksz
As you can see, I specified a block size of 128 KiB, because many flash memory are 'zoned' into 128-KiB blocks.
By matching the bs= of the dd command with the blocksize of the flash memory, the process becomes faster and also less stressing to your flash memory: instead of cycling through "read-modify-write" process 8192 times per block, it can use a single "direct-overwrite" for each block.
And here's an empirical proof of the importance of matching bs= with blocksize: http://kim.oyhus.no/FlashBlockSize.html
(In the latter article, the writer's flash memory apparently had 8 KiB blocks instead of 128 KiB, but that's allright; as you can see, specifying higher bs= does not result in slowdown).
Click to expand...
Click to collapse
Thanks for the backup assist.
Suprisingly, I found 2 files in my downloaded zip. amss.mbn and adsp.mbn
I've pushed (and backed up the original one) the amss.mbn to mmcblk0p6,
But where in the /dev/block/ should adsp.mbn be pushed?

Kreaz said:
Thanks for the backup assist.
Suprisingly, I found 2 files in my downloaded zip. amss.mbn and adsp.mbn
I've pushed (and backed up the original one) the amss.mbn to mmcblk0p6,
But where in the /dev/block/ should adsp.mbn be pushed?
Click to expand...
Click to collapse
according to here adsp.mbn should go to mmcblk0p9

After some thinking, I had to ask the question:
Is it safe, if even possible, to flash baseband via Terminal, while the baseband is being used?
I still think that the best way to flash baseband is via CWM...
-- Sent from a GT-I8150 running ICS perfectly well. F'U, Sams#!t --

pepoluan said:
After some thinking, I had to ask the question:
Is it safe, if even possible, to flash baseband via Terminal, while the baseband is being used?
I still think that the best way to flash baseband is via CWM...
-- Sent from a GT-I8150 running ICS perfectly well. F'U, Sams#!t --
Click to expand...
Click to collapse
Yeah, I was just thinking the same thing, the baseband is already being used, replacing it "shouldn't" be safe. Then again who am I to talk, I didn't believe in inventing a time machine but look at me now
Sent From The Future Using My Rocking Wonder Running Android 5.0

BTW, here's a whole gaggle of CWM-flashable basebands :
http://forum.xda-developers.com/showthread.php?p=36690782
-- Sent from a GT-I8150 running ICS perfectly well. F'U, Sams#!t --

Alcatel 960C/ One Touch Authority

Has anyone created a clockworkmod for this? This phone can be rooted, thru two apps, poot, and ministro(Qt). It still has gingerbread 2.3.6, and I need clockworkmod, or the source code, to use clockworkmod's builder. It is the cdma variant of the alcatel 995(which is gsm). can anyone point me in the right direction?

Source Code
I have it rooted, with adb insecure running, to see everything. My bootloader seems to be locked, and the recovery is unknown, with limited options. I can do most things, except change roms, wipe data, or cache in recovery. I would like to be directed to good repository.

reggjoo said:
I have it rooted, with adb insecure running, to see everything. My bootloader seems to be locked, and the recovery is unknown, with limited options. I can do most things, except change roms, wipe data, or cache in recovery. I would like to be directed to good repository.
Click to expand...
Click to collapse
how did you get it rooted?

rooting alcatel authority (960c)
squidbutt said:
how did you get it rooted?
Click to expand...
Click to collapse
First make sure you have USB Debugging checked and your allowing instalation of unknown sources
DL these from the play store:
Minstro2
Superuser
DL poot.apk: View attachment poot.zip
Run poot, click yes to download the extra librarys, click "click here to poot" you will need to restart the phone when it prompts. You should be rooted now :good:
You can DL ES File Explorer(from play store) and in the settings check: Root Explorer, Up to Root and Mount File System. Now you can manage all the files on your phone but be careful of what you delete, some of the stock apk's are very hard to recover if you delete them.
Hope this helps

Download superuser first
Download superuser first, you won't be able to run it until the phone's rooted. after it's rooted, it will work. This way, seems to stop a problem, when you go thru the steps to root. Some people had a error. If you plan to open the /data, /system, or dalvik cache, on your computer, install chainfire's adb insecure. These folders don't open without this, on a computer.

I have the kernel source here, they have it released on SourceForge I'm guessing you're right saying the bootloader is locked.
Here's some information I've found on the partitions:
mmcblk0 Internal Memory
mmcblk0p1 Mounted using VFAT Contains files pertaining to FOTA (FOTA partition?)
mmcblk0p2 500 blocks ?
mmcblk0p3 1500 blocks ?
mmcblk0p4 1 BLOCK ?
mmcblk0p5 1000 blocks ?
mmcblk0p6 2000 blocks ?
mmcblk0p7 3072 blocks ?
mmcblk0p8 5120 blocks Possible Recovery*
mmcblk0p9 7000 blocks ?
mmcblk0p10 3027 blocks ?
mmcblk0p11 3072 blocks ?
mmcblk0p12 5120 blocks ?
mmcblk0p13 1500 blocks ?
mmcblk0p14 8192 blocks Mounts to /persist
mmcblk0p15 5120 blocks?
mmcblk0p16 1024 blocks?
mmcblk0p17 409600 blocks, Mounts to /system
mmcblk0p18 307200 blocks, Mounts to /cache
mmcblk0p19 892928 blocks, Mounts to /data
mmcblk0p20 122880 blocks, partition appears empty with a sting at the bottom of it reading ANDROID-BOOT!
mmcblk1 SD Card
mmcblk1p1 SD Card Partition
build.prop (Alltel phone):
build.prop
Source Code:
SourceForge Download Link
* In a recent patch I have found, the following code was in the install-recovery.sh file:
Code:
#!/system/bin/sh
if ! applypatch -c EMMC:/dev/block/mmcblk0p15:2048:afbffa74556cd8e77ef7e1a9d0964d9a2bd446b8; then
log -t recovery "Installing new recovery image"
applypatch EMMC:/dev/block/mmcblk0p8:4055040:9411e1fd06dfb3d8da4d1924162caf9e292ea652 EMMC:/dev/block/mmcblk0p15 20270fc8f6c8fca7dae0af5ce0928b589bd6b405 4296704 9411e1fd06dfb3d8da4d1924162caf9e292ea652:/system/recovery-from-boot.p
else
log -t recovery "Recovery image already installed"
fi
Any other information needed?
I'll look into getting a recovery working, but this is by no means a promise.
EDIT:
Something interesting:
The build.prop says the phone has a MSM7630_SURF board, and the Huawei U8800 has the same board, but not quite the same specs:
960C:
480x800
Multitouch
1400 Mhz CPU Sapdragon
512 MB RAM / 2048 MB ROM
Micro SD, 32 GB
3G
U8800:
480x800
Multitouch
800 Mhz CPU Snapdragon
512 MB RAM / 2048 MB ROM
Micro SD, 32 GB
AT&T has a 3g version
I'm betting these two are compatible, and the files I found contain some boot information.
Update:
I found the recovery.fstab for the U8800, doesn't look quite right does it:
Code:
# mount point fstype device [device2]
/boot mtd boot
/cache yaffs2 cache
/data yaffs2 userdata
/misc mtd misc
/recovery mtd recovery
/sdcard vfat /dev/block/mmcblk0p1 /dev/block/mmcblk0
/system yaffs2 system
I'm not sure how exactly to make this resemble the above partition table...
Update:
More information:
U-boot seems to support this board? Maybe this is good?
http://lists.denx.de/pipermail/u-boot/2012-February/118168.html
Also if anyone else wants to take a stab at this, by all means. I'm having trouble getting the tools set up, but if someone with a little more experince wants to that would be great.

Haven't seen this
aldude999 said:
I have the kernel source here, they have it released on SourceForge I'm guessing you're right saying the bootloader is locked.
Here's some information I've found on the partitions:
mmcblk0 Internal Memory
mmcblk0p1 Mounted using VFAT Contains files pertaining to FOTA (FOTA partition?)
mmcblk0p2 500 blocks ?
mmcblk0p3 1500 blocks ?
mmcblk0p4 1 BLOCK ?
mmcblk0p5 1000 blocks ?
mmcblk0p6 2000 blocks ?
mmcblk0p7 3072 blocks ?
mmcblk0p8 5120 blocks Possible Recovery*
mmcblk0p9 7000 blocks ?
mmcblk0p10 3027 blocks ?
mmcblk0p11 3072 blocks ?
mmcblk0p12 5120 blocks ?
mmcblk0p13 1500 blocks ?
mmcblk0p14 8192 blocks Mounts to /persist
mmcblk0p15 5120 blocks?
mmcblk0p16 1024 blocks?
mmcblk0p17 409600 blocks, Mounts to /system
mmcblk0p18 307200 blocks, Mounts to /cache
mmcblk0p19 892928 blocks, Mounts to /data
mmcblk0p20 122880 blocks, partition appears empty with a sting at the bottom of it reading ANDROID-BOOT!
mmcblk1 SD Card
mmcblk1p1 SD Card Partition
build.prop (Alltel phone):
build.prop
Source Code:
SourceForge Download Link
* In a recent patch I have found, the following code was in the install-recovery.sh file:
Code:
#!/system/bin/sh
if ! applypatch -c EMMC:/dev/block/mmcblk0p15:2048:afbffa74556cd8e77ef7e1a9d0964d9a2bd446b8; then
log -t recovery "Installing new recovery image"
applypatch EMMC:/dev/block/mmcblk0p8:4055040:9411e1fd06dfb3d8da4d1924162caf9e292ea652 EMMC:/dev/block/mmcblk0p15 20270fc8f6c8fca7dae0af5ce0928b589bd6b405 4296704 9411e1fd06dfb3d8da4d1924162caf9e292ea652:/system/recovery-from-boot.p
else
log -t recovery "Recovery image already installed"
fi
Any other information needed?
I'll look into getting a recovery working, but this is by no means a promise.
EDIT:
Something interesting:
The build.prop says the phone has a MSM7630_SURF board, and the Huawei U8800 has the same board, but not quite the same specs:
960C:
480x800
Multitouch
1400 Mhz CPU Sapdragon
512 MB RAM / 2048 MB ROM
Micro SD, 32 GB
3G
U8800:
480x800
Multitouch
800 Mhz CPU Snapdragon
512 MB RAM / 2048 MB ROM
Micro SD, 32 GB
AT&T has a 3g version
I'm betting these two are compatible, and the files I found contain some boot information.
Update:
I found the recovery.fstab for the U8800, doesn't look quite right does it:
Code:
# mount point fstype device [device2]
/boot mtd boot
/cache yaffs2 cache
/data yaffs2 userdata
/misc mtd misc
/recovery mtd recovery
/sdcard vfat /dev/block/mmcblk0p1 /dev/block/mmcblk0
/system yaffs2 system
I'm not sure how exactly to make this resemble the above partition table...
Update:
More information:
U-boot seems to support this board? Maybe this is good?
http://lists.denx.de/pipermail/u-boot/2012-February/118168.html
Also if anyone else wants to take a stab at this, by all means. I'm having trouble getting the tools set up, but if someone with a little more experince wants to that would be great.
Click to expand...
Click to collapse
Hello, I haven't looked into this thread for a while. I see that you have some info for these blocks. that I couldn't get. I tried using root explorer, to look into some files, and they couldn't load, and tried to use too much memory, just to attempt to open, which, my phone said it was low on memory. Hate gingerbread, and kwansi choi( maker of this rom), This phone could easily handle a later os.
The usb ID's, are "Device 007: ID 1bbb:9018" .

USB ID's
The usb ID's are 1bbb/9018 . I built a clockworkmod File, and the status is ok, but it still won't flash, because of the bootloader.

reggjoo said:
The usb ID's are 1bbb/9018 . I built a clockworkmod File, and the status is ok, but it still won't flash, because of the bootloader.
Click to expand...
Click to collapse
I noticed that:
mmcblk0p15
mmcblk0p12
mmcblk0p8
all have the same number of blocks.
The FOTA code shows
applypatch EMMC:/dev/block/mmcblk0p8:4055040:9411e1fd06dfb3d8da4d1924162caf9e292ea652 EMMC:/dev/block/mmcblk0p15 20270fc8f6c8fca7dae0af5ce0928b589bd6b405 4296704 9411e1fd06dfb3d8da4d1924162caf9e292ea652:/system/recovery-from-boot.p
Click to expand...
Click to collapse
applypatch useage is as follows:
applypatch [-b <bonus-file>] <src-file> <tgt-file> <tgt-sha1> <tgt-size> [<src-sha1>:<patch> ...]
or applypatch -c <file> [<sha1> ...]
or applypatch -s <bytes>
or applypatch -l
Click to expand...
Click to collapse
Apply patch from blk8 to blk15.
So maybe I was mistaken with what I thought was the partition. Blk8 seems to be where fota grabs it's updated partition from?
This shows that blk15 may actually be the recovery partition. Still useless unless the bootloader can be worked on.

Battery terminals
As we know, if the battery is out, the phone will do nothing( unlike my old huawei, it didn't matter). I wondered if that was the reason why, it's so hard to unlock it. I think the bootloader has been set up to not respond to attempts. The bootloader condition treats the phone as if there's no power to it(?) . I found out that the middle terminals, of the battery contacts, will power the phone, if they're connected, but only for a few seconds.
Maybe there's some code that's unknown, or procedure. The phone doesn't respond to fastboot commands, and I can't enable it(function), on it. In the default.prop file, I see that ro.secure, is 1. Whenever I try to change it to 0( in rewritable mode), it never takes. So this is a little info.

reggjoo said:
The bootloader condition treats the phone as if there's no power to it(?)
Click to expand...
Click to collapse
You know, it's interesting that you mention that. I remember watching a Ben Heck episode, and on an Xbox 360 controller keypad, he had to open it up and connect power to the PIC chip manually. It almost makes me wonder if there's possibly a jumper of some sort on the motherboard somewhere that when connected allows writing? It would be an extremely long shot, I'm even pretty sure that it's the exact board in the Huawei but it's weird that fastboot can't be entered. I've heard that their drivers might be messed up (maybe even on purpose) that could keep you from using fastboot.

aldude999 said:
You know, it's interesting that you mention that. I remember watching a Ben Heck episode, and on an Xbox 360 controller keypad, he had to open it up and connect power to the PIC chip manually. It almost makes me wonder if there's possibly a jumper of some sort on the motherboard somewhere that when connected allows writing? It would be an extremely long shot, I'm even pretty sure that it's the exact board in the Huawei but it's weird that fastboot can't be entered. I've heard that their drivers might be messed up (maybe even on purpose) that could keep you from using fastboot.
Click to expand...
Click to collapse
Yes, I think alcatel's a little shady. I use a dual boot pc, and I found out, using the lsusb command, that the usb id's were different, than what the id's were for the supposedly official usb drivers. Sent them a msg, and they said I was wrong( can't be wrong if everything works!). They take no responsibility for their hardware, and I let people know, every chance I get, whenever I see a review of a phone from them. I found out the id's were wrong, when, before I even rooted it, I installed their onetouchmanager, and it couldn't find my phone( what! out the box!). That's not the way you do things.

Bringing 960C Back To Life!!!
Did anyone ever find a ROM that's compatible with the 960C? I recently found one floating around a storage unit and, naturally, I immediately rooted it only to find out that no one ever bothered developing a custom ROM.
I'm sure if an official ROM was never created specifically for the 960C, it's definitely not gonna happen at this point. I'm thinking that the only hope for the 960C is if it was similar enough to a more popular phone that HAS a custom ROM, maybe someone, somewhere, was successful in modding it just enough to make it compatible with the 960C...
During my research/investigation into a ROM, there was at least one (*HERE*) forum post mentioning someone attempting to mod an existing ROM (for a more popular phone) to make it compatible but it seems that everyone lost interest back in 2013...

thealexday said:
Did anyone ever find a ROM that's compatible with the 960C? I recently found one floating around a storage unit and, naturally, I immediately rooted it only to find out that no one ever bothered developing a custom ROM.
I'm sure if an official ROM was never created specifically for the 960C, it's definitely not gonna happen at this point. I'm thinking that the only hope for the 960C is if it was similar enough to a more popular phone that HAS a custom ROM, maybe someone, somewhere, was successful in modding it just enough to make it compatible with the 960C...
During my research/investigation into a ROM, there was at least one (*HERE*) forum post mentioning someone attempting to mod an existing ROM (for a more popular phone) to make it compatible but it seems that everyone lost interest back in 2013...
Click to expand...
Click to collapse
I still am using my 960c. I wouldn't mind finding the original stock rom or finding out how to upgrade to a newer android version. Currently running version 2.3.6
Too bad I don't know much about modding save for rooting and flashing. I gather there are still some of us here who really like our 960c phones otherwise.

[SPRINT] Fix for OTA update with TWRP issue

I am making a separate thread specifically for Sprint because I have seen so many posts from Sprint users that took the OTA update, and I don't want this to be buried in the other thread.
If you have a Sprint G2, then you have to wipe the fota partition AND the misc partition.
Thanks so much to autoprime from #lg-g2 for pointing me in the right direction.
Code:
adb shell
cd /dev/block/platform/msm_sdcc.1/by-name
dd if=/dev/zero of=./fota
dd if=/dev/zero of=./misc
If you can't get adb to talk to your phone and only have the terminal from TWRP, then you will have to type the paths out -- make sure you get them right
-- Brian

I keep getting an error saying -
Code:
[email protected]:/dev/block/platform/msm_sdcc.1/by-name # dd if=/dev/zero of=./misc
zero of=./misc
./misc: write error: No space left on device
32769+0 records in
32768+0 records out
16777216 bytes transferred in 1.332 secs (12595507 bytes/sec)1

That is normal since we didn't specify a block size and a count. When dd fills the partition with zeros it errors out that it is out of space. The goal here is to do just that, fill the entire partition with zeros
-- Brian

runningnak3d said:
That is normal since we didn't specify a block size and a count. When dd fills the partition with zeros it errors out that it is out of space. The goal here is to do just that, fill the entire partition with zeros
-- Brian
Click to expand...
Click to collapse
That makes sense. Still learning about this side of android. Appreciate the help bro.

Silicon Knight said:
That makes sense. Still learning about this side of android. Appreciate the help bro.
Click to expand...
Click to collapse
does this work on D802 with CWM?
Also, i actually formatted all partitions shown on CWM advance menu.. does it mean my EFS is corrupt? I did not make EFS backup..

How To Guide How to backup your partitions with command line (requires root)

How to backup partition images with dd on the command line (root required)​
We don't currently have a working custom recovery for the Xperia 10 III, but if you have root there's a simple method to dump partition images.
This is a very good idea and you should do it at least once, especially if you like to mess around the device a lot.
You won't be able to do this before you root, so by the time you do some partitions will not be stock anymore. Use XperiFirm instead to get the clean stock images.
Special partitions:​
The userdata partition holds all your personal files and system settings. It's huge (about 105 GB) and obviously you can't dump it into itself. You can dump it on an SD card if it's 128+ GB.
The super partition is a physical partition that contains several logical partitions (including system and vendor) That's why you won't find those in the partition list. This is done on Android 10+ devices to allow those logical partitions to be resized or rearranged as needed. You don't need to split out the internal logical partitions, you can flash back the entire super partition. The stock firmware also comes with a super image, not individual logical partitions.
Using a helper script:​There's a Magisk module called Backup (by Draco) which gives you a command line shell script you can use if you prefer. It mostly does the same things I described above. The script is here if anybody wants to just grab it directly.
On the plus side, the script knows to dump only the active A/B image (which is the one that interests you most). On the flip side, it doesn't have a feature to skip userdata.
So here is a shell command that will use the backup script to dump all partitions, but only those matching your device's active A/B slot, and skips userdata:
Code:
backup $(ls /dev/block/bootdevice/by-name/ | grep -v userdata | sed 's/_[ab]$//')
And here's one that also skips super:
Code:
backup $(ls /dev/block/bootdevice/by-name/ | grep -v userdata | grep -v super | sed 's/_[ab]$//')
How to dump partitions manually:​If you can't/won't use the helper script you can do it by hand. All the following commands need root:
Find the names of all the partitions:
Code:
ls /dev/block/bootdevice/by-name/
Dump one specific partition identified by NAME:
Code:
dd if=/dev/block/bootdevice/by-name/NAME of=NAME.img
Dump all partitions except userdata:
Code:
ls /dev/block/bootdevice/by-name/ | grep -v userdata | while read NAME; do echo dd if=/dev/block/bootdevice/by-name/${NAME} of=${NAME}.img; done
Find the active slot:
Code:
getprop ro.boot.slot_suffix
Get checksums for all the images after the dump:
Code:
md5sum *.img
Confused about _a and _b partitions?​You should read about A/B Seamless Updates.
Long story short, some partitions have two copies eg. boot_a and boot_b. When you boot up the device you use the partitions in one slot (eg. the _a partitions). When an OTA update is being downloaded, it writes into the partitions for the other slot (eg. the _b partitions). Your phone can stay in use while this happens. If the OTA fails nothing is broken, you just keep using the good slot partitions. After the OTA is successful you switch to the other slot and also have the previous version in the other slot in case you need to switch back.
This means that some of the _a and _b images for the same partition can be different for you! So it's strongly recommended to do the checksums, and also to find out which is your active slot, so you know which partitions you're using right now.

I used a 128 GB card to take a backup of userdata. The backup script had some trouble with the backup location being on the storage card for some reason and I didn't have time to figure it out, but the dd command I gave above worked fine.
Code:
# time dd if=/dev/block/bootdevice/by-name/userdata of=userdata.img
112111374336 bytes (104 G) copied, 2342.274225 s, 46 M/s
39m02.31s real 1m11.78s user 14m44.72s system
Code:
# adb pull /storage/1234-ABCD/backup/userdata.img ./
/storage/1234-ABCD/backup/userdata.img: 1 file pulled, 0 skipped.
87.2 MB/s (112111374336 bytes in 1225.663s)
So that's 104 GB that took 39 minutes to be written to a new Samsung Evo U3/V30 microSDXC (46 MB/sec real write speed) and 20 minutes to be read to the PC (Samsung Evo M.2) with adb pull over USB (87 MB/sec read speed). Just so you know what you're in for.

I was looking into whether I could speed up the process of taking userdata snapshots by dumping the partition directly to the PC, but you need to be root to access the device block. The stock ROM doesn't allow the command adb root, but I found this blog post which made me realize you can run a su -c command that asks dd to write to stdout and just pipe the output to a file. The post author has also made this helpful Python script which lets you do pulls and pushes with root-only files.
If you want to run the command directly (I've only tested on Linux, no idea if it works on PowerShell but it might):
Code:
# adb shell "su -c" "dd if=/dev/block/bootdevice/by-name/userdata" > userdata.img
If you want to use the Python script:
Code:
# adb-root.py pull /dev/block/bootdevice/by-name/userdata userdata.img
Using the same fast SSD on the PC side as above, I now get:
Code:
218967528+0 records in
218967528+0 records out
112111374336 bytes (104 G) copied, 1077.681097 s, 99 M/s
real 17m57.910s
So that's roughly 15 minutes compared to 1 hour total with the previous method and you don't need to have a 128 GB SD card anymore.

Are you able to switch to a different backup location? Say a USB OTG if possible.

mikeshutte said:
Are you able to switch to a different backup location? Say a USB OTG if possible.
Click to expand...
Click to collapse
With dd yes, simply move to the directory you want before you call dd.
The backup script is bugged and seems to ignore the -d parameter for the backup location so it always uses /sdcard/backup. (I think it might be expecting a different version of getopts...) Normally I would say to try creating a symlink from /sdcard/backup to the OTG storage but the ln utility is also behaving strangely and I can't make any symlinks (even with root).

wirespot said:
With dd yes, simply move to the directory you want before you call dd.
The backup script is bugged and seems to ignore the -d parameter for the backup location so it always uses /sdcard/backup. (I think it might be expecting a different version of getopts...) Normally I would say to try creating a symlink from /sdcard/backup to the OTG storage but the ln utility is also behaving strangely and I can't make any symlinks (even with root).
Click to expand...
Click to collapse
Ok I'll give it a try and see what happens. Thanks for your help.

Hi, I'm used to TWRP backups, so I don't really understand this tool. I've backedup everything except the massive userdata partition. If needed, how would I restore this? Is the userdata partition required when I have all the others?
Thanks!

jakito said:
Hi, I'm used to TWRP backups, so I don't really understand this tool. I've backedup everything except the massive userdata partition. If needed, how would I restore this? Is the userdata partition required when I have all the others?
Thanks!
Click to expand...
Click to collapse
This is basically the same thing that TWRP does, dd is a command line Linux tool that makes a "raw" copy of a partition.
Restoration is a bit more tricky. In theory you can simply dump the raw backup copy over the partition. The problem is that it's not ok to do it while the system is running. Typically it's done by booting into recovery (TWRP) and overwriting the partition from there.
Another method for restore is to use fastboot, which is an alternative tool you can boot into that only does one thing, write partitions. But fastboot is typically locked by the vendor to only write signed images, so it can only be used to write official release ROMs.
There are some limited uses for fastboot, such as overwriting the boot partition, which is not checked for signature anymore once you've unlocked the bootloader. So if you want to experiment with unofficial kernels and mess something up you can always restore a good boot partition with fastboot.
TLDR: for the time being until we get a working TWRP recovery the most you can do is take backups, but not restore them.

wirespot said:
This is basically the same thing that TWRP does, dd is a command line Linux tool that makes a "raw" copy of a partition.
Restoration is a bit more tricky. In theory you can simply dump the raw backup copy over the partition. The problem is that it's not ok to do it while the system is running. Typically it's done by booting into recovery (TWRP) and overwriting the partition from there.
Another method for restore is to use fastboot, which is an alternative tool you can boot into that only does one thing, write partitions. But fastboot is typically locked by the vendor to only write signed images, so it can only be used to write official release ROMs.
There are some limited uses for fastboot, such as overwriting the boot partition, which is not checked for signature anymore once you've unlocked the bootloader. So if you want to experiment with unofficial kernels and mess something up you can always restore a good boot partition with fastboot.
TLDR: for the time being until we get a working TWRP recovery the most you can do is take backups, but not restore them.
Click to expand...
Click to collapse
I see. Thank you nonetheless!

wirespot said:
This is basically the same thing that TWRP does, dd is a command line Linux tool that makes a "raw" copy of a partition.
Restoration is a bit more tricky. In theory you can simply dump the raw backup copy over the partition. The problem is that it's not ok to do it while the system is running. Typically it's done by booting into recovery (TWRP) and overwriting the partition from there.
Another method for restore is to use fastboot, which is an alternative tool you can boot into that only does one thing, write partitions. But fastboot is typically locked by the vendor to only write signed images, so it can only be used to write official release ROMs.
There are some limited uses for fastboot, such as overwriting the boot partition, which is not checked for signature anymore once you've unlocked the bootloader. So if you want to experiment with unofficial kernels and mess something up you can always restore a good boot partition with fastboot.
TLDR: for the time being until we get a working TWRP recovery the most you can do is take backups, but not restore them.
Click to expand...
Click to collapse
I don't know how I ended up but making a backup you can't restore is completely pointless.

Techguy777 said:
I don't know how I ended up but making a backup you can't restore is completely pointless.
Click to expand...
Click to collapse
No, it's not. All your data is in there. You can mount your backup on a linux computer and pull out apks as well as app data. You can then restore these folder by folder with adb and a root shell on your phone.
That beeing said, does anyone know a proper backup software like Titanium Backup for Android 11 and above? Sometimes I read recommendations, but looking at the ratings it seems that no software manages to achieve the same level of comfort and control. Also they all seem to suffer from the same limitations.
Let's be honest: Google wants to make your life hard, so they can lock you in.

@xperinaut
I'm using Titanium on Android 11. Is it not working for you?