Android phones

[Shachar Shemesh]

On 24/02/11 08:42, Diego Iastrubni wrote:
>
> Can  you explain how those "roms" are done? What does does it mean "binary
> patching"? Points to FMs are OK, search terms are OK as well.
>
>    
FMs?

Also, I never said "ROMs".

Android is a bit unusual in the FOSS world. It is distributed under a 
non-copyleft license. This is not so unusual in itself. What is unusual 
is that most people running Android do so from a closed source 
derivative, rather than from an open source version. In essence, while 
"Android" might be open source, all Android phones aren't (with the 
possible exceptions of Android from the freerunner, which I don't think 
anyone runs any more, and for the N900). This includes the Google 
development phones (G1, Ion, Nexus one and Nexus S). They come with an 
unlocked boot loader that allows easy flashing of the file system, but 
their default install contains much closed source drivers.

There is an open source version of Android. If you own a recent enough 
development phone, you can use the standard Android Open Source Project 
(AOSP) to compile a system image and flash it to your phone. It will 
download a few proprietary user-mode drivers from your phone, but will 
otherwise be completely open source. It will not, of course, contain any 
of Google's proprietary additions (no Market, Maps, Gmail etc.) 
Alternatively, there is a fork of Android called "CyanogenMod", which 
brings the latest version of Android to just about any Android phone 
(and some non-Android phones) in the market, provided you manage to root 
the phone so you can load it. Again, some of the drivers would be 
proprietary.

If you are importing your own phone to Israel, you have two options. You 
can either install CyanogenMod on it, and lose all of your phone's 
unique attributes, or you can try to add proper BiDi support by patching 
the binary. When I say "patching the binary", I mean just that. You use 
a tool called "baksmali" to disassemble the Dalvik machine code into 
Dalvik assembly. Fortunately, the Java heritage in Dalvik is strong, and 
the classes are easily discernible from the disassembled code. You then 
go ahead and replace the code for the specific classes where the BiDi 
processing takes place, and then use a tool called "smali" to 
re-generate machine code from the strange hybrid that is the result. The 
code for the replacement assembly is obtained by compiling the relevant 
changes inside AOSP, and hand picking the classes to be replaced. You 
have to pray that the vendor that produced your phone did not change 
these classes' semantics, but they generally don't (unless they 
implemented their own BiDi, which they might).

The actual process is a bit more complicated than that, but there are 
tools designed to automate much of it. If it sounds horribly weird and a 
miracle to be working, that may be because it is.

Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com