The Android Platform and

Real Estate Technology

A Whitepaper and Software Evaluation Project Sponsored by

The Center for REALTOR Technology

Table of Contents

Table of Contents 2

Introduction 4

RETS and Android 5

Development Challenges 5

The Android Scripting Engine 5

Other development strategies 6

The Traditional Method 6

LibRETS 6

Porting overview 6

Early success 6

What isn’t possible 7

The result 7

Setting up a Development Environment for Hacking Android 8

Instructions 8

Creating RETS Droid – An Android Application 9

Building dependent libraries - cURL 9

Building dependent libraries - expat 12

Building dependent libraries - zlib 12

Building dependent libraries - STL 13

RETS Droid Documentation 14

Screenshots (RETS Droid) 14

Prototype – A consumer friendly App - Documentation 21

Screenshots (Prototype) 22

Installation Instructions – Installing RETS Droid 24

Setup – Clearing previous installs 24

Setup – allowing unknown source applications 25

Install instructions 25

RETS Droid Usage 25

Conclusion 26

APPENDIX 28

Introducing Android 28

Advantages 29

Instructions for setting up an Android environment 30

About the Author

Mark Scheel is a longtime RETS advocate and Sun Certified Java Programmer with significant mobile platform development experience. Mark is the long time host of the Interesting Applications Exhibition at RETS meetings and a frequent participant in the contest. Mark has excelled professionally at a major MLS and industry vendor. Mark runs a software consultancy at www.digitalconstruction.com.

Introduction

In this white paper the Android operating system and its relationship to Real Estate Technology will be discussed. A comprehensive and objective survey of platforms for developing new software for the Android platform will be performed to establish these relationships. Finally, an analysis of tools built on diverse technical foundations such as Java, Ruby and Python will be performed. This paper will also outline and document the progress of the software development throughout this project. Focus will be made on using the NDK to generate an Android compatible libRETS build, but in the process will get stuck porting the fourth of four dependent libraries. Focus then turns from building a reference application to building a proof of concept that uses the entire NDK stack including a dependent library. The application is documented and has the ability to complete five RETS transactions: Login, GetMetadata, Search, GetObject and Logout. Based on feedback from CRT, a consumer grade functional prototype that showcases the technical side of RETS through a user friendly multiple screen interface with scrolling thumbnails has been created. It includes Google Maps integration, and email capability including attached photos. Its development requires significant upgrades to the initial deliverable as it requires the download of multiple photos and listings, which in turn requires the passing of data from the Android Java software layer, down to the C/C++ Native Development Kit layer, which was previously more loosely coupled. An introduction to Android has been moved to the Appendix.

RETS and Android

Unfortunately fast development of a RETS Android application is not a reality today. There are many reasons for this. Development Challenges

The Android source tree, which is not trivial to obtain, but is freely available, comes with a prebuilt ARM cross compiler. It can be found inside arm-eabi4.3.1/bin. This seems to suggest that libRETS, a C++ RETS library can be easily compiled for the Android. But this is incorrect. To start, LibRETS depends on many libraries like cURL and Boost which do not exist on Android. This is a surmountable obstacle on many platforms. On Android though the C++ implementation lacks basic features which are required. There is no iostream support in libstdc++, locales are missing, and there isn’t even a full libc. Android uses Bionic, a trimmed down version of libc. Code Sourcery makes an ARM cross compiler, but because it uses newlib instead of Bionic it can’t be used. Android provides its own cross compiler however as part of the Native Development Kit (NDK). Before we get into cross compiling libRETS and using it through the NDK, which would be the most compelling use of RETS on Android lets explore some alternatives. The Android Scripting Engine

The ASE is a neat software tool that allows you to write code and execute it on an Android device. It currently supports Ruby, Python, Lua and Perl. It works in concert with the Java API’s exposed to full application developers. The first RETS interfacing Android application was written using the ASE in python. It was able to login to the CRT Demo RETS server. Unfortunately the ASE is not consumer friendly. Unlike most applications that can be launched directly you have to open ASE and choose a script to execute. There is a work around, but even this shows a “scary” shell like interface to the user. Worse, the ASE does not have a way to execute native code (C or C++), which is what libRETS is. To effectively use ASE to write a RETS application you would have to rewrite all the RETS logic in the scripting language you chose. Because the ASE source code is open source, it is possible you could fork the project to integrate a native library and make the interface more user-friendly with significant effort.

If you did, the ability to write scripts with locale would enable you to take specific action based on location or time. For example, a client of a Realtor might walk by a house on a Saturday morning and their mobile device could alert them that it matched their search criteria. After creating the first RETS program on Android with ASE, this approach was abandoned. Other development strategies

There are some other ways to develop for Android, besides the traditional SDK route, and which will be mentioned here, but not investigated them deeply. Phonegap is a cross-platform project that allows you to develop applications in javascript that will run on an iPhone or Android device. There is an Open Screen Project that allows, in theory, for development in Flash, though currently Flash is not supported on my Android devices (Cliq and MyTouch). There is a Scala functional programming Android project. There is a project called Rhodes that allows you to develop for all major smartphone operating systems in Ruby. All of these projects are neat, but none of them have an open source RETS library to draw from. The Traditional Method

The best way to get libRETS onto the Android platform and available to developers is to cross compile it so it can be accessed via the SDK. As mentioned above, this approach is not without challenges. Building C and C++ code on Android is very difficult. Building libRETS is a particular challenge as we will see below. If libRETS can be built, it can be included in SDK projects with NDK calls.

LibRETS

Porting overview

In order to port libRETS to a new platform several external libraries are required, they are: cURL Boost Expat STL Early success

Porting all of those except Boost is possible and a reference NDK application for each has been created, as well as one that combines cURL, Expat and Zlib.

What isn’t possible

A port of Boost was attempted, but due to time constraints could not be easily achieved. An open source Flash project called Gnash has looked into it, but it does not appear they were successful in porting Boost to Android despite excellent cross compilation skill-sets. Posts to the Google Android-NDK mailing list received no responses. It asked if anyone had tried or successfully ported Boost to Android. This will definitely be a point of interest if this project is continued. The NDK awaits many updates and it is entirely possible that a future version will lower the resistance barrier for this crucial step in bringing libRETS to Android. The result

Since libRETS is at its most generic a C/C++ library with dependent libraries that can interface with the CRT Demo server, a substitute was developed. This substitute was a user friendly Android application capable of Login, Metadata, Search, GetObject and Logout Transactions that used a Dalivk compatible APK file. This APK file is compiled from Java code that contains native references to NDK compatible C and C++ code. These native code files have the ability to interact with the CRT Demo server with dependent library support (e.g. cURL) built in. This is the best reference application that can be created at this time. It is probably more apt to describe it as a proof of concept, application due to its limited extensibility.

Setting up a Development Environment for Hacking Android

Development was tested on Windows, Mac and Linux platforms and it was observed that Linux is your friend when hacking the Android framework. Windows is painfully slow at running the ARM processor emulator, and Mac has file-system case sensitivity incompatibility issues. If you only have a Windows or Mac don’t worry! It is free and easy to set up a VirtualBox virtual machine running Ubuntu that will meet your needs.

Instructions

This section has been moved to the appendix: Instructions for setting up an Android environment 30

Creating RETS Droid – An Android Application

RETS Droid is the proof-of-concept application. Most of it is standard Android platform development, but the NDK calls and built in libraries are not that easy. When attempting to build libRETS for Android the dependant libraries needed to be built into C and C++ code separately. Observations and conclusions: Building dependent libraries - cURL

cURL was a difficult port, experiences and comments were posted to the cURL developer mailing list and ever since have been receiving emails from other developers. That work is here: http://curl.haxx.se/mail/lib-2009-12/0071.html Here are more technical notes: Goal: Cross compile a cURL library and use it in an Android application

- download curl src

- extract curl src download

- find out how Android would configure a curl build

put curl source into external

just copy extracted folder to ~/mydroid/external/curl

build android with showcommands on

~/mydroid/make showcommands

wait for failure

Here is the result:

####

target thumb C: curl <= external/curl/src/main.c

prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/arm-eabi-gcc -I system/core/include -I

hardware/libhardware/include

-I hardware/libhardware_legacy/include -I hardware/ril/include -I dalvik/libnativehelper/include

-I frameworks/base/include -I frameworks/base/opengl/include -I external/skia/include

-I out/target/product/generic/obj/include -I bionic/libc/arch-arm/include -I

bionic/libc/include

-I bionic/libstdc++/include -I bionic/libc/kernel/common -I bionic/libc/kernel/arch-

arm -I bionic/libm/include

-I bionic/libm/include/arch/arm -I bionic/libthread_db/include -I external/curl/include

-I external/curl/lib

-I external/curl -I out/target/product/generic/obj/EXECUTABLES/curl_intermediates

-c -fno-exceptions -Wno-multichar -march=armv5te -mtune=xscale -msoft-float -fpic -

mthumb-interwork -ffunction-sections

-funwind-tables -fstack-protector -fno-short-enums -D__ARM_ARCH_5__ -

D__ARM_ARCH_5T__ -D__ARM_ARCH_5E__ -D__ARM_ARCH_5TE__

-include system/core/include/arch/linux-arm/AndroidConfig.h -DANDROID -fmessage-

length=0 -W -Wall -Wno-unused -Werror=return-type

-DSK_RELEASE -DNDEBUG -g -Wstrict-aliasing=2 -finline-functions -fno-inline-

functions-called-once -fgcse-after-reload

-frerun-cse-after-loop -frename-registers -DNDEBUG -UDEBUG -mthumb -Os -fomit-

frame-pointer -fno-strict-aliasing

-finline-limit=64 -Wpointer-arith -Wwrite-strings -Wunused -Winline -Wnested-externs

-Wmissing-declarations

-Wmissing-prototypes -Wno-long-long -Wfloat-equal -Wno-multichar -Wsign-compare -

Wno-format-nonliteral -Wendif-labels

-Wstrict-prototypes -Wdeclaration-after-statement -Wno-system-headers -

DHAVE_CONFIG_H -MD

-o out/target/product/generic/obj/EXECUTABLES/curl_intermediates/src/main.o

external/curl/src/main.c

- run config ./configure --host=arm-eabi from in the external structure

now you have curl_config.h in lib

- start to make jni project

create <ndk>apps/curljni/project (sc)

make new android app in eclipse, starting at project

run the project just to be sure your emulator is working and so is sdk (sc)

add this method below the created onCreate()

public native String stringFromJNI();

static {

System.loadLibrary("curljni");

}

go to project folder in terminal, cd into bin

run: javah com.banandroid.curljni.curljni

look for a .h file which includes this snippet:

JNIEXPORT jstring JNICALL Java_com_banandroid_curljni_curljni_stringFromJNI

(JNIEnv *, jobject);

we will use that in our c file

make curljni.c inside of project/jni/

make Application.mk inside apps/curljni (curljni curl)

make Android.mk inside jni/

make curl folder inside jni/

put lib,src,include from ~bin/curl into jni/curl

ndkroot/make APP=curljni

note: I already had made so script is shortened, could of used -B for full output

note: tried setting to 0, didnt work, have to comment out instead, you see mistake

in output

make fails!

error preceded by:

apps/curljni/project/jni/curl/lib/if2ip.c:51:23: warning: ifaddrs.h: No such file or

directory

apps/curljni/project/jni/curl/lib/if2ip.c:54:23: warning: stropts.h: No such file or

directory

mess around with curl_config, for each var below comment out

/* Define to 1 if you have the <stropts.h> header file. */

#define HAVE_STROPTS_H 1

/* Define to 1 if you have the freeifaddrs function. */

#define HAVE_FREEIFADDRS 1

/* Define to 1 if you have a working getifaddrs function. */

#define HAVE_GETIFADDRS 1

/* Define to 1 if you have the <ifaddrs.h> header file. */

#define HAVE_IFADDRS_H 1

/* Define to 1 if you have a working ioctl SIOCGIFADDR function. */

#define HAVE_IOCTL_SIOCGIFADDR 1

Update curljni.c to actually use libcurl

Error with build now is related to zlib:

SharedLibrary : libcurljni.so

out/apps/curljni//libcurl.a(content_encoding.o): In function `exit_zlib':

apps/curljni/project/jni/lib/content_encoding.c:73: undefined reference to `inflateEnd'

out/apps/curljni//libcurl.a(content_encoding.o): In function `inflate_stream':

apps/curljni/project/jni/lib/content_encoding.c:136: undefined reference to `inflateEnd'

apps/curljni/project/jni/lib/content_encoding.c:137: undefined reference to `inflateInit2_'

apps/curljni/project/jni/lib/content_encoding.c:104: undefined reference to `inflate'

apps/curljni/project/jni/lib/content_encoding.c:120: undefined reference to `inflateEnd'

out/apps/curljni//libcurl.a(content_encoding.o): In function `Curl_unencode_gzip_write':

apps/curljni/project/jni/lib/content_encoding.c:282: undefined reference to `zlibVersion'

apps/curljni/project/jni/lib/content_encoding.c:284: undefined reference to `inflateInit2_'

apps/curljni/project/jni/lib/content_encoding.c:291: undefined reference to `inflateInit2_'

out/apps/curljni//libcurl.a(content_encoding.o): In function

`Curl_unencode_deflate_write':

apps/curljni/project/jni/lib/content_encoding.c:168: undefined reference to `inflateInit_'

collect2: ld returned 1 exit status

lets go back and recompile curl without zlib support since we don't need it

mscheel@ubu:~/mydroid/external/curl$ ./configure --host arm-eabi --without-zlib

//try to replace host with build and see if it works

we'll see if ipv6 gives us any trouble

it worked! but we got a response code 6 (sc)

This is because the app does not have permission to use the internt, so update

manifest:

<uses-permission android:name="android.permission.INTERNET"/>

Now it works. Note: To get a good refresh you need to make the JNI cmd line and

change something in Eclipse before run

Building dependent libraries - expat

To port expat:

make an apps/expatjni/project/jni folder

copy Android.mk into it

delete the host section (middle)

mv lib from expat to project/jni (has .h and .c files etc)

make Building dependent libraries - zlib

To port zlib:

copy Android.mk into project/jni get rid of everything after the shared libz library

copy *.h and *.c from zlib to project/jni

add into Android.mk something for zlibjni

make

Building dependent libraries - STL

To port STL use STLPORT:

start at ndk root

mscheel@ubu:~/bin/android-ndk-1.6_r1$ git clone git://umbel.mooo.com/ndk-

wrappers.git

mscheel@ubu:~/bin/android-ndk-1.6_r1/ndk-wrappers$ source ./env.sh

PATH now includes wrapper scripts.

./setup.sh willl try to rebuild stlport - errors

change a couple 1.5 to 3's - see blog comments, this is for 1.6 -

http://sseyod.blogspot.com/2009/08/android-ndk-getting-stlport-up-and.html

Now ./setup.sh (from ndk-wrappers, no source prefix) yields:

mscheel@ubu:~/bin/stlport/ndk-wrappers$ find . -name "libstlport*.a"

./stlport/build/lib/obj/arm-linux-gcc/so/libstlport.a

RETS Droid Documentation

Below are screenshots of the reference application. Although the interface is simple, the work being done behind the scenes is complex. Here is a visualization of the 11 steps that every RETS action requires: 1. User Selection 2. Java Code 3. NDK/JNI Call 4. C/C++ code with dependent library cURL 5. HTTP 6. CRT Demo Server-------------------------- 7. HTTP 8. C/C++ code with dependent library cURL 9. Return NDK/JNI Call

10. Java Code 11. User Display Screenshots (RETS Droid)

[1.1] Application selection screen.

[1.2] First screen the user sees. Each action can be selected by touch or using the directional pad.

[1.3] Response screen to pressing Login action.

[1.4] Response screen to pressing GetMetadata action.

[1.5] Response screen to pressing Search action.

[1.6] Response screen to pressing GetObject action. A newer version displays the downloaded photo.

[1.7] What it looks like when a user selects an action, such as Logout.

[1.8] Response screen to pressing Logout action.

Prototype – A consumer friendly App - Documentation

In response to feedback from CRT, a consumer friendly interface to the CRT RETS server on Android was developed. It includes a custom coded extension to the Android component ListView allowing for thumbnails of property pictures in a scrolling list. It includes a Toast message that contains timestamped entries indicating progress in obtaining data for and creating the scrolled list. Parsed property data is passed between intents so that a detail page can display additional data fields. The application also allows for plotting of a property on a Google Map, and the emailing of the subject property with prepopulated dynamic subject lines and message bodies as well as an attached photo. These last two features showcase how powerful the Android ecosystem is.

Screenshots (Prototype)

[2.1] Main Menu with Prototype option

[2.2] Scrolling list of properties with summary data – long press top line for log peek

[2.3] Detail page with Map and Email capability and scrolling area of data fields

Installation Instructions – Installing RETS Droid

The application exists as an APK file which is a standard zip file dressed up to provide an Android application. These instructions have been tested on Android 1.5, 1.7, 2.0 and 2.1 and on the hardware devices Cliq, MyTouch and G1. Setup – Clearing previous installs

It is important before proceeding that the file crt.apk does not exist on your phone, if this is your first time installing ignore these instructions to remove any copies of crt from your phone: Download Astro File Manager from the Marketplace, when launched it defaults to

showing files from /sdcard/downloads. If you see any file named crt (crt-1, crt-2, etc.)

long press on the file, select edit and then select delete.

Setup – allowing unknown source applications

Your next preliminary step is to allow unknown source applications: Before you get started you need to change a setting on your phone that will allow you to

download an application that is not in the marketplace (if you don't you will get an Install

blocked error):

Settings > Application > Unknown Sources

Check it so unknown sources are allowed Install instructions

With all instances of crt APK files cleaned from your phone and unknown sources allowed you can install RETS DROID on your phone: 1. Open your phone’s browser 2. Navigate to wapley.com/clients/crt

3. Click the hyperlink for CRT.APK (a download will start, if it says 128k then something

is wrong, did you delete all crt files? It should be at least 129kb)

4. Click the downloaded apk from within your browsers download screen

5. Say yes, you want to Install it

If you have previously installed, there will be some warnings about overwriting

an existing application, agree to them

If this is your first installation there will be a warning that this application has

internet access permissions, agree to it

5. Wait for installation to complete

6. You can now click open, or click done and later access the app under Applications >

RETS Droid

RETS Droid Usage

To see the consumer grade application launch RETS DROID and select Prototype. You are presented with the screen shown in image 2.2 above. This screen shows all properties under $500,000 from the CRT RETS server as summary data and thumbnail images. The top line summarizes how many properties were returned. Long pressing this line shows a Toast message of a log file, providing valuable timestamp information about network latency. Selecting any property brings you to its detail page, like image 2.3 above. On this screen there are two active buttons, one loads Google Maps and push-pins the property’s location. The other allows the user to compose an email with the subject, body, and an attached picture pre-populated with information specific to the property. The rest of this screen includes a header line, a larger photo, and a scrolling text area of detailed information culled from the RETS server. When using Android ecosystem components like Maps and email the back button will return you to RETS Droid.

Conclusion

Google describes working with the NDK as "rough", and this was observed. Attempting to port libRETS, a body of C and C++ code with many dependent bodies of code was at times a technical struggle and at others a lesson in humility. The NDK, or Native Development Kit, is a build system and set of instructions--in constant flux--that allows some C and C++ code to be executed on the Android platform, which is primarily intended to be a Java platform. The native calls are accomplished by calling specially constructed methods through the Java Native Interface, in Java code. The methods execute as C or C++ code on an ARM processor. The process is complicated. It is made more difficult because getting code to run through the NDK is hampered by a number of NDK limitations. A few of them are: - libc does not exist on Android, a subset called bionic exists instead - C++ code is not well supported, RTII and Exceptions are explicitly not supported - Documentation is sparse, incorrect, and confusing - Common libraries like STL are not supported (Boost too) - Combining multiple libraries is in some cases impossible due to documented bugs in the NDK Sounds like a challenge to port libRETS and create a reference application that uses it! To do so would require the following actions: "The Gauntlet" 1. Establish an Android development environment with emulators and other Android SDK Tools 2. Add NDK tools to #1 3. Cross compile dependent library cURL for ARM processor and port to Android via NDK 4. Cross compile dependent library libz for ARM processor and port to Android via NDK 5. Cross compile dependent library expat for ARM processor and port to Android via NDK 6. Cross compile dependent library cURL for ARM processor and port to Android via NDK 7. Cross compile dependent library STL for ARM processor and port to Android via NDK 8. Cross compile dependent library boost for ARM processor and port to Android via NDK 9. Build RETS code with dependent libraries on Android NDK 10. Create reference application with SDK and connect via NDK to 3 - 9 11. Test on Emulator and physical phone Some of these steps were easier than others. 1 and 2 are well documented, although

frought with peril. There are multiple SDK and NDK versions available and knowing which to use for success in later steps is difficult to know in advance. 4 was surprisingly easy, libz is ported by the Android team for internal uses already, and it is possible to ape their process. 6 was deceptively difficult due to bugs in the cURL configure process. 7 was a bear. And 8 proved too difficult to accomplish in the time allotted for this project, it is likely that with current NDK limitations it is impossible to complete. Removing the boost dependency from libRETS--the other side of the coin--is also impossible due to its heavy integration with shared pointers. Eventually, steps 1 - 7 and 9 – 11 were completed. The reference application calls C methods through the NDK that use dependent open source libraries like cURL to interact with the CRT Demo RETS server. It can login, get metadata, search, and retrieve photos. The resultant HTTP responses are gathered by the same C code running on an ARM processor and via the NDK pass information back through the JNI to a user interface that displays on a handset. This has been tested on a MYTouch running Android 1.7 and a Motorola Cliq running MOTOBlur which is a forked version of Android 1.5. CRT has tested this on a G1. The NDK is like the wild, wild, west. It is fraught with challenges but ripe with opportunity. Despite the challenges faced on this project it is clear that the Android ecosystem is a great one to develop productivity tools for Real Estate professionals using RETS.

APPENDIX

Introducing Android

“Hello”

Lets dive right into the history of Android, starting with its formation and roots. The Open Handset Alliance (OHA) is the standards organization in control of Android. It is commonly believed that Google owns Android, but this is not technically true. Google does contribute heavily to the development of Android, but as a partner of the 50 company OHA. The OHA was first established in 2007, which is when Android was first introduced. It was (and remains) a mobile operating system based on the Linux Operating System. It is open source. The Android Software Development Kit (SDK) was first introduced to developers on November 12, 2007. The first mobile handset made commercially available was the T-Mobile G-1. That milestone occurred on October 22, 2008. A year later, the New York Times reported that as many as 18 Android phones were expected in 2009, and those estimates have proven to be mostly accurate. Another misconception about Android is that it runs regular Java programs. Actually Android programs use a virtual machine that is not the Java Virtual Machine, instead it is a subset engine called the Dalvik Virtual Machine. Using the Android SDK it is possible to write programs that run on Dalvik. Android has had several major releases of their operating system – 1.0, 1.5. 1.6 and 2.0. Each has led to changes in the SDK, so a consideration of application development is trying to remain compatible with many different operating systems. The SDK has changed during this timeline as well, as has the NDK which was first introduced in 2009 and has had two revisions. The NDK is the Native Development Toolkit and allows Android applications running on Dalvik to execute specially constructed C and C++ code through a modified JNI (Java Native Interface) protocol. Google publicly states that the NDK is “rough” and is in its early stages. For example, debugging support will come in a future revision of the NDK. The Gartner group has published a study saying that by 2012 there will be more Android devices than iPhone devices worldwide, making this an excellent choice for mobile development.

Advantages

Android has many unique attributes that give it an advantage in the marketplace. Android’s open stance is a big advantage. It has drawn many manufacturers with its royalty free operating system, and not just in the mobile phone space. There are tablet PC’s, laptops, and a popular e-book Reader (Barnes & Noble Nook). Soon there will be Televisions and other devices. The upside for pervasiveness is unlimited. The Android platform offers Application Equality. It is a mobile platform where every application is run with the same priority and every piece of functionality is an interchangeable application. Users can control their mobile platform. A RETS application can be a widget on their home screen. It can interact with the email or the dialer application. To put this another way there are no longer borders to what applications can do. A final advantage of developing for Android, generically, is the rapid development potential. Everything in the platform is oriented around building applications quickly.

Instructions for setting up an Android environment

Here are some tips to getting a productive development environment set up, with included timestamps to provide a general idea of how long steps take but the timing may vary:

Building Android Source from scratch on XP with Ubuntu in VirtualBox on my Asus Eee

PC (HA1000) with 2GB RAM and 1.6Ghz Atom processor, using a cable modem

connection

Start 9:15 AM Already had VirtualBox Set up new machine “Ubuntu on XP 2” with 12GB disk and 1024MB ram Start with CD mounted and netbook ubuntu iso (previously downloaded, karmic koala) Select English Select install ubuntu netbook 9:17AM 9:22AM Welcome screen, select English, select timezone, select keyboard, prepare disk space, specify who are you 9:30 – Installing System 10:22 – Installation complete, Restart Now Button (Be sure to Unmount CD to avoid going through Install again) Ubuntu installation complete, lets do some more clean up steps before we start getting the Android source code 10:34 Update Manager will blink within 5 minutes, go ahead and run updates, too, this will take a long time Now we are almost ready to get the Android source code But, before we go any further lets use a Gnome Desktop Tool to see if we have enough disk space to continue, from the instructions: The source is approximentely 2.1GB in size. You will need 6GB free to complete the

build.

Accessories > Disk Usage Analyzer A 12GB hard disk was initially created and is using 2.2 GB with updates still installing. Seems pretty safe and reliable. An Ubuntu installation (7GB disk drive) building the Android source and ran out of disk space, it was a big pain, so you definitely want to make sure you have enough disk space.

11:14 Lets install Guest Additions Devices > Install Guest Additions (for convenience of cut and paste between host and guest OS and mouse sharing) Open Terminal, go to /CDROM, $sudo ./[filename].run where filename is the x86 or amd64 version, wait for terminal output to ask you to restart 11:33 Restart 11:36 (much prettier now) Test cut and paste between guest and host systems – it works Check disk space one more time – 9.1GB available Lets get some source code! http://source.android.com/download Following steps When getting required packages you need Java-5, not Java-6. Java-5 is not available in karmic koala so you have to do some trickery: http://ubuntuforums.org/showthread.php?t=1289730 $sudo nano /etc/apt/sources.list add these lines:

deb http://us.archive.ubuntu.com/ubuntu/ jaunty multiverse deb http://us.archive.ubuntu.com/ubuntu/ jaunty-updates multiverse

$sudo apt-get update $sudo apt-get install sun-java5-jdk //confirm disk space usage with Y (118MB) and when you see license arrow down and type yes, if you get the graphical version of the license you can use tab/enter – make you say yes and not no, you can get confused, say no, and not realize it until your build fails later [lets say you had already installed java6, that is OK, but a little more work, you need to use the update-alternatives command: $ sudo update-alternatives –install /usr/bin/java java /usr/lib/jvm/java-5-sun/jre/bin/java 70 s //note on my system java6 was set by default to priority 63 $sudo update-alternatives –config java //this lets you choose which java version to use

update-alternatives is pretty nifty, you can check the man pages, but here is my high level summary. You have multiple program versions you want to be able to swap in and out. The ACTUAL versions get installed normally but instead of adding them to the PATH directly you set up a GENERIC executable in the PATH and configure a SYMBOLIC link to that GENERIC. The update-alternatives program changes the symbolic link for you. To make a symbolic link on your own – $ln target link ] Now Java 5 is installed – test with java -v 12:00 break 12:35 update sources.list to comment out the jaunty servers so you are only using the karmic ones $ sudo apt-get update

sudo apt-get install git-core gnupg sun-java5-jdk flex

bison gperf libsdl-dev libesd0-dev libwxgtk2.6-dev build-

essential zip curl libncurses5-dev zlib1g-dev

Straight cut and paste from web page (these are the 32 bit instructions) 12:45 Installing Repo $ cd ~ $ mkdir bin

$ curl http://android.git.kernel.org/repo >~/bin/repo

$ chmod a+x ~/bin/repo

$ mkdir mydroid

$ cd mydroid

$ repo init -u git://android.git.kernel.org/platform/manifest.git

$ repo sync

6:21PM

8:06PM

[Note that sometimes this process is hampered by network timeouts

on the kernel.org site, be patient]

$ gpg –-import

[pgp key]

$ cd ~/mydroid

8:08PM

$ sudo make When this is done many hours later you have Donut/1.6 built. For best NDK compatibility we actually want 1.5. So, need to downgrade to 1.5 … Sudo make clean (to uninstall all built items)

To specify a revision, that is, a particular manifest-branch, use the -b option. For

example: $ repo init -u git://android.git.kernel.org/platform/manifest.git

-b android-1.5

[had options for r1-r4 but going with vanilla]

[instructions say –b release-1.0 but that syntax stopped

working after 1.0]

repo sync if server keeps “fatal: The remote end hung up unexpectedly” than connection is sketchy and you can patch mydroid/.repo/repo/subcmds/sync.py with https://review.source.android.com/#patch,sidebyside,12628,1,subcmds/sync.py only use spaces, no tabs! cupcake branch is missing patch master has – have to modify findleaves.sh: http://android.git.kernel.org/?p=platform/build.git;a=commitdiff;h=239637eac86c8f4f92384891a8f99085039a5778 Start of build still is missing BUILD_ID but it seems to work and seeing CUPCAKE flash by a couple times. Now we get a AST.o compilation error about 10 minutes in, problem is we have gcc and g++ 4.4 which is too strict, downgrade to 4.3 (sudo apt-get install gcc-4.3 and g++-4.3, then sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.3 70 and g++ same for 4.4 but do 60, can check right one is prioritized with sudo update-alternatives –config gcc) Gpg –import Paste key Return ctrl-d ~/mydroid/$ sudo make

Now lets set up our development environment. Download SDK, NDK, and Eclipse for java Galileo In Eclipse get ADT Eclipse – Window – Preferences – Android – Point SDK to unzipped location (~/bin/android-sdk-linux … tar -xvzf) Unzip NDK (unzip) into ~/bin … Reboot That is all, you now have a VirtualBox with a complete development environment and Android source, including Eclipse, the SDK and NDK.