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
RETS and Android 5
Development Challenges 5
The Android Scripting Engine 5
Other development strategies 6
The Traditional Method 6
Porting overview 6
Early success 6
What isn’t possible 7
The result 7
Setting up a Development Environment for Hacking Android 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
Introducing Android 28
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.
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.
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
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
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
After creating the first RETS program on Android with ASE, this approach was
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-
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
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.
In order to port libRETS to a new platform several external libraries are required, they
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.
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.
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
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
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
-I hardware/libhardware_legacy/include -I hardware/ril/include -I
-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
-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 -I out/target/product/generic/obj/EXECUTABLES/curl_intermediates
-c -fno-exceptions -Wno-multichar -march=armv5te -mtune=xscale -msoft-float -fpic -
-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-
-frerun-cse-after-loop -frename-registers -DNDEBUG -UDEBUG -mthumb -Os -fomit-
-finline-limit=64 -Wpointer-arith -Wwrite-strings -Wunused -Winline -Wnested-externs
-Wmissing-prototypes -Wno-long-long -Wfloat-equal -Wno-multichar -Wsign-compare -
-Wstrict-prototypes -Wdeclaration-after-statement -Wno-system-headers -
- 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();
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
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
error preceded by:
apps/curljni/project/jni/curl/lib/if2ip.c:51:23: warning: ifaddrs.h: No such file or
apps/curljni/project/jni/curl/lib/if2ip.c:54:23: warning: stropts.h: No such file or
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
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
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)
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
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-
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 -
Now ./setup.sh (from ndk-wrappers, no source prefix) yields:
mscheel@ubu:~/bin/stlport/ndk-wrappers$ find . -name "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
6. CRT Demo Server--------------------------
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
[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
[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.
[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
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
Settings > Application > Unknown Sources
Check it so unknown sources are allowed
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 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.
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
Sounds like a challenge to port libRETS and create a reference application that uses it!
To do so would require the following actions:
1. Establish an Android development environment with emulators and other Android
2. Add NDK tools to #1
3. Cross compile dependent library cURL for ARM processor and port to Android via
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
6. Cross compile dependent library cURL for ARM processor and port to Android via
7. Cross compile dependent library STL for ARM processor and port to Android via
8. Cross compile dependent library boost for ARM processor and port to Android via
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
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
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
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
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
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 install ubuntu netbook
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
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
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.
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: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!
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:
$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
[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-
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
update sources.list to comment out the jaunty servers so you are only using the karmic
$ 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)
$ 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
[Note that sometimes this process is hampered by network timeouts
on the kernel.org site, be patient]
$ gpg –-import
$ cd ~/mydroid
$ 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
$ repo init -u git://android.git.kernel.org/platform/manifest.git
[had options for r1-r4 but going with vanilla]
[instructions say –b release-1.0 but that syntax stopped
working after 1.0]
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:
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
~/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 …
That is all, you now have a VirtualBox with a complete development environment and
Android source, including Eclipse, the SDK and NDK.