I start this thread due to popular demand. This issue is brought up every once in a while in regards to the Galaxy S2 family of devices, but may be of interest to owners of other similarly old hardware. I have been sitting on this info for over a year without time to document it and develop it further, and finally decided to publish what i know so others can implement what is needed.
NOTE: This information applies to Android 6. In Android 7+ things could have changed.
EDIT: confirmed working on Android 7.1.1 (CM14.1) by the.gangster!
What is this?
Old hardware that originally shipped with pre-ICS Android (such as the Galaxy S2 and friends) that provides an "internal" SD card, do so by means of a dedicated FAT partition in the eMMC that is separate from the EXT4 /data partition. On the other hand, newer hardware comes with a single big EXT4 /data partition and "emulates" an SD card (or several) by storing their contents in the /data/media folder. This is called "emulated storage".
Advantages of emulated storage
Emulated storage has many advantages over non-emulated storage:
- EXT4 is a modern journaling file system that is much safer than FAT.
- Due to increased safety, mount-time full file system check is not necessary in EXT4; so it mounts much faster than FAT.
- FAT is limited to files that are less than 4GB in size.
- Emulated storage can be encrypted.
- Only devices with emulated storage can support multiple users.
Conventional wisdom
All over the net you can find discussions regarding switching to emulated storage. Basically a two step process:
- Repartition your device to a huge /data and a vestigial or deleted /sdcard.
- Build a modified Android from source for your device that uses emulated storage.
Discussions center on the fact that ROM maintainers do not want to switch to emulated storage to avoid forcing everyone to repartition and wipe their phones.
The big misconception
The reality is that emulated storage can be used with standard ROMs built for non-emulated devices. The ROMs do not even need to be patched and can be flashed and used as-is. The repeated discussions over whether CM should switch have always been unnecessary.
How does it work then?
Surprisingly, Android stores the flag determining whether storage emulation is enabled or not in /data, presumably to allow upgrades from non-emulated to emulated modes. The flag is stored in /data/system/storage.xml: non-emulated storage is signaled by the presence of XML attribute primaryStorageUuid="primary_physical". To enable emulated storage: just edit this file, remove said attribute, and reboot. It is that simple.
What happens if I upgrade my ROM?
Everything keeps on working as it should; the above change only affects /data.
What happens if I wipe /data?
Your device will return to non-emulated mode. If the /sdcard partition is missing, it might not be able to boot.
Can wipe be 'fixed'?
Yes, but it requires a change in the ROM. This change has to be reapplied somehow every time you upgrade your ROM.
After a wipe, Android will initialize /data/system/storage.xml based on the value of system property ro.vold.primary_physical. If set to 1, Android will use non-emulated storage. To fix wipe, set this property to 0.
Is that all there is to it?
Nope! Recovery will still think you are on non-emulated storage and format /data when you choose to wipe it. This means that "wipe /data" will also wipe your emulated SD card!!! This is very dangerous.
I recommend that someone like Arnab builds a TWRP image for emulated storage. Maybe a second official build could be configured: something like device 'i9100_emu'.
I made an on-device patcher for TWRP before, and a year ago I tried to adapt it to mod TWRP for emulated storage use. Unfortunately I seem to remember that it is not possible to mod a TWRP image as the emu/non-emu distinction apparently gets baked into the code during compilation. Nonetheless, i found a file called 'lanchon-emulated-sd-twrp-3.0.2-0-i9100.img' lying around in my hard drive, and i have no idea what it is. Maybe a failed attempt? Could it work? I don't know, i don't remember what it is; guess not, but i could post it.
Moving forward
A year ago I wanted to make some scripts to do these changes, then run them though Flashize and sign them to convert them to flashable scripts. I don't have time for any of this now, but if someone wants to follow up, here is what could be done:
- A script to convert to emulated storage.
- A script to mod the ROM to use emulated storage after a /data wipe.
- A script like the previous one that uses the 'addon' ROM flashing mechanism to auto-run after each ROM flash, just like GAPPS do.
Of course a modded TWRP image would also be a great thing to have.
What else?
There is the question of what happens to the partition that had been /sdcard before the conversion. I suppose it gets mounted as a secondary SD card. In the case of the S2, that has an actual SD card slot, you can probably have two secondary SD cards mounted simultaneously.
The vestigial internal SD card is useless and it would be preferable to have it disappear. Methods to try:
- Wipe the /sdcard partition area so that the file system is gone and it cannot be mounted. This might produce the desired outcome, or Android might just fail to boot.
- Mod the ROM so that it does not look for this partition.
- Configure Android to swap SD cards 0 and 1, so that at least /sdcard0 is the external, useful one. (There are several threads covering this.)
How to repartition
REPIT cannot move data from one partition to another. So unless you manually backup the data in /sdcard, you will loose it.
On the i9100, to enlarge /data and reduce /sdcard to the minimum, you can use this configuration after backing up the /sdcard:
If you want to try rendering /sdcard unmountable to see what happens, you can use this configuration instead:
NOTE: REPIT does not work on encrypted phones! If your phone is encrypted, you will have to back up /data to an external SD card and then format it to get rid of encryption before using REPIT.
And that's all folks!
I believe this procedure is too involved for the average user. So IMHO the standard builds should not move to emulated storage, given that advanced users can convert by themselves. The big problem is that wiping /sdcard is unavoidable due to lack of spare space to hold the data, unless really smart scripts that reduce and enlarge the partitions incrementally while moving files are made. A TWRP build that is able to backup and restore both the emulated and non-emulated sdcards to the external sdcard would be a big hit for this operation. The other big issue is handling encrypted phones; TWRP backups can help in that regard too.
Please share your experiences on this thread. I cannot test any of this, but with your help a full solution can be found.
NOTE: This information applies to Android 6. In Android 7+ things could have changed.
EDIT: confirmed working on Android 7.1.1 (CM14.1) by the.gangster!
What is this?
Old hardware that originally shipped with pre-ICS Android (such as the Galaxy S2 and friends) that provides an "internal" SD card, do so by means of a dedicated FAT partition in the eMMC that is separate from the EXT4 /data partition. On the other hand, newer hardware comes with a single big EXT4 /data partition and "emulates" an SD card (or several) by storing their contents in the /data/media folder. This is called "emulated storage".
Advantages of emulated storage
Emulated storage has many advantages over non-emulated storage:
- EXT4 is a modern journaling file system that is much safer than FAT.
- Due to increased safety, mount-time full file system check is not necessary in EXT4; so it mounts much faster than FAT.
- FAT is limited to files that are less than 4GB in size.
- Emulated storage can be encrypted.
- Only devices with emulated storage can support multiple users.
Conventional wisdom
All over the net you can find discussions regarding switching to emulated storage. Basically a two step process:
- Repartition your device to a huge /data and a vestigial or deleted /sdcard.
- Build a modified Android from source for your device that uses emulated storage.
Discussions center on the fact that ROM maintainers do not want to switch to emulated storage to avoid forcing everyone to repartition and wipe their phones.
The big misconception
The reality is that emulated storage can be used with standard ROMs built for non-emulated devices. The ROMs do not even need to be patched and can be flashed and used as-is. The repeated discussions over whether CM should switch have always been unnecessary.
How does it work then?
Surprisingly, Android stores the flag determining whether storage emulation is enabled or not in /data, presumably to allow upgrades from non-emulated to emulated modes. The flag is stored in /data/system/storage.xml: non-emulated storage is signaled by the presence of XML attribute primaryStorageUuid="primary_physical". To enable emulated storage: just edit this file, remove said attribute, and reboot. It is that simple.
What happens if I upgrade my ROM?
Everything keeps on working as it should; the above change only affects /data.
What happens if I wipe /data?
Your device will return to non-emulated mode. If the /sdcard partition is missing, it might not be able to boot.
Can wipe be 'fixed'?
Yes, but it requires a change in the ROM. This change has to be reapplied somehow every time you upgrade your ROM.
After a wipe, Android will initialize /data/system/storage.xml based on the value of system property ro.vold.primary_physical. If set to 1, Android will use non-emulated storage. To fix wipe, set this property to 0.
Is that all there is to it?
Nope! Recovery will still think you are on non-emulated storage and format /data when you choose to wipe it. This means that "wipe /data" will also wipe your emulated SD card!!! This is very dangerous.
I recommend that someone like Arnab builds a TWRP image for emulated storage. Maybe a second official build could be configured: something like device 'i9100_emu'.
I made an on-device patcher for TWRP before, and a year ago I tried to adapt it to mod TWRP for emulated storage use. Unfortunately I seem to remember that it is not possible to mod a TWRP image as the emu/non-emu distinction apparently gets baked into the code during compilation. Nonetheless, i found a file called 'lanchon-emulated-sd-twrp-3.0.2-0-i9100.img' lying around in my hard drive, and i have no idea what it is. Maybe a failed attempt? Could it work? I don't know, i don't remember what it is; guess not, but i could post it.
Moving forward
A year ago I wanted to make some scripts to do these changes, then run them though Flashize and sign them to convert them to flashable scripts. I don't have time for any of this now, but if someone wants to follow up, here is what could be done:
- A script to convert to emulated storage.
- A script to mod the ROM to use emulated storage after a /data wipe.
- A script like the previous one that uses the 'addon' ROM flashing mechanism to auto-run after each ROM flash, just like GAPPS do.
Of course a modded TWRP image would also be a great thing to have.
What else?
There is the question of what happens to the partition that had been /sdcard before the conversion. I suppose it gets mounted as a secondary SD card. In the case of the S2, that has an actual SD card slot, you can probably have two secondary SD cards mounted simultaneously.
The vestigial internal SD card is useless and it would be preferable to have it disappear. Methods to try:
- Wipe the /sdcard partition area so that the file system is gone and it cannot be mounted. This might produce the desired outcome, or Android might just fail to boot.
- Mod the ROM so that it does not look for this partition.
- Configure Android to swap SD cards 0 and 1, so that at least /sdcard0 is the external, useful one. (There are several threads covering this.)
How to repartition
REPIT cannot move data from one partition to another. So unless you manually backup the data in /sdcard, you will loose it.
On the i9100, to enlarge /data and reduce /sdcard to the minimum, you can use this configuration after backing up the /sdcard:
lanchon-repit-XXXXXXXX-system=same-data=max-sdcard=min+wipe-preload=min+wipe-i9100.zip
If you want to try rendering /sdcard unmountable to see what happens, you can use this configuration instead:
lanchon-repit-XXXXXXXX-system=same-data=max-sdcard=min+wipe+swap-preload=min+wipe-i9100.zip
NOTE: REPIT does not work on encrypted phones! If your phone is encrypted, you will have to back up /data to an external SD card and then format it to get rid of encryption before using REPIT.
And that's all folks!
I believe this procedure is too involved for the average user. So IMHO the standard builds should not move to emulated storage, given that advanced users can convert by themselves. The big problem is that wiping /sdcard is unavoidable due to lack of spare space to hold the data, unless really smart scripts that reduce and enlarge the partitions incrementally while moving files are made. A TWRP build that is able to backup and restore both the emulated and non-emulated sdcards to the external sdcard would be a big hit for this operation. The other big issue is handling encrypted phones; TWRP backups can help in that regard too.
Please share your experiences on this thread. I cannot test any of this, but with your help a full solution can be found.
Last edited: