[Galaxy S II Original Android Development] Lanchon:
hi rINanDO,

i brought you to this thread to keep the Lineage thread on-topic and to concentrate here info about the emulated sd work, i hope you don't mind.

although a new PIT doesnt hurt, please also consider my REPIT script that can repartition and handle any size of start partitions without loosing data. it also handles 8GB and 32GB i9100s, which are rare but exist (i was forced to support them as they showed up when /system wouldn't fit CM anymore) and n7000s and the other S2 family members.

in this particular use case, the data in /system and /data would be preserved. what REPIT cannot do is move data from one partition to another, such as moving from /sdcard to /data/media, so the /sdcard would be lost and needs backing up. note that in the general case (partitions full of data) this data move cannot be done in one shot without external storage. (REPIT will never learn to do this trick: it si outside the scope of the tool.)

if you want to look, i give info on how to do the emulated sd conversion with REPIT in the OP of this thread, in the section "How to repartition".

PIT

regarding the PIT that you are making, i ask that you consider not to remove the /sdcard partition, but rather just make it very small. 8MiB is the smallest ext4 formattable power of 2 size that you can get. (the size keyword "min" in repit for i9100 is an alias for 8MiB).

the reasons are:

#1- if you remove a partition, REPIT sanity checks will no longer pass and the tool will refuse to run on those devices.

#2- because of migration backup (explained below).

TWRP

it's great that you are working on a proper TWRP to support emulated storage! this is the big part that's missing, you'll do S2 owners a big favor.

besides using the standard TWRP switch for emulated storage, i suggest you also try and make theses changes to TWRP to ease the migration procedure, if they end up being possible:

- add /data/media to the list of "partitions" that TWRP is able to backup (might not be possible!).

- add /sdcard to the list of partitions that TWRP is able to backup.

- these two partitions should be added using the same backup name/ID.

the migration procedure would be something like this:

- flash your modded TWRP.

- backup /sdcard to external storage (external SD or USB mass storage).

- optionally backup /data and/or /system if information there is valuable.

- run REPIT to expand /data and wipe and shrink /sdcard. (this is compatible with and keeps any previous /system size.)

- restore /data/media from external storage. (because the two "partitions" share the same backup name/ID, TWRP will restore the info that was stored in /sdcard to /data/media.)

- (no /data or /system restore is needed if using REPIT.)

for this to work, it's imperative that the modded TWRP be able to access the /sdcard partition. this is why i suggest above that you keep /sdcard in your PIT (reason #2). otherwise parts of TWRP might misbehave if the expected partition is not there, i don't know for sure. i think it's just less problematic not to remove the partition; that's why when i did REPIT i chose to shrink /preload to minimum instead of removing it. some kernels had issues if /preload went missing.

the proposed mod creates the possibility of a user backing up a storage onto itself. for instance, backup /data/media to /data/media. IMHO, its ok not to detect this: users should know better. the result of this could be undefined, including the possibility of a total hung of TWRP util the affected partition goes full.

for completeness, not only should modded TWRP backup to/from:

- USB

- external SD

- /data/media

but should also backup to/from /sdcard. this would provide total orthogonality between the two internal storage spaces.

btw, the user-visible names i recommend for the the internal spaces are:

- "Emulated storage"

- "Non-emulated storage"

because "Non-emulated internal storage" is just too long. these names should apply to the backup "partition" selection menu when creating or restoring backups, and to the storage selection menu when configuring where backups are made to or restored from.

EDIT:

some details i forgot...

if you favor removing the /sdcard partition because that way android won't show it, keep in mind that some android builds might fail to boot. a better possibility would be to simply wipe the file system from the partition. that way users who need the partition back can just format it. i suppose this should be enough to stop android from showing the partition in every place except where it offers you to format it.

one option to do this in REPIT is to switch the file system type of the partition to 'swap'. it's not exactly the same, but might be close enough.

the reason i didn't support a 'zero' partition type in REPIT (i thought of it) is that the 32 bit 'dd' in busybox wraps around at 4GB. this means that, to do a full partition wipe, one needs to delete the partition and create several partitions in its place, each smaller than the dd wrap-around, serially segmenting the original partition area, and dd zero over each part. then finally restore the original partition in the partition table. (btw, this is how i move partitions in REPIT.) it's not difficult to do, but it was just too much work for an option that nobody would use.

the alternatives are:

- TRIMming the complete partition (but this makes the workings of REPIT dependent on kernel support and eMMC type, and i won't go for it).

- zeroing the beginning of the partition only.

- a combination of both methods.

i'm open to implement a 'zero' or 'blank' partition type in REPIT.