HTC ROM Update Utility RUU variants explanation

Owners of HTC devices might be a little confused when it comes to understanding the current method of numbering used by HTC to mark their software updates. Here you can find a short explanation of this matter.

First of all, we all know that HTC sells their devices all over the world. Every carrier and region of the world has some more or less different "local settings". By "local settings" I mean things like: emergency call numbers, languages, time-zone settings, network settings, carriers branding, GPS settings and more. Because of that each software for even the same device must be different.

Secondly, even the same device might use different hardware related to the region of the world. For example, HTC One is available in at least 6 different hardware configurations. One of the main difference is modem version. GSM version of the HTC One uses MDM8215 chip and LTE variant has MDM9215. Verizon (US) is known to have MDM9615. So thats already 3 different versions of the same device.

Every HTC update has the following numbering structure:

a.bb.ccc.d

a - the first number of the software. Normally it doesnt increase very often, but when it does, it usually means newer Android version.

bb - this number is also a software number. Increasing bb number means some more or less major update based on the same Android version, but sometimes it might even bring newer version of the HTC Sense.

ccc (also cc or cccc) - this is the number of the region/carrier. It has nothing to do with the software itself being newer or older. More details below.

d (sometimes dd) - the third part of the software version (the fourth one in the RUU name). Usually indicates some minor update with some hot fixes.

Example: 3.20.401.3

So basically, when you are interested in the software version, you should look at a.bb.d (3.20.ccc.3) because ccc (401) means only the region/carrier variant of the software.

Here is the list I was able to gather of possible RUU variants:

a.bb.61.d - Orange UK (United Kingdom)

a.bb.65.d - Orange CH (Switzerland)

a.bb.69.d - Orange PL (Poland)

a.bb.73.d - Orange FR (France)

a.bb.75.d - Orange ES (Spain)

a.bb.110.d - T-Mobile UK (United Kingdom)

a.bb.111.d - T-Mobile DE (Germany)

a.bb.112.d - T-Mobile AT (Austria)

a.bb.113.d - T-Mobile CZ (Czech Republic)

a.bb.118.d - T-Mobile PL (Poland)

a.bb.161.d - Vodafone UK (United Kingdom)

a.bb.163.d - Vodafone FR (France)

a.bb.165.d - Vodafone IT (Italy)

a.bb.166.d - Vodafone CH-DE (Switzerland - Germany)

a.bb.168.d - Vodafone GR (Greece)

a.bb.169.d - Vodafone AT (Austria)

a.bb.206.d - O2 UK (United Kingdom)

a.bb.207.d - O2 DE (Germany)

a.bb.401.d - World Wide English (WWE)

a.bb.415.d - Arabic (UAE/Middle East)

a.bb.468.d - Turkey

a.bb.497.d - Morocco

a.bb.498.d - WWE Brightpoint US (United States)

a.bb.502.d - Cingular US (United States)

a.bb.531.d - T-Mobile US (United States)

a.bb.631.d - Rogers Canada (WWE)

a.bb.651.d - Sprint US (United States)

a.bb.661.d - Telus WWE (Canada)

a.bb.666.d - Bell Canada

a.bb.707.d - Asia (WWE)

a.bb.708.d - Asia HK (Hong Kong)

a.bb.709.d - Asia TW (Taiwan)

a.bb.720.d - Asia (India)

a.bb.728.d - Virgin AU (Australia)

a.bb.751.d - Chunghwa Telecom (Taiwan)

a.bb.771.d - Hutchison 3G UK (United Kingdom)

a.bb.777.d - ?

a.bb.841.d - Telsra WWE (World Wide English)

a.bb.862.d - Voda-Hutch AU (Australia)

a.bb.901.d - TIM IT (Italy)

a.bb.911.d - SK Telecom (South Korea)

a.bb.980.d - Optus AU (Australia)

a.bb.999.d - HTC Test RUU

a.bb.1400.d - China

a.bb.1401.d - ?

a.bb.1403.d - HTC China CMCC (China Mobile Communications Corporation)

a.bb.1540.d - HTC One U.S. Developer Edition

a.bb.1600.d - ?

a.bb.1700.d - HTC One Google Edition

The list is quite long, and Im sure there are still some some missing. If you know more variants, please let me know in the comments section.

The 401 and the 707 devices are usually the first ones that HTC prepare updates for. Carrier branded software is usually months after the WWE updates.

Finally, keep in mind that each software version is connected with the CID (Carrier ID) and MID (Model ID) of your device. That means you cant use whichever version you want, unless you have S-OFF on your device. Each ROM Update Utility.exe package will check your device details (bootloader version, MID and CID) before starting the update process.

Have any questions or comments? Feel free to share! Also, if you like this article, please use media sharing buttons (Twitter, G+, Facebook) below this post!

Read More..

How to Fix a corrupted DATA partition on the HTC One

Since the HTC One was released, Ive had a few users asking me to help them fix their broken device. They couldnt boot their system or access anything on the DATA partition from inside custom recovery. Why this happens so often on the HTC One I have no idea...

Here is a short guide explaining how to fix this problem without sending the device for repair under warranty.

Short Explanation

This method can be used to fix any other partition too, just remember about changing the mount point number - from "mmcblk0p37" to the relevant one. For example, the SYSTEM on the HTC One is "mmcblk0p35". In some rare cases the mkfs.ext4 attributes (like dir_nlink or resize_inode) might change too! To get a list of all eMMC mount points on HTC devices use the command cat /proc/emmc. Never format RAW partitions! This method can be used only to format EXT4 partitions. Not following the guide properly might end in permanent damage to your device. I do not take any responsibility for that.

Some people might also find this helpful in case of need to remove the entire contents of the virtual SD-card. As long as the virtual SD-card is not a separate partition, (i.e. it is emulated space on the DATA partition [/data/media]) it cant be formatted - only wiped clean. I wrote an in-depth explanation of how the virtual SD-card works on Android here - Virtual SD card on Android.

How Do I Recognise The Problem?

When trying to mount the DATA partition from inside the custom recovery using the mount /data command you will most likely see this output: mount: mounting /dev/block/mmcblk0p37 on /data failed: Invalid argument

To be 100% sure you can check filesystem structure with the following command: /sbin/e2fsck -n -f /dev/block/mmcblk0p37

Repair Process

Note: the content of your DATA partition will be lost, including the contents of your virtual SD-card! I also assume you already have custom recovery flashed and you are a Windows user - LINUX people please amend as needed.

1. Download this mini-sdk package and extract it to c:mini-sdk
2. Download this mkfs.ext4 binary and put it into c:mini-sdk
3. Connect your device to the PC
4. Boot your device in recovery mode
5. Open a command prompt on the PC (cmd.exe), type and confirm each command with ENTER:
6. cd /d c:mini-sdk
7. adb push mkfs.ext4 /tmp
8. adb shell
9. chmod 777 /tmp/mkfs.ext4
10. /tmp/mkfs.ext4 -b 4096 -O ^huge_file,^dir_nlink,^ext_attr,^resize_inode,^extra_isize -m 0 /dev/block/mmcblk0p37

Image of the whole command in one line to avoid mistakes:

Now your DATA partition will be formatted. It is not the same as "wiping", which is only removing all or just some files from particular partition. Formatting means that the entire partition will be re-created with the above attributes. You should see the following output:

mke2fs 1.41.12 (17-May-2010)
Filesystem label=  
OS type: Linux 
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
1703936 inodes, 6815744 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
208 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768,98304,163840,229376,294912,819200,884736,1605632,2654208,4096000
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 25 mounts or 180 days, whichever comes first. 
Use tune2fs -c or -i to override.

Your DATA partition is now completely empty, so we need to copy our particular ROM zip file there:

1. Copy ROM zip file to c:mini-sdk and rename it to "rom.zip"
2. In the same command prompt window type and confirm each command with ENTER:
3. mount /data
4. mkdir -p /data/media/0
5. exit
6. adb push rom.zip /data/media/0

Copying rom.zip to the device will take a few minutes. Wait until its done. The output should be: xxxx KB/s (xxxxxxxxxx bytes in xxx.xxxs). Now you can flash rom.zip from inside custom recovery. Done!

Have any questions or comments? Feel free to share! Also, if you like this article, please use media sharing buttons (Twitter, G+, Facebook) below this post!

Read More..