[G Tablet General] K J Rad:
With the large influx of new users due to the Woot deal and recently lowered prices from multiple vendors I've noticed a cookie cutter trend toward dealing with problems posted in these forums. In many cases symptoms are overlooked, known issues are ignored and all too often a "Nuclear Option" is applied to solving problems. We're constantly advising people to take it slow, read and learn before they mod anything but we jump right in and push them to reflash ROMs or even nvflash before we're even sure what has gone wrong.

I'm not suggesting that we should abandon the tools we've come to know will help us, just that perhaps we should start to think about less invasive methods to solve our problems. Rather than immediately suggesting a repartitioning because someone used the word "Loop" in the description of their problem, we should look at all the symptoms as well as any actions already taken by the user and take smaller steps focused on solving the issue.

For example: In my recent research I've identified three types of "Boot Loops" that I've been able to reproduce on my tablet.

The first and most difficult to address is the "APX Boot Loop." I was able to create this issue by nvflashing a corrupted image to my tablet. The most obvious symptom is the screen will either show the boot image or just the backlight and then hang or quickly go to black. This will always require the use of advanced tools (nvflash) to address.

The other two are similar to each other with subtle differences. I refer to number two as "Non-APX Boot Loop." For testing, I created a corrupted system image that would fail to load by corrupting some system data with a hex editor. In this case you'll see the screen switch from the initial boot image to the gTablet screen and back. This is an indication that the system software is failing to load relatively early in the boot process. I've successfully treated this type of loop with a Cache/Dalvik/Data wipe and/or re-installation of the currently installed ROM which can often be done with an update.zip applied through standard recovery from a MicroSD. With some experimental ROMs there were some complications in very rare cases that required more intrusive methods. This might have been due to a mismatch in the bootloaders I was using during testing (I'm still researching this).

The third type I refer to as "System Loop." The visual symptom for this would be the boot animation hanging or looping just prior to displaying the home screen or launcher. I was able to recreate this problem by introducing corrupted system data into a few different system apps. I was able to "cure" this problem with simple data wipes or even more surgically by wiping specific directories thus leaving user installed apps and data intact. I have successfully done this with a script in an update.zip applied through standard recovery from a MicroSD.

One thing that became clear in the testing was that doing a Cache/Dalvik/Data Wipe prior to installing new ROMs was nearly 100% effective in preventing Non-APX Boot Loops and System Loops. Making that a standard practice would likely reduce the occurrence of these issues dramatically.

The main points here are that we're often applying the most invasive and complex recovery procedure we have when it might not be necessary at all and many of these problems could have been prevented with better practices.

Once I've refined my "Surgical Delete" script a bit more I'll post it up here for others to try if they like.