Let’s talk about what can possibly go wrong when trying to port a device to an AOSP-based ROM like CM7 or otherwise.

I’ll use the Droid 3 as an example, where I’ve been banging my head against the proverbial wall of ALSA sound drivers.

I know that Arcee (of LG Optimus 3D fame — another OMAP4 device) has been using updated alsa_sound source from omapzoom to support the OMAP4 processors.  And, that’s where I started as well, since both using the same 6010 sound device (IIRC).

Enter Motorola, and their confusing ways.

Today, I was browsing through the kernel source for the Droid 3 and saw a file I hadn’t noticed before: motsnd.c

Turns out it’s a wrapper around all of the ALSA kernel functions as well as some new ones.

Yes, that’s right.  Motorola has bastardized the ALSA sound driver in the kernel to support HDMI out, as well as some other things.

So, the end result:
To get sound working correctly on the Droid 3, I’ll have to start with the current alsa_sound source from omapzoom and the alsa module out of hardware/ti/omap3 and bastardize it to match the kernel source.

Ugh.

[ Edited 11/2/2011 : Droid 3 Safestrap 1.0 Release - Read Here ]

Right now I’m putting the final touches on version 1.0 of Safestrap and I wanted to talk about the upcoming changes and how they affect YOU (if you’re using Safestrap).

As always, the idea behind Safestrap is to present a locked bootloader recovery experience which protects the phone’s original OS and the user as much as possible from SBF/fastboot restores, while letting us flash custom ROMs and keep the phone an enjoyable device.

It’s been a challenge to present to the community a DIFFERENT idea of what a bootstrap / recovery needs to be for locked phones.  And, I realized that I’m not helping either, due to some of the issues with the current Safestrap:
1. Having to constantly backup/restore while swapping from non-safe to safe system
2. Can’t flash most ROMs due to hijacks and needed init*.rc files.
3. Wasn’t backing up 1st systems for emergency restore use.

And those issues are what I focused on for this update.

Here’s a breakdown of what’s new in Safestrap 1.0:

Splashscreen Entry to Recovery:
While I’ve kept the Boot Menu -> BP-Tools method of entering recovery (for now), I added a new method of entering recovery as well.  Once installed Safestrap will display a splash screen during boot.  Besides showing you which system (non-safe or safe) you’re booting into, you can also hit the [ MENU ] key to enter recovery while that screen is being displayed.  It’s shown for about 5 seconds right now.  But, I may tweak that timing based on response from users.

No more backup/restores while swapping from non-safe system to safe system (and back again):
When using the “Toggle Safe System” function, the recovery will automatically stow away your userdata/cache and bring back previous userdata/cache from whatever system you’re moving to.
Why do this? Users were experiencing too many bootloops when switching systems if they “missed a step” or did something out of order.   And “backing up” should be just that.  A backup of a point in time which you really want to keep around, not something which you have to do all of the time and then keep cleaning up as space gets low on the SD card.
NOTE: When toggling safe system on / off remember that the stowed data is a snapshot of what you have right when you use the toggle function.

Most common ROMs should be compatible with Safestrap now without being modified:
In an effort to keep the community from getting “segmented” into having 2 flavors of  ROM .zip files, I’ve adjusted the flashing routines of recovery to fix several issues with ROMs which weren’t designed specifically for Safestrap.

1. All mount/format references to the non-safe system partition are re-routed to the safe system.  All flashing should only happen to the safe-system.
2. If the common logwrapper hijack is present in the ROM, it’s removed.
3. If there are no init.rc files for the ROM to boot off of, the stock ones are added.

This feature needs to be tested extensively and I’m sure will be tweaked as we go.
NOTE: I cannot coverup system execution commands made directly to the original system device: IE: running busybox to do something manually.  I’ll keep looking at this issue, but when I checked in all of the current ROMs, none had this issue.

Recovery will make backups now of the non-safe system (called “systemorig” in recovery lists):
Why do this? In previous versions only the safe system, userdata and cache were backed up.  Users who did have a catastrophic failure didn’t have a backup of the original system to use after SBF/fastboot.
When you select the main “restore” function for nandroids, it does NOT write over the non-safe system.  By default, Safestrap will only restore the safe system, data and cache.  You CAN restore the non-safe system file by using the “Restore (advanced)” and choosing ”systemorig” manually.

KNOWN ISSUES:

• I think this affects all recoveries for Droid 3 (Koush’s and Safestrap).  Users should dial *228 and select option 1 after switching ROMs to ensure that incoming phone calls work properly.  There’s an issue with a RIL RDS socket being created in /data/misc which isn’t being backed up by the recovery (using the new .tar format). I’m looking into ways of fixing that in Safestrap.