Can you point me in the direction of where to learn how to compile this (
packetlss's Profile - GitHub) -- I know how to compile simple C-code, I'm just assuming that I can't just do it in Eclipse and that I'd probably have to have Ubuntu (I've got a 9.04 on a flash-drive and I could burn 10.04.1 onto a CD) with a gcc compiler (which I'm betting is standard on it). I've just never compiled a whole "tree" of code like this...
Thank you for finding that! (sources)
Eclipse is a generic code-development IDE, but the Android plugin for it revolves around developer support for
Java/Dalvik app development, not native code (ARM executables, kernels, native libs and so forth). So, you won't use Eclipse to build kernels or the Android OS tree - you'll be using conventional Unix development tools - primarily "make". (The hard part about using "make" at the top of a source tree is not typing in the command "make" - it's getting your environment set up correctly so that the build will proceed correctly).
I can only tell you part of the truth - the part that I know. It appears (from what is online at developer.android.com) that Google engineers are probably using Ubuntu 8.0.4 LTS for their development work. (I would avoid at all costs trying to set up a build environment with Cygwin. It's OK to have on your Windows PC, but don't try and build Android with it)
You can use a VM for Ubuntu, but beware - the complete source and build trees for Android are pretty large. I built the AOSP Froyo tree last night, and the git/repo databases + sources + build objects for the full Froyo tree take about 7 Gb of disk space. So, I wouldn't bother using a pre-built VM (e.g. VMware Player machine w/Ubuntu), as a lot of times they are limited to small virtual disk sizes.
(The reason that the builds are so large is that
everything gets built - the emulator, the cross-compilers, all the external tools (fastboot, mkbootimg, ddms, etc) in addition to all the libraries, kernel, utilities, etc.)
You could use VirtualBox from Oracle (free) and build a Ubuntu 8.0.4LTS VM from scratch - I would configure it to use an expandable hard drive with a maximum size no smaller than 30 GB. But I'll tell you - that is only the beginning of your learning. If you pull down the packetlss sources, you will notice all the "Android.mk" files - the builds are structured in a way where they leverage the Google/Android build system - you need to integrate them into an Android build tree, and that means that some large fraction of the Android tree needs to be built first.
I spent some time about 6-8 months ago building standalone ARM executables (exploit codes), so I could point you at
some instructions on how to build either static or dynamic standalone native (ARM) executables, (which turns out to be rather twisty in and of itself for static code), but so far I have only built entire Android Source trees, without trying to splice external Android project code into an Android build tree.
The thing is, to get a truly good grip on the build system for Android (the OS, not the Apps), you probably need to understand not only how the Android build tree is structured, but how to use "git" and "repo" in a fine-grained way, so that you can extract the correct revisions of code (and now there is yet another tool to be learned - "gerrit").
I'm getting close to understanding bits and pieces of it - I will give a shot at building the Amon_RA tree. (I tried a couple of things that I thought would be "obvious" tonight, but no go.)
Is there a "kitchen" that I need and is there a special way to prepare the .img file once its compiled for writing to the recovery partition?
The android-dls.com URL you referenced below is an excellent guide. The one piece of information that it does not provide - which is critical - is the "base" or load address for the kernel, which seems to be different for every phone. For the Eris it is 0x11200000. Here's an excerpt from a script I wrote that shows the mkbootimg command line for an Eris image:
Code:
mkbootimg --kernel ${_KFIL} --ramdisk new-${_RAMDGZ} --cmdline 'no_console_suspend=1 console=null' --base 0x11200000 --output new-${_BNAM}
The ramdisk is compressed with the pipeline mentioned in the android-dls.com URL like this:
Code:
find . | cpio -o -H newc | gzip > ../new-${_RAMDGZ}
Side-side note: I've also been looking at the jarsigner thing we were talking about...I've found the source (
Source Code Cross Referenced for JarSigner.java in 6.0-JDK-Modules-sunsecuritysunsecuritytoolsJava Source Code / Java DocumentationJava Source Code and Java Documentation) and there's a verifyJar method inside it that I'm still trying to digest (no pun intended
)
Note that Google took great pains to avoid licensing issues with Sun/Oracle - while App code is written in Java, they use their own bytecode compiler and interpreter (Dalvik) - they specifically avoided having to license Java from Sun. I am not sure whether their framework/foundation classes have any dependencies on Sun/Oracle classes. While there is no harm in using Sun/Oracle code for learning purposes, I would stick to the Android API standard, and if you can't find the functionality you need there, use the native libraries for signing/verification checks (IIRC, Android uses OpenSSL sources).
For instance, the very native code you are trying to build needs to have all that stuff in it, as it does the same verification process on the same types of files.
I also ran the jarsigner -verify command on a ROM w/verbose mode and looked at the output. At first, it looked like it simply unzips each file in the .zip and then calculates an SHA1 digest on each file and then compares it to the manifest.
That's what the verification step does... plus one more thing: the signature file is a signature of the manifest, so the crypto sig of the manifest is checked. If it is OK, then you know the manifest has not been tampered with by anybody but the signer**, and since 100% of the files need to match the SHA1 hashes in the manifest, then you
also know that none of the files have been corrupted since the signing took place.
(** Every XDA dev has a copy of the "private key" used to sign ROMs used by Amon_RA and Clockwork, so there is no guarantee of authenticity with dev ROMs - you can only be sure that your file isn't corrupted somehow)
However, when I unpack the ROM manually and calculate the SHA1 checksum on a given file, I get a different value than what is published in the MANIFEST.MF for that file (and there's even a different value in the CERT.SF file). Needless to say, I'm a little confused...
Dunno. ??
good luck
