Powered by Flashize.
many older devices, especially the ones originally released before emulated storage was available, were partitioned by the OEM in ways that hinder the installation and use of newer Android versions. for example, the Galaxy S2 GT-I9100 comes with a 0.5 GiB /system partition that is unable to fit CM 13.0 and Open GApps, even if you choose the pico version. though its flash is typically a generous 16 GiB, the stock /data partition is only 2 GiB which means that with today's ART you run out of space to install applications in no time. it also comes with a 0.5 GiB /preload partition that goes unused on custom ROMs.
people have typically solved this by repartitioning. on Samsung devices this is a tricky process that involves the use of download mode, a Windows PC, Windows device drivers that support the device's download mode, a 'pirated' proprietary PC software called Odin, the right PIT and other files, and correct configuration. (a free software alternative to Odin called Heimdall works on many devices and is cross platform and supports Linux PCs, but the rest of the hurdles remain.) the procedure has potential for hard-bricking if the wrong files are flashed. after repartitioning, all affected partitions must be reflashed or formatted anew, a procedure that many get wrong. and of course, all data in the affected partitions gets wiped (typically the complete device) making this an ultra-inconvenient affair.
REPIT is a simple, safe, device-only, data-sparing, and easily portable repartitioning tool for Android devices:
you can look at the log of a demo run to get a feel for what REPIT can do. in this run on a Galaxy S2 it grows the /system and /data ext4 partitions to 1 and 6 GiB respectively, it wipes and shrinks the unused /preload partition to a minimum size, and it adjusts the size of the internal /sdcard vfat partition to occupy whatever space is left. REPIT plans, orders and undertakes a safe series of partition resize and move operations to reach its goal, all the while keeping and eye on details such as alignments and retaining the data present in the /system, /data and /sdcard partitions.
finally, go get a coffee or two. do not, under any circumstance, interrupt this script !!!
in case the script fails to start:
if you want to sideload:
-system=1G
is enough (the -
is required). note that your recovery might require you to resign the zip after that change.configure the script by renaming the zip file before flashing it.
valid zip names: <prefix>[-partition1=<conf>][-partition2=<conf>]...<suffix>
valid partition <conf>
values: [<size>(G|M)|same|min|max][+[keep|wipe][+[ext4|vfat|f2fs|swap|raw]]]
the defaults are device-dependent. please look inside your device's configuration file for more information. for configuration samples please see the i9100 section below.
keep
: retain the data in the partition. if the partition needs to be moved or resized, this option usually makes the operation significantly slower, even if the partition is mostly empty.wipe
: wipe the partition. always wipe partitions that are empty or carry data that you do not care about: it will make REPIT faster and will result in less wear on the flash memory.same
: do not alter the size of this partition.min
: make this unused partition a minimum yet formattable size (typically 8 MiB, but device-dependent).max
: make this partition as big as possible (at most one partition per 'heap' can have its size set to 'max').<size>(G|M)
: fractional number followed by a size unit expressing the desired partition size. the unit is either G
for GiB or M
for MiB. this value gets rounded to the nearest acceptable discreet value. the size granularity is device-dependent, but typically set to match the device-dependent partition alignment (which typically is 1 or 4 MiB).ext4
and vfat
: these partitions have full move, resize and wipe support.f2fs
: f2fs partitions can be moved and wiped, and can only be resized while wiping them.
swap
: swap partitions can be wiped, and can only be moved or resized while wiping them.
raw
: raw partitions are treated as opaque blobs and can only be moved.
wipe | keep + move | keep + resize | keep + move + resize | crypto footer | |
---|---|---|---|---|---|
ext4 | YES | YES (brute force) | YES (efficient) | YES (brute force) | YES |
vfat | YES | YES (efficient) | YES (efficient) | YES (efficient) | no |
f2fs | YES | YES (brute force) | no | no | YES |
swap | YES | no | no | no | no |
raw | no | YES | no | no | no |
if there are any problems, read the log! you can scroll it on TWRP. most likely it will tell you what is wrong and what to do about it. if not, make sure to somehow record the log. REPIT logs to file '/tmp/lanchon-repit.log'. otherwise, you can obtain a copy of TWRP's log (which includes REPIT's log), or if not at least take a picture of it with your camera. in TWRP 2.8.7.* you can see a full screen log by hitting the back button once, then the center button at the bottom of the screen that looks like a TV screen. after recording the log, you can try reflashing the script if you understand what happened and flashing it again makes sense.
PLEASE NOTE: your 'did not work' report is useless unless you post info from your log.
each supported device has a unique targeted build of REPIT in the download section. you can also find device-specific information in the device tree; try searching by device codename using Github's find file. all configuration options for a specific device are defined in the corresponding <device-codename>.sh
file and the common.sh
files that might exist in the same directory and in directories above it. you might also find device-specific readme files with relevant information.
so your device is unsupported, tough luck... but porting REPIT to a new device is an easy job; you can either do it yourself or request that i do it for you. to request a new port, please follow this steps; port requests are welcome. if you want to get your hands dirty, check the configuration files for i9100 (1, 2), they are the most complete and commented. but usually you can get away with much less, take a look at i9300. for an example of how to handle out-of-order partitions, check out janice.
REPIT started its life as i9100-only tool and it inherits this doc section from the good old days.
IMPORTANT NOTE: this script will not work if your phone is encrypted. you need to decrypt your phone first. this was found and reported by XDA user jer194 here. if you run the script on an encrypted phone anyway, no damage will come: it will just refuse to start, complaining that it cannot reread the partition table.
download and flash the file as it is. it will get most space from the unused /preload partition and only 8 MiB for the internal sdcard, and then make /system 1 GiB in size. it will keep you current /data size constant, whatever it is. it will retain all data except data in /preload, which is unused in custom roms (but some multi-boot setups use it).
you can nonetheless use this script to do general repartitioning, file system fixing, wiping, and/or file system type changes. download the script, rename it to express your desired configuration (see below), and then flash it.
first get official TWRP running on your device, then follow the generic how-to.
valid zip names: <prefix>[-system=<conf>][-data=<conf>][-sdcard=<conf>][-preload=<conf>]<suffix>
for this device, partition alignment is 4 MiB and partition sizes get rounded to the nearest 4 MiB boundary. (it is typical for all devices to use the same value for partition alignment and granularity.)
-system=same+keep+ext4
-data=same+keep+ext4
-sdcard=same+keep+vfat
<-- note vfat
here-preload=same+keep+ext4
lanchon-repit-XXXXXXXX-system=0.5G-data=2G-sdcard=max-preload=0.5G+wipe-i9100.zip
-system=0.5G-data=2G-sdcard=max-preload=0.5G
-data=+wipe
-sdcard=+wipe+ext4
-system=1G-data=6G-sdcard=max-preload=min+wipe
-system=1G-data=6G-sdcard=max++ext4-preload=min+wipe
-system=1G-data=6G+wipe-sdcard=max-preload=min+wipe
i believe this software to be very safe and i exercised it a lot before posting it. but i accept no responsibility if your data is lost or your device is bricked.
for historical information regarding the CHEF-KOCH incident (and XDA's response), please follow this link.