Flashing a Sprint Nexus S 4G to Verizon

I originally wrote the following post in July 2012 to document how to fully flash a Nexus S 4G from Sprint to Verizon Wireless, but never got to publishing it. I have long since switched away from Verizon Wireless and no longer own any of the phones mentioned, and decided to publish it for what it’s worth.

If you’re interested in the high-level view of how CDMA phones are programmed, check out my previous article Carrier Programming on CDMA Android Phones.


This is a guide for flashing a Sprint Samsung Nexus S 4G to a standard Verizon monthly plan, and voice, texting and 3G data will all be fully functional. This method will likely also work on many other phones, especially Samsung ones, and should theoretically work just file on any ROM as well.

Note that this procedure entails ESN cloning, which may be illegal in your region. Please make sure you have an understanding of all applicable laws before proceeding. The author of this guide cannot be held responsible for any legal infractions that may ensue. Finally, you are solely responsible for any consequences of your actions as a result of following this guide. While I believe it to be quite safe, I cannot guarantee you that this process will not brick your devices or start a zombie apocalypse.

Requirements and Setup

We will need the following before starting:

  • A currently active Verizon Wireless Android phone and plan. Please beware that not all phones will work; many phones do not allow us to extract all the information we need for this process. For instance, my Motorola Droid 3 did not work, and I had to purchase and activate an HTC Incredible for this. This phone will be our donor phone.

  • A rooted Samsung Nexus 4G.

  • A computer running a recent version of Windows, with at least 2 USB ports.

  • 2 MicroUSB cables.

In addition, we need the following software:

  • USB diagnostic drivers for your donor phone. These vary by manufacturer and their configuration may be quite complex; search online for how to set up yours. For HTC phones, download and install HTC Sync from HTC’s website (archived here).

  • USB diagnostic drivers for the Nexus S 4G. The easiest way is to download and install PdaNet (archived here). We don’t actually need the functionality of PdaNet, but it happens to bundle the drivers we need. Select Samsung when prompted for the manufacturer of our phone.

  • QPST and QXDM (archived here). These are internal Qualcomm tools; we will use them to clone the MEID of the donor phone.

  • DFS (archived here). This is a third-party tool for working with CDMA phones. The demo version will suffice.

Step 1: Preparation

First, make sure the donor phone is fully activated and that calls, text and data are all fully functional.

Now, find the HEX MEID of the donor phone. On the HTC Incredible, this can be found under Settings → About Phone → Phone Identity. On most Android phones, this is under Settings → About Phone → Status. It is also usually printed on a label underneath the phone battery. This should be 14 digits and usually begins with A00000.

Now put the donor phone in airplane mode.

We will next connect both phones to the computer in diagnostic mode.

  • On the Nexus S 4G, dial *#*#8778#*#*, then select MODEM under USB. Connect the Nexus S 4G to the computer. If drivers were installed correctly, you should now see a SAMSUNG Mobile Modem Diagnostic Serial Port (WDM) under Ports (COM & LPT) in Windows’s Device Manager. Note down the port number of the Nexus S 4G; we will assume COM4 for convenience.

  • On the HTC Incredible, dial ##3424#, hit Call, connect it to the computer, then follow the instructions in this thread with Device Manager. If everything goes well you should now see a HTC Diagnostic Interface under Ports (COM & LPT) in Device Manager. Note down the port number of the HTC Incredible; we will assume COM11 for convenience.

After confirming that both phones show up under Ports (COM & LPT), run QPST Configuration and hit Add New Port…. You should see both phones on the left. Select one and hit OK. Then repeat for the other phone.

Step 2: Cloning

We will now clone the MEID of the donor phone onto the target phone. Open QXDM Professional. Select Options → Communications…. For Target Port, select the port corresponding to the Nexus S 4G, say COM4, and hit OK. Then in the text box labeled Command, type the following:

Password 01F2030F5F678FF9

Hit Enter. You should see Password Result = Correct at the bottom of the Command Output window.

Now in the Command text box, type the following, replacing <MEID> by the hex MEID of the donor phone:

RequestNVItemWrite meid 0x<MEID>

Hit Enter. You should see it repeat back the MEID to you. Type RequestNVItemRead meid followed by Enter to make sure the write happened.

Close QXDM Professional and reboot the Nexus S 4G. Rebooting the target phone after writing a new MEID is essential! If prompted, do NOT go through the activation process on the Nexus S 4G. Just select Skip when possible.

Step 3: Reset SPC

In order to program the Nexus S 4G, we need to obtain or reset the SPC code (also known as the MSL) of the phones. If you already know the SPC code for your phones and would rather not reset the SPC code, you can skip this step.

Open QXDM Professional again. Go through Options → Communications and make sure the Target Port is still COM4. Hit OK. In the command text box, type the following two lines, each followed by an Enter:

Password 01F2030F5F678FF9
RequestNVItemWrite sec_code 000000

If this is successful, the SPC on the Nexus S 4G will have been reset to 000000. Repeat for the donor phone (in our example, on COM11).

Close QXDM Professional after done. All QPST / QXDM programs must be closed before proceeding, or DFS will complain.

Step 4: Programming CDMA Chipset

Launch DFS. Click Ports on the top left. In the dialog box, double-click on each port representing our phones, in our case, COM4 and COM11, and close the dialog box. Now make sure the SPC text box above reads 000000 (or if you chose not to reset the SPC, whatever your SPC is). Type 01F2030F5F678FF9 into the Pwd text box.

Step 4.a: Basic CDMA settings

Let’s now copy basic CDMA settings from the donor phone to the target phone. In the drop-down menu next to Ports, select the donor phone (COM11). Switch to the Programming tab and the NAM tab under it. Click the SPC and Pwd buttons to send the SPC and NV password to the phone to unlock it. Then hit Read beneath Network identification. The text fields below should be populated by information from the donor phone. Now select COM4 in the drop-down menu next to Ports, click SPC and Pwd, then click Write beneath Network identification.

Step 4.b: PRL

Now, let’s copy over the PRL (or Preferred Roaming List - essentially a database of tower locations). Again, select COM11 under Ports and click Read under PRL towards the right. Then select COM4 under Ports and click Write under PRL.

Step 4.c: 2G Data settings

Now go to the next tab, Data. Select COM11 and hit Read. Switch to COM4 and hit Write. If you observe errors in the log window in the bottom, and / or no information shows up in the Pwd boxes under PPP and HDR AN Long, your donor phone doesn’t support the extraction of some data passwords, and you will have to try a different donor phone.

Step 4.c: 3G Data settings

We do the same with Mobile IP. Select COM11 and hit Read. Switch to COM4 and hit Write. Then hit Write current profile settings. Again, if you encounter errors, or no information shows up under AAA Shared secret and HA Shared Secret, you will have to try a different donor phone.

Finally, we need to copy over a file containing a secret key used to establish a 3G connection. Go to the EFS tab towards the top. Select COM11 and hit Read EFS. Click the "+" sign of the root folder on the left and then the "+" sign next to the DMU folder and you should see a file called 10.key. Right-click on this file and hit Save…. Save this file somewhere on your hard drive. Now switch to COM4 and hit Read EFS again. Select the root folder on the left, type /DMU under Path (57 max) on the right and hit Add Item to create a folder named DMU on the Nexus S 4G. Then select DMU on the left, click on the check box named I want to add file from PC, and select the 10.key file we just saved. Then hit Add Item to upload the 10.key file to /DMU/10.key.

The programming is now done. Close DFS, select OK and OK again when prompted whether to send a mode reset to the phone. The Nexus S 4G will now reboot.

Step 5: Programming Android

We will now modify some Android system files to Verizon settings. This step will need to be repeated whenever you flash a new ROM on the Nexus S 4G in the future.

1-click programming app

I have built a 1-click Android application that automates this step; you can find it here. It requires root as it will need to modify system files. Install the application and click the button in the middle. When the process finishes, you will be prompted to reboot. Simply reboot your phone and you’re all set; you may uninstall the app, or you could keep it around for when you update to a new ROM.

If the 1-click app does not work for you, or if you want more control over what it does, follow the steps below. You do not need to do any of the following if you already used the app above.

Step 5.a: Fix voice calling

This is required to enable calls on Verizon. On the Nexus S 4G, connect to WiFi and install ES File Explorer from the Play Store. Then go to Menu → Settings and check Up to Root, Root Explorer, and Mount File System. Allow it to use superuser privileges if asked. Then navigate to /system and open build.prop with ES Note Editor. Find the following two lines:


Change them to read:


Then add a line below (or anywhere in the file) that says:


Hit Menu → Save and then Back to exit.

Step 5.b: Fix roaming

This step tells Android to treat the Verizon network as the home network. It sets the roaming status to "Not roaming", removes the triangular roaming indicator in the status bar and changes the displayed name of the current network to "Verizon Wireless".

Now navigate to /system/framework and copy framework-res.apk onto your computer - you can use adb or email it to yourself or whatever (you have to copy it to the internal SD card before you can email it though). Once on the computer, rename it framework-res.zip (yes, an APK is just a zip archive) and use your favorite program to replace the file res/xml/eri.xml inside it with the one at this link. Now rename it back to framework-res.apk, copy it back onto the Nexus S 4G (using adb or whatever) and use ES File Explorer to overwrite the existing /system/framework/framework-res.apk with it.

Step 5.c: Add Verizon APNs

This last step sets up Verizon APNs that enable web and MMS. Use ES File Explorer or any other tool to replace /system/etc/apns-conf.xml with the one at this link.

Step 6: Reboot & PROFIT

The Nexus S 4G should now be a fully functional Verizon Wireless phone. If you are curious about what each of the steps means, you’re welcome to check out my previous article Carrier Programming on CDMA Android Phones for a high-level view of how CDMA phones are programmed.

While your mileage may vary, I hope the above information have been of help. Since I no longer use Verizon Wireless and no longer own any of the phones mentioned above, please take all this information with a grain of salt.

Good luck, and happy hacking!

Disabling Screen-Off Animation In Android

I am impressed by the amazing progress Android’s UI has made since its inception. With each iteration, likewise in software as in hardware, its usability and aesthetics have steadily improved to the point where I can now confidently buy one for my mom to replace the iPhone I recommended to her only last year.

On the other hand, one particular "feature" I intensely dislike is the screen-off animation that emulates the brief white flash you see when an old CRT TV monitor is powering off. Introduced in Gingerbread (2.3), it seems not to bother most people as much as it bothers me, and even seems to be quite popular (e.g., this thread).

I was glad to learn though that a number of people find it as annoying as I do, for example in this thread and this bug.

As a CyanogenMod fan, I was quite happy with the straightforward checkbox in the Settings app in CyanogenMod 9 that toggled whether to play this animation. In CM10, this option was removed, but there was an easy hack involving changing window animation scale in the developer settings, as explained in the second link above.

So when I updated to CM10.1 M1, I was very unpleasantly surprised to find that this hack does not work any more either. I tried to immediately downgrade to CM10, but then discovered that doing so requires a full data wipe (of course…). A quick search pulled up this thread which proposes a simple prop edit, but the following posts in the thread suggest mixed results.

So, stuck with CM10.1, and really disgusted at this turn of events, I finally decided to put on my hax0r gloves and get this annoying "feature" out of my face once and for all.

Poking Around

I went to androidxref.com and started searching the Android source code for "screen off animation". (OK, I actually started out with grep, but it didn’t take me long to realize androidxref.com was about sixty million times faster - it’s really pretty cool.)

I quickly found why changing the window animation scale in Jelly Bean 4.1 (and CM10) disables the screen-off animation. The two snippets of of code implementing this behavior are at line 470 and line 2228 of PowerManagerService.java.

In Jelly Bean 4.2 (and CM10.1), however, these parts of the code have been completely refactored. The snippet of code that launches the screen-off animation is now found at line 704 of DisplayPowerController.java. Note that this new DisplayPowerController class has been factored out of the old PowerManagerService class, and both have moved into a separate power sub-directory.

The Hacking

Disclaimer: I am NOT responsible for anything that happens to your phone or you or your house or your relationship with your wife if you follow the instructions down here. If you don’t know what you’re doing and are scared of bricking your phone, just give up and go watch Superbowl. Please.

What did not change, I found, is that this code gets packaged into /system/framework/services.jar on the Android system. So, let’s take a look at this file as found in the CM10.1 image on my phone:

# Copy services.jar from phone to current directory.
adb pull /system/framework/services.jar
# Disassemble.
apktool d services.jar

(apktool is a tool that extracts and disassembles Android APK/JAR files, and is available for Linux, Windows and OS X.) This produces a directory, services.jar.out, which contains the disassembled code of services.jar we just pulled from a connected phone. I dived into the DisplayPowerController code and edited the else clause at line 704 to essentially just say setScreenOn(false); directly instead of running the animation first. If you look at the dissassembled code, you’d realize Dalvik bytecode is really quite readable and easy to hack, especially since the line number hints allow you to directly map a line in the Java source code to the corresponding Dalvik instructions. I just had the Java source file on androidxref.com open in a browser tab for reference and killed instructions line by line. You can download my patch here and apply it like this:

patch -d services.jar.out -Np1 < path/to/disable_screen_off_animation.patch

(For CM10.1 nightlies (after the MR1.1 merge) and CM10.1 M2, use this patch instead. The same piece of code was shuffled around to line 777. For CM10.1 M3, use this patch instead.)

Now re-assemble the code and push it back on to the device:

# Re-assemble modified sources as services-mod.jar.
apktool b services.jar.out services-mod.jar
# Copy services-mod.jar to /sdcard/ on phone.
adb push services-mod.jar /sdcard/
# Remount /system partition as read-write in order to modify it.
adb shell su -c 'mount -o rw,remount /system'
# Overwrite original services.jar on phone with services-mod.jar as root.
adb shell su -c 'cp /sdcard/services-mod.jar /system/framework/services.jar'
# Reboot phone for this to take effect.
adb reboot

When the phone reboots, it will say Android is upgrading and will rebuild Dalvik cache for each application, so it might take a while. But hey, it’s worth it.

Parting Words

The final product, if you just want to replace the services.jar on your phone, is here:

  • CyanogenMod 10.1 M1 - tested on Galaxy Nexus (maguro) and Nexus S (crespo), should work on other phones as well (can’t promise - let me know):

  • CyanogenMod 10.1 M2 - tested on Galaxy Nexus (maguro), should work on other phones as well (can’t promise - let me know):

  • CyanogenMod 10.1 M3 - tested on Galaxy Nexus (maguro), should work on other phones as well (can’t promise - let me know):

  • CyanogenMod 10.1 RC1 - tested on Galaxy Nexus (maguro), should work on other phones as well (can’t promise - let me know):

  • Stock 4.2.2 (takju/JDQ39) - for "takju" factory image from Google

  • Stock 4.2.2 (yakju/JDQ39) - for "yakju" factory image from Google

Apply the services-mod.jar to your phone like this (obviously assuming you have adb working and root):

# Copy services-mod.jar to /sdcard/ on phone.
adb push services-mod.jar /sdcard/
# Remount /system partition as read-write in order to modify it.
adb shell su -c 'mount -o rw,remount /system'
# Overwrite original services.jar on phone with services-mod.jar as root.
adb shell su -c 'cp /sdcard/services-mod.jar /system/framework/services.jar'
# Reboot phone for this to take effect.
adb reboot

Or, I suppose, you could just use ES File Explorer with root mode enabled, mount /system as read-write and copy the file to /system/framework/services.jar on the phone.

Note that a reboot is needed after you replace the services.jar whatever you do, and upon the first reboot the "Android is upgrading" dialog will pop up.

Android Rooting: A Developer's Guide

First things first — this is not about how to apply a rooting method, e.g., a one-click-root, to an Android device. Rather, it is about how one could go about developing a rooting method for a device that no one has rooted before, and is told through my experiences with rooting a particular device — the Barnes & Noble Nook Tablet 8GB. For context, you can read my original thread "Root for Nook Tablet 8GB (w/ Android Market) on XDA-Developers where I published my rooting method, which has reached a download count of — wait for it — OVER NINE THOUSAND!!!

For an overview of how rooting works behind the scenes, you may want to read my previous article How Rooting Works - A Technical Explanation of the Android Rooting Process as background.

Sometime in late February (2012), on a visit to to a Barnes & Noble store in Boston, I bought the then freshly released Nook Tablet 8GB entirely on impulse for $199. Being the hax0r that I am, the first thing I did when I got home was to try to root the device. It came as a nasty surprise, therefore, when I discovered that no one had yet succeeded in rooting the device. All I could find was a YouTube video showing that the existing rooting method for its cousin, the Nook Tablet 16GB, did not work. After waiting for a few days, the absolutely pathetic app store and handicaps instituted by B&N finally motivated me to develop a rooting method for the device myself.

The Plan

So, how do you go about rooting an Android device? As I explain in my previous article, rooting is basically a two-step process:

  1. Find exploit that allows execution of arbitrary code as root

  2. Use exploit to install su (with SUID bit set) and Superuser.apk as root

After su and Superuser.apk are installed correctly, apps that require root (such as Titanium Backup or AdAway) will invoke su to run code as the privileged user.

The Process

There are many generic or device-specific exploits that a hax0r may leverage to achieve privileged execution of arbitrary code. I would again refer you to this excellent presentation on various Android root exploits that have been or may still be used for this purpose.

However, none of these methods that I knew of could work on the Nook Tablet, which is probably one of the most locked-down Android ROMs out there:

  • Bootloader is locked.

  • ADB is disabled, and cannot be enabled from the UI.

  • Installing non-market apps (raw APKs) is disabled, and cannot be enabled from the UI.

  • No access to Google Play / Android Market (or any Google Apps).

This rules out 1) root APKs and 2) the majority of exploits out there that require executing commands over ADB. It means that one cannot run any code on the device that does not come from B&N period.

But of course there was another way in. Somebody on XDA-Developers had discovered that the bootloader of the Nook Tablet supported booting off an Android system located in partition images stored on an external microSD card. This mechanism is probably used to repair corrupted system partitions by B&N customer support.

The solution, then, is clear: we create dummy system partition images that, instead of booting an Android system, installs su and Superuser.apk into the "normal" Android system in internal flash memory. More concretely, I modified the system initialization file inside the initrd inside the boot partition image to invoke a custom script that copied the relevant files into the system partition in the internal flash memory.

I based my work on bauwks’s 2nduboot images and used abootimg to unpack files in the boot partition image boot.img:

# Extracts files in the boot partition image into the current directory.
abootimg -x ./boot.img
# Extract files in the initrd cpio archive into the folder ./ramdisk/
aboot-unpack-initrd ./initrd.img

I changed the system initialization file init.omap4430.rc in the initrd to mount the system partition of the internal flash memory at /foo rather than /system, because later system initialization steps attempt to remount /system as read-only and so on, and for some reason I could not disable that behavior:

on fs
    mkdir /foo
    mount ext4 /dev/block/platform/mmci-omap-hs.1/by-name/system /foo wait

I added the following to the system initialization file init.rc in the initrd to start my rooting script:

service root_script /sbin/busybox ash /assets/run.sh

My rooting script, which I place in the directory assets in the initrd, installs not only su, but also Google Play and other Google apps which are missing from the Nook Tablet ROM:

# Install su and Superuser.apk
/sbin/busybox cp /assets/su /foo/bin/
/sbin/busybox cp /assets/su /foo/xbin/
/sbin/busybox chmod 06755 /foo/xbin/su
/sbin/busybox chmod 06755 /foo/bin/su
/sbin/busybox cp /assets/Superuser.apk /foo/app/

# Install Busybox.
/sbin/busybox cp /sbin/busybox /foo/xbin/
/sbin/busybox chmod 06755 /foo/xbin/busybox

# Install Google Play and other Google apps.
/sbin/busybox cp /assets/*.apk /foo/app/
/sbin/busybox cp /assets/com.google.android.maps..xml /foo/etc/permissions/
/sbin/busybox cp /assets/com.google.android.maps.jar /foo/framework/
/sbin/busybox cp /assets/libvoicesearch.so /foo/lib/

# Done.
/sbin/busybox mount -o ro,remount /foo

In accordance with the above script, I had placed all assets in the assets directory inside the initrd, and the Busybox binary in sbin inside the initrd. With all changes done, I pack everything back into a new boot.img:

# Build initrd cpio archive
abootimg-pack-initrd initrd.img.new
# Build new boot.img using previously extracted components
abootimg --create boot.img.new -f ./bootimg.cfg -k ./zImage -r ./initrd.img.new

Then I replace the boot.img on the SD card image with my boot.img.new, and the rooting method is done.

Final words

The actual process, of course, was much, much more painful. The Nook Tablet’s bootloader is very picky; some microSD cards just won’t work, there is a file size limit on boot.img, etc.. It was also after much frustration that I discovered the mount-to-/foo trick. And I could not even keep track of how many factory restores I had to perform on the device to undo bad modifications. But it was still a lot of fun, and the euphoria at the end and the feeling of accomplishment when reply posts started rolling in and random people were donating $5 as a token of their appreciation could not be overstated.

Good luck rooting!

Carrier programming on CDMA Android phones

Have you ever wondered how CDMA phones are programmed to a specific carrier for voice calls, SMS and data?

In the U.S., all major CDMA carriers operate on the same frequencies, which means that there is no inherent difference in hardware between phones sold by any of them, and that theoretically there is no reason why a Verizon Wireless phone cannot work on Sprint or MetroPCS or Virgin Mobile or Boost Mobile, for example. Unlike GSM phones with swappable SIM’s, however, a CDMA phone sold in the U.S. is typically locked to a particular carrier; so how is that done?

I was recently able to figure out the answer to this question when I successfully flashed a CDMA phone from Sprint to Verizon (an exploit documented in Flashing a Sprint Nexus S 4G to Verizon). As I have not been able to find a compilation of this information elsewhere, I am writing up this document in the hope that it will help others with flashing phones or porting ROMs to different carriers.

Note that this information is based on my research with the Jelly Bean (4.1 & 4.2), ICS (4.0) and Gingerbread (2.3.4) versions of Android and two major U.S. CDMA carriers, Verizon Wireless and Sprint. Hence, it may not be applicable to other phones or carriers; in particular, the section about CDMA chips do not apply to CDMA phones that require a SIM card, such as some Verizon Wireless LTE phones. In such cases, your comments and insights are welcome.

Finally, a disclaimer: I have no formal understanding of any of the intricacies of CDMA technology and therefore cannot guarantee the correctness or accuracy of this information. Use it at your own risk. I cannot be held responsible for any damage or legal consequences resulting from or related to the application of this information.

At a high level, there are two places where carrier information is stored on a CDMA Android phone: inside the CDMA chip (radio), and in Android OS system files.

Programming the CDMA chip

Every CDMA phone (obviously) has a CDMA chip (radio). This chip is responsible for carrying out voice calls and transferring data over 2G/3G, and in order to do that, it needs to know stuff like what phone number it represents, what towers to connect to, what account name to bill the 3G connection to, etc.. All of this information is stored directly inside the chip (unless you have a Verizon Wireless LTE phone with a SIM card), and not on any file system controlled by the OS; this is why even after a factory reset (which formats the internal flash file system) these settings persist. It is (I believe) not possible to change the information stored on the CDMA chip from the OS itself; instead, carriers provide a special number (e.g., *228 for Verizon Wireless) that, when called, will transfer the information to the chip. This is typically called "programming" the phone by U.S. carriers.

So what information exactly is stored inside the CDMA chip? Here’s an incomplete list:

  • MEID: Unique serial number of the phone. This is like the MAC address of an ethernet / WiFi card in that it is the sole identifier of the CDMA chip. It is what carriers use to connect phone calls, deliver SMS’s, blacklist stolen phones, etc.. A fatal flaw, however, is that it is actually possible to modify (flash) the MEID of many, but not all, CDMA chips. If you flash the MEID of phone A onto phone B, the carrier network has no way of distinguishing between phone A and phone B, and phone B is able to make and receive calls, send and receive messages etc. as phone A. Unsurprisingly, this is illegal in many countries, including the U.S., and as such I will not discuss it here.

  • Phone / account numbers: known as MDN and MIN, these store the phone and account numbers associated with the phone.

  • 2G/3G data account information: user names and passwords used to connect to data services. Some carriers have stronger (harder to impersonate) authentication systems than others; for instance, Verizon Wireless requires two encrypted passwords and a secret key in the EFS file system on the CDMA chip; Boost Mobile only requires two passwords; while MetroPCS simply accepts the SPC/MSL code (see below) as the password. Note that 2G and 3G are unrelated systems with independent authentication; a phone can have valid 3G credentials and thus connect to 3G while being denied a 2G connection.

  • PRL (Preferred Roaming List): a list of towers the phone can connect to. This is of course carrier- and location-specific. In some cases, updating the PRL (by calling a special number) can improve reception and save battery when the phone moves to a new geographical area; see Verizon Wireless’s explanation, for example.

Software such as CDMA Workshop, DFS, QXDM/QPST can be used to read / write information stored on a CDMA chip from a computer. Often, however, a 6-digit passcode known as the SPC code or the MSL code is required. This SPC/MSL code, again stored inside the CDMA chip, is either randomly assigned by the carrier (this is the case for Verizon Wireless and Sprint) or deterministically computed based on the MEID (MetroPCS). In the former case, there are a variety of tricks for retrieving the SPC/MSL code from the phone itself,; Google is your friend there. In the latter case, there are sites for computing the code from the MEID. Once it is known, the SPC/MSL code can be changed to any 6-digit number; some phones may even allow you to overwrite the SPC/MSL code without knowing it first.

Carrier configuration in the Android OS

To figure out what system files in the Android OS contain carrier information, I inspected source code and images of ROMS for the Samsung Galaxy Nexus (Sprint and Verizon Wireless), the Samsung Nexus S 4G (Sprint), the HTC Incredible (Verizon Wireless), and the Motorola Droid 3 (Verizon Wireless). I found three places that store carrier-specific information.

The first is /system/build.prop. Sprint phones contain the following lines:


while Verizon Wireless phones contain the following lines instead:


These settings apply to phone calls. If one adopts the Sprint configuration on a Verizon Wireless phone, for example, the phone would ring very briefly on a call, but would be unable to actually make or receive calls. The ro.cdma.homesystem specifies a list of indices into the PRL that represent "home" or non-roaming networks.

The second configuration file is eri.xml, which is compiled into the file /res/xml/eri.xml inside the system package /system/framework/framework-res.apk on an Android system. This file tells the OS what it needs to display about a particular network (as an index into the PRL); for an example, take a look at the stock eri.xml for the Sprint Galaxy Nexus or the CyanogenMod eri.xml for the Verizon Wireless Galaxy Nexus. In particular, this file instructs the OS whether to consider a network (tower) to be roaming (so whether a roaming icon is displayed), and gives the name of the network (tower) to be shown in the UI. It must be stressed that this file has no functional effect; all it changes is how the OS displays information about networks. Since APK packages are just ZIP archives, it is easy to replace the +eri.xml within to change roaming and name settings for networks; note, however, that the file inside the APK is not a plain text XML, but some compiled binary form; you may need to Google for the appropriate binary form pulled from another phone.

The last configuration file is /system/etc/apns-conf.xml. This file contains APN settings for 4G and MMS. See the stock APN settings file for the Sprint Nexus S 4G or the default CyanogenMod APN settings.

Step-by-step guide

If you’re interested in learning more about how exactly this works, you’re welcome to take a look at my follow-up article Flashing a Sprint Nexus S 4G to Verizon, which documents the process of flashing an actual phone.

Using ALSA audio drivers in Android

While working on a port of the Gingerbread (2.3.7) userland of Android for the N810, I had to figure out how to add support for an audio chip with a working ALSA driver in an Android build. The information was out there but it took me a while to figure everything out, so here’s a brief summary of the process.

First, of course, ALSA drivers for the chip must be enabled in the kernel; to check whether they are working, see if /dev/snd is properly populated. If not, check if the driver has been compiled into the kernel and not as a module.

There are three libraries that act as intermediate layers between an ALSA sound device and the Android userland. Due to the recent relocation of the Android source tree, I used alternative URLs for the three libraries. The code (shamelessly stolen and modified from this Armadeus Wiki page) is as follows, assuming $ANDROID_SOURCE points to the root of the checked-out Android source tree:

cd $ANDROID_SOURCE/external
git clone git://git.omapzoom.org/platform/external/alsa-lib.git
git clone git://git.omapzoom.org/platform/external/alsa-utils.git

cd $ANDROID_SOURCE/hardware
git clone git://git.omapzoom.org/platform/hardware/alsa_sound.git

However, a bogus commit to the last library in platform/hardware/alsa_sound breaks the build (as explained in this thread), hence:

cd $ANDROID_SOURCE/hardware/alsa_sound
git checkout ece3f1b6f1e6a67d02e42490eca6c7de62220b57

Then, modify the BoardConfig.mk of your build to include:


And that should do the trick.