Mounts2SD is a customizable sd-ext control script that can be used to move content to and from the second sdcard partition known in Android as sd-ext. In addition to moving content, Mounts2SD comes with other features and is also the only script that has a bunch of safe guards build-in for almost any situation, making sure that when things go wrong, the script will adapt and try keeping your phone running 100% and try to make sure that data is not lost or corrupted. And it comes with an app to configure the script and monitor the options current status in real time.
For the love of god, make sure to do a full recovery backup before attempting to install something like this
If not, I do not want to hear any complaints about your loss of data if something went wrong
Make sure to backup your device before attempting this
If you encounter any issues with Mounts2SD, there are several ways to get help
While creating your bug report, there are some information that you will need to provide, otherwise no one will be able to help and your report is a waste of time
Normal operating systems like Linux, Windows etc. allows you to store different types of applications and also wherever you'd like. Mobile operating systems like Android however, uses APK's (Special ZIP Files) to pack applications and it stores both the application (APK) and all of it's data like libraries and user data (Settings and such) on the /data partition in specific sub-folders. The OS is not built to look for applications and data elsewhere, so if you run out of space on this partition, you will be out of luck. Especially since you cannot upgrade the internal nand drive.
The conept of sd-ext was created for this very reason. It enables you to move some of the content from /data and place it on an additional partition on your external sdcard (sd-ext), something that you are able to upgrade. The problem however is that Android, like mentioned above, is not able to look for applications and other types of data outside the /data partition, so whatever you move to sd-ext, will not be located by Android. This is where the sd-ext scripts comes in to play. The trick is to make Android think that everything is still located on the /data partition, while in fact it is stored on the sd-ext partition. The way this works is that the sd-ext script moves one or more sub-folders from /data to sd-ext, folders like app
which stores the APK files or data
which stores the user specific app configurations. Once moved to sd-ext, the script will then mount (link) each sub-folder from sd-ext and back to /data where Android can find it. Now every time Android accesses one of these moved folders to read, write or store files, Android will in fact be using the files from sd-ext, even though it accesses them via /data.
One thing to note here is that Android is not aware of the sd-ext partition. This means that you will not be able to see this partition from within the Android Settings. You will however be able to see the extra space on your /data partition after moving some of the content to sd-ext.
Also note that sd-ext is NOT your external sdcard storage partition (/sdcard, /extSdCard, /mnt/sdcard etc.). It is a SECOND partition on your external sdcard which the script handles during boot.
Android, like any Linux based operating system, uses POSIX-compliant permission scheme to administer files and folder permissions. Android uses these permissions to restrict access to files and folders for specific processes. For an example, any file and folder owned by a specific application, can only be accesses by this application (Unless it was created world wide). Also many Android system files and folders can not be accessed by any application at all. All of these permissions is written in a header on each file and folder, which means that in order to work, it will need a file system that supports this type of permission scheme. The Fat32 file system for an example, was created by Microsoft and therefore does not support this scheme. This means that the sd-ext partition needs to be formated using a Linux File system like Ext2, Ext3, Ext4, XFS etc. Otherwise Android will not be able to set permissions on any content within sd-ext, and will in most cases refuse to boot the device.
Android is pre-configured to use the first sdcard partition as the external storage device (Where you save your Music, Photos etc.). Therefor, the sd-ext partition needs to be added as the second partition on the sdcard.
You can also add a SWAP partition to the sdcard. This should be the third partition in the table.
When Android boots a device, it executes the init binary which is located in the device's boot partition. By using multiple init.rc files (customizable configurations for init), it handles all of the pre-boot configurations like creating missing folders, setting specific permissions on important files and folders, setting up shell environment variables, starting all of the services needed for Android to run and much more. Basically anything that should be handled before entering into the actual Android OS.
Some times you might want to add additional jobs to be handled during boot, like changing partition mount arguments, changing sdcard readahead, setting up custom kernel settings like CPU OC or in this case, handle the sd-ext partition and move content to and from the original /data partition. The problem with init's configuration files, is that they are located on the boot partition and everything here is packed into a boot.img file, so it cannot be altered easily. In order to add custom jobs to init, you will need to reboot into the recovery, extract the boot.img, unpack it, add your custom work, repack it and flash it back to the boot partition. To make this a lot easier, custom ROM's often comes pre-configured with an init.d feature, which is a small change to the boot.img that during boot, will execute any script located in /system/etc/init.d/. This makes it easier to add custom work for init as you will only need to add new scripts to this folder.
If you are not running a custom ROM, but just rooted your stock version, you can use Init.d Injector to add init.d support to it.
There are two types of init.d support. One which executes scripts in the background while the OS is booting and one which executes scripts in the foreground while waiting for them to finish before booting the OS.
Sd-ext scripts works better with the second option. Once the OS is booted, it will start using the content placed on the data partition, in which case it is not smart to start moving it around. To avoid any issues, a safe mode has been added to Mounts2SD which will auto disable certain options that are known to cause damage under these circumstances whenever this type of init.d support is detected.
Mounts2SD also has a work-around for this type of init.d support, which is used whenever safe mode has been disabled. By default, this is used. However, it is still possible to enable safe-mode if the work-around whould cause any problems on certain devices.
You also have the option of adding the better type of support by using Init.d Injector
Mounts2SD enabled a feature which allows you to store system files on /data or sd-ext (Files normally found in /system). The first added support was for system applications (/system/app), which could be placed on /data/app-system and then moved to sd-ext by the script depending on your application options. In Mounts2SD version 3+ (Script version 6+), a new feature was added which allows you to store anything system related on /data and sd-ext. By adding a folder to /data named [NAME]_s, for an example /data/app_s or /data/lib_s, Mounts2SD will link any content in these folders to it's original system folder, for an example /system/app and /system/lib.
Unlike the old /data/app-system feature, using /data/[NAME]_s provides an additional option for moving the content to sd-ext, which enables you to keep system files on /data while moving regular applications to sd-ext (The app option will move both regular APK's and the once in /data/app-system).
In order to configure the script, some sort of configuration system is needed to store custom setups which the script can then read during boot. Mounts2SD uses property files located in /data/property. It keeps one files for each available option, and each file is named /data/property/m2sd.[OPTION]
1 = enabled
, 0 = disabled
1 = enabled
, 0 = disabled
1 = enabled
, 0 = disabled
1 = enabled
, 0 = disabled
1 = enabled
, 0 = disabled
1 = enabled
, 0 = disabled
2 = auto
, 1 = enabled
, 0 = disabled
1 = enabled
, 0 = disabled
2 = don't change
, 1 = enable journal
, 0 = disable journal
1 = enabled
, 0 = disabled
Integer from 0 to 100
Type like ext2 or xfs
, auto = Auto Detection
1 = enabled
, 0 = disabled
Integer in percentage, like 10 for 10%
, 0 = disable feature
Integer in percentage, like 10 for 10%
, 0 = disabled
Integer in kilobytes
Scheduler type like row and cfq
Integer in kilobytes
Scheduler type like row and cfq
1 = disable safe mode
, 0 = use safe mode
Having root enabled on your device can be a great thing. It enables applications to provide much more features that Android would normally not allow applications to provide. However, it can also be very risky as applications which are granted root permissions can do anything that they like. There is no restrictions enabled for root. For this reason, no one should ever grand any closed source applications root permissions, as they could hide anything in their code. Mounts2SD is full Open Sourced, so anyone can look trough the code to see what both the application and the script is using root for. To make it easier for people that cannot read programming code, I will explain the usage of the root permissions.
Normal processes like applications and such, are not allowed to view or change any file or folder stored in /data which is not owned by the process itself. This means that in order for the script to move content not owned by Mounts2SD from /data to sd-ext, it needs to do so using root.
Most of the application can do without root, however, calculating how much space each /data folder uses (Displayed in the app), needs root permissions as the app is not allowed access to any /data sub folder, not even to calculate the size of the content within. It also needs root to list the current value of the storge threshold, as this value is stored in a database file which is not accessable for regular applications. And last, it needs root in order to write configurations to the script property files located in /data/property, as this folder also is not accessable for regular applications. So most of the application root usage, is used to collect specific information. The only changes made as root, is to the scripts own property files.
Besides the Log Viewer, Mounts2SD has two Tabs/Screens. One of them is used to display the current state (Overview)
and the other is used to change the scripts setup (Configure)
.
The current state means all of the current values used by the device at the moment, like which folder are linked from sd-ext to data, what file system type that sd-ext is currently mounted as, the current value of the storage threshold and so on. Mounts2SD uses a live overview, which means that it scans the device and collect all of the data used to display the overview. It does NOT, like the older versions and most other sd-ext applications, display the values that was set by the script. So if something has been changed since Mounts2SD's upstart script did it's work, this is the values displayed in the application.
So if you ever find discrepancies between the current state displayed in the overview tab and your setup from the configure tab, it can be a result of many things.
If you find discrepancies between the current state and your setup, the best thing to do is check the log. If the discrepancies was a result of an error, the log will contain details about it that could explain why.
:
:
:
:
:
:
:
:
: