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.