Root Proposal/Theory for External SD storage solution on F6

[lucasmun09]

I might sound a bit impatient and I know you are also a very busy person but I really do want to try out this mod.

When you said the gta would not work very well... How so? I know all of android's GTA apk's are not able to be moved to sdcard via app2sd function built in the F6.

Also lets say I have did this mod spectacularly but I "accidentally" pull out the SD card... What will happen then? Will the phone crash? Or will it just remount the old internal storage back to what it was mounted before?

 

[Trevor Philips]

i'm just gonna reset my phone

 

[JVene]

I've had to reset about a dozen times along the way, but then I had REALLY ticked off Google's apps, so I really had to.

lucasman09 - I hear you. I had a math tutoring session tonight (my son is 12, probability isn't his thing yet), and I'm pushing to get a release build on a product I plan on putting on the app stores soon (it's still a few months).

Anyway, this is SUCH a significant improvement that I know it should be packaged and made publicly available. To that end I started putting together a Windows application for managing this on most devices (not just LG brand) - but, I'll pause and just package something simple that works on the F6.

GTA Vice city has a graphics problem. The F6 may throw it for a loop because of the GPU, the OS support for extensions or any number of other minor things GTA didn't account for. I think San Andreas can run on the F6 (I've heard that it does), so I'm going to try that one.

The NFS series had no problem, and I THOUGHT I had GTA Vice City running at one point, but I don't actually play it - my son informed me otherwise.

It wasn't a space issue in the least.

Now, when this storage solution is implemented the way I have it on my son's F6, the script which controls the mount of /data from the external card is actually run from the external card. Let me call that "external /data" - where primary storage for all of Android is from the external card. "Internal /data" would be the stock arrangement, where we have that 1.27 Gbyte partition serving all of Android.

There is a script on the INTERNAL card that starts things off, checks to see if it can mount partition 2 from the external, and if so, runs the second phase from the external card which mounts "external /data".

If the card isn't there, or another card is put in it's place, the first script will "realize" this and leave the older /data in place. That means the phone would boot with "internal /data".

There is an interesting consequence. Let's say you run the phone for weeks or months with the "external /data" mounted. During that time you load 10 apps, take 100 pictures...etc.

If you pull the external card and boot...none of those 10 apps will be there. They're on the "external /data"...only the apps installed at the time we apply this alteration will be on the "internal /data". Further, if you removed apps while the "external /data" was in place, which were also on the "internal /data"....they'll be back if you boot without the external card.

Put another way, it is like having two phones. When you boot with the "internal /data" it's like phone A..the original. When you boot with the "external /data" it's like phone B. Whatever you do to phone B doesn't affect phone A. Nor does what you do to phone A affect phone B.

You could ALSO clone the external card (using a PC and a card reader) using standard partition based backup or cloning software.

At which point you would have phones A, B and C - entirely separate from each other.

Meaning, also, you could clone an F6, and all it's installed applications (and it's contacts, email cache...everything)...to another phone.

I haven't tried it, but conceivably you'd HAVE to check that the personal info....like your own phone number...isn't cloned in the process (just fix it by editing).

I THINK (but not confirmed) that configuration information MAY be stored in a /system directory, not the "Android" /data directory. If that's true, then the configuration information would NOT be cloned by that process...I'd need to look, but it's minor.

 

[jokerpks]

I may look into rumors that 64 GByte cards work.

Yup 64 GB cards work on this phone.

 

[pressy4pie]

https://github.com/konnorrigby/Xposed

this is the xposed version of app_process. should still work the same but enables xposed modules also.

 

[Trevor Philips]

If you pull the external card and boot...none of those 10 apps will be there. They're on the "external /data"...only the apps installed at the time we apply this alteration will be on the "internal /data". Further, if you removed apps while the "external /data" was in place, which were also on the "internal /data"....they'll be back if you boot without the external card.

I personally find that pretty cool :thumbup:

 

[JVene]

https://github.com/konnorrigby/Xposed

this is the xposed version of app_process. should still work the same but enables xposed modules also.

I had contacted the author of Xpose to persuade him to include that. He replied with interest in the subject but didn't appear prepared to include this.

I'm delighted to see that added.

I'll pull this in and append a link to the app_process binary built with this as an option for the installer scripts.

I'm working on the installer scripts - got quite a distance last night but alas it's not quite ready. Script debugging / verification is actually tougher than working in C++ because the environment isn't as conducive.

I'm getting there.

 

[tony_duane]

I'd like to test this i meet the following requirements:
- rooted
- adb and USB drivers installed and working
- USB cable
- full backup of data on SD card, including any hidden directories/files
- full backup of all APK's (just in case).
please pm me with links/instructions

 

[jokerpks]

I had contacted the author of Xpose to persuade him to include that. He replied with interest in the subject but didn't appear prepared to include this.

I'm delighted to see that added.

I'll pull this in and append a link to the app_process binary built with this as an option for the installer scripts.

I'm working on the installer scripts - got quite a distance last night but alas it's not quite ready. Script debugging / verification is actually tougher than working in C++ because the environment isn't as conducive.

I'm getting there.

When are you going to release the script? I don't mean to rush you or anything just curious. Thanks for your work I really appreciate it.

 

[Trevor Philips]

When are you going to release the script? I don't mean to rush you or anything just curious. Thanks for your work I really appreciate it.

Patience is a virtue

 

[JVene]

I'd like to test this i meet the following requirements:
- rooted
- adb and USB drivers installed and working
- USB cable
- full backup of data on SD card, including any hidden directories/files
- full backup of all APK's (just in case).
please pm me with links/instructions

When are you going to release the script? I don't mean to rush you or anything just curious. Thanks for your work I really appreciate it.

Patience is a virtue

Thanks for the interest everyone.

I'm getting there.

Just a little more debug on the refinements.

For now I'm calling this thing "zinit" - that became the script name, a contraction of "zygote initialization", zygote being the name Android gives to the process of the Dalvik runtime, the Java engine of Android.

Bash (like) script programming isn't my cup of tea, but a necessary requirement of the technique. What started as a 5 line script in the experiments has become a 1500+ line script capable of dealing with a wide range of unexpected scenarios and configurations, opening the application of zinit to most Android devices.

I've banged up the F6 quite badly in the process (restored it several times). At one point I had a typical Android problem on the external installation, where FB was arguing with AVG over control of the contact database, soft booting and then soft bricking Android. I had to be sure if zinit was in any way responsible for the soft brick or the problems, and fortunately it wasn't.

However, this left the second partition on the F6 full of difficult filesystem errors which e2fsck (the ext2/ext4 file system check/repair tool) could not fix automatically. It required (as it stated to me) that I run the tool manually, to decide what to do with some files it had to fix.

In the process of this I found that zinit became a tool for recovery from the soft brick, and set about the task of implementing features which aid in the repair.

It appears many of us can't know when soft bricking the phone is because of an application gone awry, or from soft-reboots causing filesystem corruption which grows to the point that Android gets locked up trying to boot. We're locked out of running e2fsck manually during boot on a stock device with a locked bootloader. zinit now opens that ability up.

I was able to repair the soft-bricked installation of Android without resorting to a restore or hard reset.

An interesting side point is that zinit can operate without root installed. You still have to be rooted to install zinit, but then the su application could be removed and zinit will still operate. This is because after installation, the boot scripts executed by this approach are granted root privilege by init when it launches zygote by the very nature of Android's design, even if a root application is not present. This does not grant root privilege to anything else (it can't, because the root privilege is only operational during the boot), but it means those things zinit must be 'root' to do can be done even without root still installed. I've not verified that busybox dependency is entirely cleaned away from the script...but I'll let that slip for the moment to get this out the door.

The exception being manual file system checks - for that one must have root privilege, which could be a temporary installation, unless the owner put the external SD card into a PC with either Unix or Linux (even in a VM) performing the file system check.

There is also a feature to configure the boot datasource. Datasource is defined as the source of the /data directory. By setting a value, one can choose to boot the factory (default) way, or boot to any suitable datasource from the external card. I used this feature in a primitive form in my recovery and formalized it as a result. At one point I had 4 different "personalities" on the external card, one of them a copy of the factory version of /data, another a backup of my "son's" installation and backup of my "development" installation. Think of each as a separate installation of Android.

When my development installation was soft-bricked, I simply set the option to boot the factory backup, rebooted and operated normally. I then switched to my development backup installation, rebooted and operated normally. Then I booted the factory (default) way, performed file system check maintenance on the external card, restored only the missing files in the development installation from backup, set the configuration to boot the development system (previously soft-bricked), and upon reboot - everything was normal.

The entire series of events from the start of fixing the soft-brick to the final reboot into the previously soft-bricked development installation (through two reboots of two different personalities and the factory boot) took under 12 minutes.

That did require that I adjust the boot configuration from an ADB shell.

I have a plan to implement a feature in zinit that monitors boot cycles, to determin if Android is soft-bricked, so as to automatically fall back to other boot datasources in order to get the phone working again (it would take a few reboot attempts to trigger) - but that can wait a bit.

Ok, back to debugging....hitting the final stretch to a beta now.

 

[Trevor Philips]

Thanks for the interest everyone.

I'm getting there.

Just a little more debug on the refinements.

For now I'm calling this thing "zinit" - that became the script name, a contraction of "zygote initialization", zygote being the name Android gives to the process of the Dalvik runtime, the Java engine of Android.

Bash (like) script programming isn't my cup of tea, but a necessary requirement of the technique. What started as a 5 line script in the experiments has become a 1500+ line script capable of dealing with a wide range of unexpected scenarios and configurations, opening the application of zinit to most Android devices.

I've banged up the F6 quite badly in the process (restored it several times). At one point I had a typical Android problem on the external installation, where FB was arguing with AVG over control of the contact database, soft booting and then soft bricking Android. I had to be sure if zinit was in any way responsible for the soft brick or the problems, and fortunately it wasn't.

However, this left the second partition on the F6 full of difficult filesystem errors which e2fsck (the ext2/ext4 file system check/repair tool) could not fix automatically. It required (as it stated to me) that I run the tool manually, to decide what to do with some files it had to fix.

In the process of this I found that zinit became a tool for recovery from the soft brick, and set about the task of implementing features which aid in the repair.

It appears many of us can't know when soft bricking the phone is because of an application gone awry, or from soft-reboots causing filesystem corruption which grows to the point that Android gets locked up trying to boot. We're locked out of running e2fsck manually during boot on a stock device with a locked bootloader. zinit now opens that ability up.

I was able to repair the soft-bricked installation of Android without resorting to a restore or hard reset.

An interesting side point is that zinit can operate without root installed. You still have to be rooted to install zinit, but then the su application could be removed and zinit will still operate. This is because after installation, the boot scripts executed by this approach are granted root privilege by init when it launches zygote by the very nature of Android's design, even if a root application is not present. This does not grant root privilege to anything else (it can't, because the root privilege is only operational during the boot), but it means those things zinit must be 'root' to do can be done even without root still installed. I've not verified that busybox dependency is entirely cleaned away from the script...but I'll let that slip for the moment to get this out the door.

The exception being manual file system checks - for that one must have root privilege, which could be a temporary installation, unless the owner put the external SD card into a PC with either Unix or Linux (even in a VM) performing the file system check.

There is also a feature to configure the boot datasource. Datasource is defined as the source of the /data directory. By setting a value, one can choose to boot the factory (default) way, or boot to any suitable datasource from the external card. I used this feature in a primitive form in my recovery and formalized it as a result. At one point I had 4 different "personalities" on the external card, one of them a copy of the factory version of /data, another a backup of my "son's" installation and backup of my "development" installation. Think of each as a separate installation of Android.

When my development installation was soft-bricked, I simply set the option to boot the factory backup, rebooted and operated normally. I then switched to my development backup installation, rebooted and operated normally. Then I booted the factory (default) way, performed file system check maintenance on the external card, restored only the missing files in the development installation from backup, set the configuration to boot the development system (previously soft-bricked), and upon reboot - everything was normal.

The entire series of events from the start of fixing the soft-brick to the final reboot into the previously soft-bricked development installation (through two reboots of two different personalities and the factory boot) took under 12 minutes.

That did require that I adjust the boot configuration from an ADB shell.

I have a plan to implement a feature in zinit that monitors boot cycles, to determin if Android is soft-bricked, so as to automatically fall back to other boot datasources in order to get the phone working again (it would take a few reboot attempts to trigger) - but that can wait a bit.

Ok, back to debugging....hitting the final stretch to a beta now.

Thanks for taking your time on this JVene! Once you're done, This + overclocking = Badass F6

 

[JVene]

Thanks for taking your time on this JVene! Once you're done, This + overclocking = Badass F6

Overclocking!?

Hmmm....I shall have to give that some attention next!

 

[Trevor Philips]

Overclocking!?

Hmmm....I shall have to give that some attention next!

http://androidforums.com/metropcs-o...-kernel-ms500-freedom-kernel-overclocked.html

 

[pressy4pie]

Overclocking!?

Hmmm....I shall have to give that some attention next!

GameTheory and I already have an overclock kernel out, but it is a boot.img so it needs loki. and some users have a difficult time using that because of the tmo/metro versions..

 

[Trevor Philips]

Hey Jvene, stopping by to ask how this is going

 

[tony_duane]

I can't wait till this is packaged and completed the anticipation is agony...

 

[Trevor Philips]

I can't wait till this is packaged and completed the anticipation is agony...

i feel you lol, i dont even feel like i can use the f6 without this

 

[legacybeats]

After researching, and much trial and error, it's apparent that all mods are essentially temporary to say the least...

 

[legacybeats]

Btw I'm new here, you guys have truly helped out allot, couldn't help but become a part of the community

 

[hubsabubs]

Ummm, after the Kit Kat update, I assume this phone will then be back shelved and not slated for anymore updates, as that is a major update for us.

This is my solution, and I explained how I do this on a thread in the Coolpad Quattro 4G section because that phone had terrible internal memory. Also for some reason these phones being put out today are locked down and they are getting good at doing it. If you root the phone, good luck getting an OTA update to work properly after that. My Quattro is still OTA Update stuck and I still can't get the damn thing to go away.

My plan, wait patiently for the Kit Kat update, then backup my phone. Root my phone, then use Link2SD, and Mini Partition Wizard Tool to format a 32gb SD Card with a 16gb EXT2 partition and install Link2SD on my phone. It attaches itself to the 16gb partition and then to the 1.1gb internal memory and pairs them leaving me with 17gbs of internal storage and 16gb of external memory. Set a few settings and everything then after pairs with Link2SD automatically. In my opinion all these "mods" and "Band-Aid" fixes are unnecessary. To much work for such a simple solution.

Sidenote on something mentioned above. I also read that you can partition a 64Gb SDCard with a 32Gb Ext2 partition and a 32Gb Fat32 Partition and utilize both, the phone does support a 32Gb Card and being its the only Fat32 partition the phone thinks its the only memory available and leaves you with 33Gb internal memory via Link2SD as well.

 

[Trevor Philips]

Btw I'm new here, you guys have truly helped out allot, couldn't help but become a part of the community

Welcome

 

[TehFlash]

Anything new on a solution or anything?

 

[hubsabubs]

Any possibility on being able to partition a 16gb sdcard into 2 8gb fat32 partitions and use the internal/external swap method? Swap the internal with 1 of the 8gb partitions and still use the other 8gb partition as a external storage location?

 

[tony_duane]

I've got dual partitions on my sd card, I have links2sd and I have the swap installed. I still have an issue, because despite all the room /data gets full rather quickly even with plenty of space elsewhere. It is an incomplete solution