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
_______________________________________________
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
