Archive for the ‘Uncategorized’ Category

XMPP and WCF .Net – Introduction

Hummm… XMPP and WCF? Is this not a blog page about Android or other Google related stuff. That’s partly true but as a Microsoft .Net developer I am more interested in combining the best of both world. I like Google and Microsoft products. I really like the open source vision of Google. But when it comes to development tools I prefer using Microsoft.

So that’s me, living between both worlds. Using the best of both worlds to develop good implementations. And that is where this new blog post are about.

Some time ago Google launched Google Wave presentation (http://wave.google.com/help/wave/about.html) When I watched the presentation, I was (and still am) impressed.

At my previous job, we developed a real time location aware application. A huge amount of data was collected by the location systems, was processed by the server and was made visible on the clients. The made visible part is a tricky one, because we wanted to make use of protocols which where cross platform like SOAP. The result was a polling mechanism which sends requests on interval basis to the server to get new data.

We knew that this was not the best implementation. At that time (almost 3 years ago) we were also thicking about as a possible solution. XMPP stands for Extensible Messaging and Presence Protocol (http://xmpp.org/). A protocol which was developed already in 1999 and is based on XML. I think that the popularity of this protocol was getting a boost when Google launched their Google Talk client in augustus 2005.

I found a presentation on the Web about XMPP (http://www.slideshare.net/kellan/beyond-rest) which has a nice slide (shown in the image below). This reminds me of an episode of the Smurfs (http://en.wikipedia.org/wiki/The_Smurfs) where the Smurfs are on a long trip.

Brainy Smurf: Is it much further, Papa Smurf?
Papa Smurf: Not much further my little smurfs.
Jokey Smurf: (different location) Is it much further, Papa Smurf?
Papa Smurf: Not much further my little smurfs.
Grouchy Smurf: (third location) Is it much further, Papa Smurf?
Papa Smurf: (exasperated) Yes…it is!

Are we there yet?

Are we there yet?

So when all Smurfs are requesting data from Papa Smurf, Papa Smurf becomes overloaded. A better solution would be a Publish Subscribe implementation  (http://en.wikipedia.org/wiki/Publish/subscribe). XMPP has such extension: http://xmpp.org/extensions/xep-0060.html. This way the clients (little smurfs) don’t become bored (they can do other things) and Papa Smurfs don’t get distracted or even overloaded.

Tell me when I get there

Tell me when I get there

The protocol of Google Wave is based on this model. The protocol makes use of the XMPP protocol together with some extensions. Installation document of the Google Wave Federation Prototype server can be found at http://code.google.com/p/wave-protocol/wiki/Installation Of course Google is using Java or Phyton for the example clients, and that is exactly the part where my love for Microsoft fits in. I am really interested in building a Google Wave protocol client within .Net

Because XMPP is involved, the first step would be to develop a XMPP client in .Net. There are some XMPP libraries available for .Net but those don’t have a flexible extension model. And when looking at Windows Communication Foundation, there are already some parts available for setting up the connection and send/retrieve messages. Developing an XMPP library based on the WCF technology is the first goal of these new blog posts.

What’s next?

Before looking at a WCF implemtation, it is good to know how XMPP works. Therefore I will develop a sample client which makes use of the .Net TcpClient to initiate and send/retrieve messages (no WCF involved). To test this client I will install a XMPP server called OpenFire (http://www.igniterealtime.org/projects/openfire/index.jsp). Check this blog often for new updates… and remember Papa Smurf, we are not there yet!

BTW I love to retrieve comments on this (or my other blogposts). Your feedback is really important!

Building Chromium OS – update

Today (or yesterday late) I started download and building the source of Chromium OS again. As a described inside my blog and at http://groups.google.com/group/chromium-os-discuss/browse_thread/thread/ba8ddf13edece9a6/647d2632e8c2d615?lnk=raot I got a blue gradient screen after login.

One of the reponse of this post said something about the different version of the gtk library which are used http://code.google.com/p/chromium-os/issues/detail?id=676 Ubuntu 9.10 makes use of libgtk2.0 2.18.3 while Chrome OS is packaged with 2.17.2. So building the code went fine but when running you get errors inside the log file var/log/slim.log

/opt/google/chrome/chrome symbol lookup error: /opt/google/chrome/ chrome undefined symbol: gdk_x11_window_get_drawable_impl

You don’t get this issue when using the pre built browser binary (because this one is compiled with the right package). But my idea was that I wanted to build the Chromium OS completly from source. Because I did not want to make another chroot environment for building the browser code, I created a new virtual machine (within VMWare) and this time I use Ubuntu 9.04

About Chromium

About Chromium

I updated my previous blog post and this time I get a browser after login. Still the system is far away from stable (but this is probally because it is a very early version) and performs not that smooth (probally lack of drivers). But it is working.

So check out the previous (updated) blog post (http://www.johandekoning.nl/index.php/2009/11/23/building-chromium-os/) and I hope it helps you when building the system by your own. Of course it is possible to ask question or give feedback by posting comments.

Building Chromium OS

Note: for my first build I used Ubuntu 9.10. It looks like there are some issues with using this version so for my second build I am using Ubuntu 9.04. Some of the part of this blogpos became obsolete because those issues don’t exists anymore. I marked those part as red. When updating this blog I am using the revision 33052 of the browser code. I don’t know which revision I am using of the OS code

While I have no time to complete the build proces for Android 1.6 (looking at the Google application part), I quickly start looking today at building the Chromium OS (for which the source code was released today (20 november 2009)). Within this blog post, I will summarize the steps I took to build the Chromium OS. I used the steps described at http://www.chromium.org/chromium-os/building-chromium-os

Installation of Ubuntu

Just like Android, I prefer to use an Ubuntu environment as development/build environment. Android could not be build on a Windows OS, it looks like this is possible for Chromium OS. But still setting up an Ubuntu environment is quite easy. I use VMWare server to make an Ubuntu virtual machine.

With Android I used Ubuntu 8.04. This time I am using the Ubuntu 9.04 version. The document suggests Ubuntu 9.10, but it looks like that building the browser part is not completly possible because of the gtk library used (details at http://code.google.com/p/chromium-os/issues/detail?id=676). Installation of Ubuntu is executing a next-next-finish Wizard, keeping things as default as possible (partition table) and supplying some information when needed (user login).

After installation of Ubuntu, I always perform a sudo apt-get update and sudo apt-get upgrade to get the latest version of the installed packages.

Because I am using VMWare, I also install the VMWare tools.  Because the VMWare tools supplied by VMWare server are not compatible with Ubuntu 9.10, I choose the Open VMWare version by following the instructions which are listed here http://langui.sh/2009/10/05/ubuntu-9-10-in-vmware/

I tried to installed the Open VMWare tools (like it did on my first attempt building Chromium with 9.10) but it looks like Open VMWare is not compatible with 9.04. I tried the normal VMWare tools supplied by VMWare server and those are working fine.

Prerequisites

To build Chromium, several libraries are needed to compile the source code. There is a package list shown at http://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites

To simplify the installation of those packages, there is a script supplied which will automatically install the requires software. This script can be found at http://src.chromium.org/svn/trunk/src/build/install-build-deps.sh Save this script on you local harddrive at a location which is easy to find/remember (for example your home directory).  To execute this script, use the following commands from a terminal window

chmod a+x install-build-deps.sh
sudo ./install-build-deps.sh
This script installs all tools and libraries needed to build Chromium.
For most of the libraries, it can also install debugging symbols, which
will allow you to debug code in the system libraries. Most developers
won't need these symbols.
Do you want me to install them for you (y/N)
Skipping installation of debugging symbols.

The script will ask if you want the debugging symbols to be installed. I choose No because at this moment I don’t want to debug the code of the system libraries.

The code repostitory is not only on SVN but makes also use of git. So you also have to install the git-core package

sudo apt-get install git-core

Issue with msstcorefonts

With ubuntu 9.04 I did not have any issues with installin msstcorefonts

The install_build_deps.sh script will also install the msttcorefonts package. Installation of this package did not succeed because of (dns) time outs (the files are downloaded from sourceforge). To get rid of those timeouts, change the file at /var/lib/dpkg/info/ttf-mscorefonts-installer.postinst. Remove the -dns-timeout=10 part at line 148.

if ! wget --continue --tries=1 --connect-timeout=15 --read-timeout=300 $QUIET_ARG --directory-prefix . --no-directories --no-background $URLROOT$ff ; then

Getting the browser source code

The Chromium OS has two components: the browser and the operating system. Because, although that is my idea, you want to build the complete solution, we also download the source of the browser part to get everything. This step is optional because you can also use a pre-built binary version of this Chromium-based browser (more details at http://sites.google.com/a/chromium.org/dev/chromium-os/building-chromium-os/getting-the-chromium-os-source-code)

Install depot_tools scripts

To get the browser source, a package of scripts (depot_tools) need to be installed. Those script are used to manage checkouts and perform code review. One of the tools used inside this package is gclient to retrieve the Chromium code. The depot_tools can be retrieved in multiple ways (SVN or as a download) I use the SVN method by executing the method (from the home directory ~/)

svn co http://src.chromium.org/svn/trunk/tools/depot_tools

This will create a directory (together with the scripts) called depot_tools inside your home folder (~/depot_tools). Add this location to your PATH. I add this to the .profile file

gedit ~/.profile

Add to the the end of the file

export PATH=$HOME/depot_tools:$PATH

Save and exit the text editor. To activate this change (without rebooting), reload the .profile file (from the ~/ location)

. .profile

Check your PATH by executing the echo $PATH command. You should get something like this

/home/jcdekoning/depot_tools:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Get the source code

Create a directory inside your home location called chromium. This location will hold the source which belongs to the browser (part of the OS).

mkdir ~/chromium
cd ~/chromium

Code retrieval is done with the gclient tool. Configure this tool by executing

gclient config http://src.chromium.org/svn/trunk/src http://chromium-status.appspot.com/lkgr

The first url is the SVN location. The second url is a reference to the revision number which should be downloaded (SVN works with revision numbers). The http://chromium-status.appspot.com/lkgr holds a reference to the revision which succesfully passed the unit tests (in debug mode). This way you will download not the latest version, but a version that builds (most of the time).

You can also make use of another revision reference http://build.chromium.org/buildbot/continuous/LATEST/REVISION. This is a reference to the revision that passes both unit tests and layout tests. This version will probally an older version than the lkgr one, because layout tests will take some time to run on the server.

It is also possible to specify a different revision number (by supplying a revisionnumber) but this is not part of this blog post and you will probally want to use the LKGR one. The status of the source tree can be found at http://build.chromium.org/buildbot/waterfall/console (when it is green/open you should be able to compile the code)

Retrieve the source by executing the following command. Code retrieval will take some time

gclient sync --deps="unix,chromeos"

Because you will use the code for building the Chromium OS, you need to supply the deps argument

Getting the OS source

Create a directory for the OS source. I use a location within my home directory called chromiumos

mkdir ~/chromiumos
cd ~/chromiumos

Code retrieval from the Git repository is also done with the gclient (and will also take some time)

gclient config http://src.chromium.org/git/chromiumos.git
gclient sync

Build Chromium OS

After the code is retrieved for both parts (browser and OS), it is time to build the Chromium OS. The different build scripts are inside the ~/chromiumos/chromiumos.git/src/scripts directory

cd ~/chromiumos/chromiumos.git/src/scripts

Local package repository

Chromium OS builds only it a seperate environment (chroot environment). This way the build result does not (or less) depend on the, in our case, Linux environment installed. To prepare this chroot environment, the first step will be the retrieval of the different packages which will be used to create this environment.

From the scripts directory, execute the following command to make a local repository of the packages. This will take some time

./make_local_repo.sh

Create chroot environment

After the local repository is created, it is time to set up the chroot enviroment

./make_chroot.sh

Build browser

The Chromium OS will be build within the seperate chroot environment. But before we can start to build the OS, you need to build the browser. This step is not needed when you use the binary pre-built version of the browser.

When building the browser, I got two build issues. I solved them by making some changes in the code. So before building the browser from the source, you have to make some changes.

When building the browser code (revision 33052) I did not get this issues written below. It is possible that the source code is updated (patches are merged inside revision) or that the issues are related to package version (like the gcc). So fixing both issues can be skipped.

Patch 414025

When building the source, I got an error like ‘<anonymous>’ is used uninitialized in this function inside the cookies_tree_model.cc file. This issue can be fixed by applying a patch (details at http://codereview.chromium.org/414025/show)

Download the patch file issue414025_1_2.diff from http://codereview.chromium.org/download/issue414025_1_2.diff and save it inside the ~/chromium/src/ directory. Apply the patch by running

patch -p0 -i issue414025_1_2.diff

Conflict_resolver.cc issue

Another build issue is related to the conflict_resolver.css file (~/chromium/chrome/browser/sync/engine/conflict_resolver.cc). This error is related to the fact that the compiler has some difficulties with understanding the type std::string. This issue can be solved by adding an #include <string> to the file.

Open ~/chromium/chrome/browser/sync/engine/conflict_resolver.cc inside your favorite text editor and add the following string (somewhere at the beginning of the file, i.e under #include <map>)

#include <string>

Save the file and exit the texteditor

Build the browser code

After both issues fixed, it is time to build the browser code. This is done by executing

./build_chrome.sh --chrome_dir ~/chromium

Whereby the –chrome_dir argument references to the source location of the browser code. Compiling/building will take some time.

Enter chroot build environment

Because the Chromium OS is build within its own build environment, it is time to enter this prepared enviroment. Run

./enter_chroot.sh

Chromium OS configuration

Inside the chroot environment there are two configuration steps which can be taken to make it easier to work with the Chromium OS (within this development stage).

Enable a local user account

When the Chromium OS boots, you get a login screen where you enter your Google account username and password. It is possible (and I confirm that this was the case for me) that authentication is not working (no network connection, lack of network driver support). By creating a local test user, you are able to login with this username (and empty password). To create this local user account (from within the chroot environment):

( cd ../platform/pam_google && ./enable_localaccount.sh USERNAME )

Change USERNAME to the username you want to use.

Shared user password

When you want to enter a terminal from within the Chromium OS and you want to perm task as sudo, you have to type in a password. This password is normally random generated (for security). You can define your own sudo password by executing (from within the chroot environment):

./set_shared_user_password.sh

Build the packages and kernel

Next step will be building the packages and kernel for Chromium OS. Both is done from within the chroot enviroment by executing the following commands:

./build_platform_packages.sh
./build_kernel.sh

Instead of running above commands, you can also execute ./build_all.sh. This will not only build the platform packages and kernel, but will also create the Chromium OS image (which can be copied to an USB key or VMWare/VirtualBox). When runnin build_all.sh, you can skip the next step

Building the image

From within the chroot environment, create the Chromium OS image by executing

./build_image.sh

The script will end with something like

Done.  Image created in /home/jcdekoning/trunk/src/build/images/999.999.32609.064708-a1
To copy to USB keyfob, outside the chroot, do something like:
./image_to_usb.sh --from=~/chromeos/src/build/images/999.999.32609.064708-a1 --to=/dev/sdb
To convert to VMWare image, outside the chroot, do something like:
./image_to_vmware.sh --from=~/chromeos/src/build/images/999.999.32609.064708-a1

The output directory where the image will be stored, is generated by the script. This number will probally be different on your environment.

The Chromium OS is now successfully build and you should be able to copy and run it from an USB key or use it within VMWare. Using the image is explained in the following steps

Using the image

Exit chroot

Before using the image (copy to USB or use within VMWare), you can check the image content by mounting it locally. Make sure that you exit the chroot enviroment first by running the exit command. You will be back in your own system environment.

Check the package list

Mount the image by running the following commands. Replace SUBDIR with the unique generated number for your build (i.e. 999.999.32609.064708-a1)

cd ~/chromiumos/src/build/images/SUBDIR
sudo mount -o loop rootfs.image rootfs
sudo chroot rootfs

Get a list of the installed packages by running

dpkg -l

Exit the image and unmount the image (when finished exploring the image content)

exit
sudo umount rootfs

Copy image to a USB key

Because at the moment I don’t have a 4GB USB key available, I did not performed those steps yet (details at http://sites.google.com/a/chromium.org/dev/chromium-os/building-chromium-os/build-instructions). Copying the image to the USB key is done by running the command

I got an USB key (8GB) and copyied the image by running the command

./image_to_usb.sh

This command will copy the latest build to the device /dev/sdb. If you want to copy not the latest build or if the location of the USB key is different, run the following command

./image_to_usb.sh --from=~/chromiumos/src/build/images/SUBDIR --to=/dev/USBKEYDEV

Whereby the SUBDIR should be replaced by the unique generated number, and the USBKEYDEV to the device for the USB key.

I will post my results (update this blogpost) when I performed the copy to USB key steps.

Use/convert image for VMWare

The Chromium OS image can also be used within VMWare by converting it to an vmware disk (.vmdk). You can also use this disk within Sun VirtualBox.

To make converting possible, you should install the qemu package

sudo apt-get install qemu

After the qemu package is installed, run the image_to_vmware.sh script.

./image_to_vmware.sh

This will convert the latest build to the ~/chromiumos/chromiumos.git/src/build/images/SUBDIR/ide.vmdk location (SUBDIR is the unique generated number for the build). If you want to specify the build and or the location where the VMWare image should be stored, then use the command:

./image_to_vmware.sh --from=~/chromiumos/chromiumos.git/src/build/images/SUBDIR \ --to=~/chromiumos/chromiumos.git/src/build/images/SUBDIR/ide.vmdk

I copied this image to my Vista enviroment (to get it outside Ubuntu) and created a new Virtual Machine within VMWare Server. As operating type, I selected Ubuntu. Don’t create a new disk but use an existing one (the ide.vmdk file). Make sure that you change the disk options/type to IDE (and not SCSI).

When running ChromiumOS within VMWare, I got the login screen after a couple of seconds. I am not able to login with my Google account (get a message that there is no network connecting). Login with the local user account (with empty password) is possible but after login it shows nothing (only a blue gradient screen). I hope I can solve this issue soon (first need to know what causes this issue). I will also try to arrange some USB key, to check if it is VMWare related

With my new build (25 november) it is still not possible to login with my google account. Login with the local account is possible and this time a browser is visible. Still the system is slow (except from the boot part), especially the internet connection (takes more than 10 seconds to load a page) and also the systems completly freeze at certain times (so you should perform a reboot).

Chromium OS login screen

Chromium OS login screen

And some new screens (after logged in).

Login information

Login information

Main menu

Main menu

Twitter inside Chromium OS

Twitter inside Chromium OS

What’s next…

I succesfully build the ChromiumOS (browser and OS) but am not able to use the system after login. I will try the USB key installation first to see if the blue gradient screen issue also occurs there. To solve my issue, I started a thread at the Chromium discussion group. Because this is my first post in this group, the moderator should first check my post (so it is not there yet) http://groups.google.com/group/chromium-discuss

Hope to give an update / solve this issue soon. Please let me know if you encounter the same problems

Update 23 november 2009: my post is accepted and can be found at http://groups.google.com/group/chromium-os-discuss/browse_thread/thread/ba8ddf13edece9a6# I got a response that somebody else had the same issue. So still not solved…

Update 25 november 2009: I am able to succesfully build the Chromium OS and it is also possible to use it. The system is not responding very smoothly and freezes often. Also the internet connection is really slow. One of the problems could be the lack of driver support. I also booted the OS from the USB key, but it still performs slow.

At the moment I am really impressed about the boot time. In a couple of seconds VMWare/PC shows the boot screen. Love to see this fast boot in other distributions so that it can be used for media center functionality.

It is not my plan for now to get involved in the development of this OS. So the next step for me will be to check new revisions at interval basis to get an idea about the progress made. I am also interested in the future of this OS to see whats the big thing behind this OS and if it will be used by a large group of people.

Building donut for dream – Proprietary files difference

It looks like a donut build for the Dream is possible. HTC release 1.6 version of Android on their website (http://developer.htc.com/adp.html). So a new attempt for building donut for dream can be made.

Before starting a new build I was wondering if there was any differences between the proprietary files. I made the following list (comparing the 1.5 with the 1.6 HTC versions of Android)

Equal

  • AudioFilter.csv
  • AudioPara4.csv
  • AudioPreProcess.csv
  • gps.conf
  • Fw1251r1c.bin
  • libaudioeq.so
  • libhgl.so
  • libhtc_acoustic.so
  • libjni_pinyinime.so
  • libOmxCore.so
  • lights.msm7k.so

Different

  • akmd
  • brf6300.bin
  • tiwlan.ini
  • libgps.so
  • libhtc_ril.so
  • libmm-adspsvc.so
  • libOmxH264Dec.so
  • libOmxMpeg4Dec.so
  • libOmxVidEnc.so
  • libopencorehw.so
  • libqcamera.so
  • libspeech.so
  • sensors.trout.so

Removed
The following files are not inside the 1.6 version

  • libpvasf.so
  • libpvasfreg.so
  • lights.goldfish.so

It is possible that libvasf*.so are renamed to libvasfcommon.so, libpvasflocalpb.so and libpvasflocalpbreg.so. Currently I don’t know if these files should be extracted from the HTC 1.6 image and added to the build. The new extract-files.sh version does not contain those files.

With these changes in mind, the next step will be building the donut source for dream again, boot the custom build and compare this version with the HTC 1.6 version.

Running Android on other hardware

Now that building Donut for Dream is not working at the moment (because of the prioritary files) and it is unkown if it will be possible (because of the memory size on the device) I become interested in porting Android to different hardware.

It would be nice to have hardware with the complete specifications. This way there is no (or less) problem with proprietary files because code can be written to implement these parts (because of the hardware specification available). This would be great to expand my knowledge about Android (and the linux kernel) which is currently not that big.

I was looking at some hardware and found two options: the beagleboard or the chumby. Both devices don’t have a GSM radio stack but maybe this can be added by the use of an USB device.

Beagleboard

The USB-powered Beagle Board is a low-cost, fan-less single board computer that unleashes laptop-like performance and expandability without the bulk, expense, or noise of typical desktop machines.

Above is the description of the beagleboard (http://www.beagleboard.org) as written on their website. It is a really small piece of hardware (about 7.6 cm) and can be extended with other (USB) hardware. Just like the Dream it also uses an ARM processor.

BEAGLE BOARD

Beagle Board

A small shopping list of hardware that should be bought when using the BeagleBoard can be found at http://code.google.com/p/beagleboard/wiki/BeagleBoardShoppingList Looking at the minimal hardware list, the total price is about $250 without shipping costs(with the current exchangerate of 1.4 this will be 176 EUR). You can lower the price if you buy some parts on eBay (for example the USB HUB with Ethernet http://www.supermediastore.com/gwc-usb-2-0-3-port-hub-ethernet-adapter.html can be found on eBay for 12.50 EUR). BTW with the hardware you don’t have a nice touchscreen.

Beagleboard with connected hardware

Beagleboard with connected hardware

Chumby

The chumby (http://www.chumby.com) is some kind of cute device which can be described as an Internet radio/media player/alarm clock. Because it is a complete product there is already software installed. The Chumby runs linux and makes use of widgets (which are developed in Flash).

Looking at the hardware, the Chumby has an ARM processor, 3.5 inch touchscreen, Wifi connection and sensors (Squeeze and accelerometer). The hardware specification and source code of the Chumby is available (http://www.chumby.com/developers) which makes it a really good starting point for porting Android to the Chumby.

Chumby

Chumby

The price of a Chumby is $199.95 (141 EUR) shipping costs not included. The only problem for me is that I cannot order it to my address in The Netherlands.

What’s next?

I know that there is already some porting done (like for the Beagleboard http://labs.embinux.org/index.php/Android_Porting_Guide_to_Beagle_Board). But let’s be clear, I am more interested in where to start with porting Android and which steps to take than simply run some build scripts. If I know the details of the porting process than I can describe them here as a reference for other devices. BTW I am not trying to reinvent the wheel, so if some porting is done and for me it is clear why that has been done, i might/will use that ported stuff. But it should be clear why and not because somebody else said so.

When looking at the BeagleBoard and the Chumby, my choice goes to the Chumby. In the mean time, while ordering the hardware, I would like to get some pointers of you where to start with porting Android.

Building donut for dream – Second attempt: a home screen

The first attempt was not a success, but based on the discussion at http://groups.google.com/group/android-platform/browse_thread/thread/929aa624d2da63a7 I decided to make another build with less proprietary files.

Before the patch with the extracting and adding of the extra proprietary files was applied on the source tree (master, cupcake and donut) there was a small list of proprietary files. I used that list again with libcamera.so added because otherwise you cannot make a build. I kept the extract-files.sh the same because I doesn’t matter if the files are inside the proprietary directory. I changed the AndroidBoard.mk file  inside the ~/mydroid/vendor/htc/dream-open to this (only showing the htc proprietary section, the rest is kept the same)

# htc proprietary code
#
proprietary := $(LOCAL_PATH)/proprietary

PRODUCT_COPY_FILES += \
   $(proprietary)/akmd:system/bin/akmd

PRODUCT_COPY_FILES += \
   $(proprietary)/AudioFilter.csv:system/etc/AudioFilter.csv \
   $(proprietary)/AudioPara4.csv:system/etc/AudioPara4.csv \
   $(proprietary)/gps.conf:system/etc/gps.conf \
   $(proprietary)/brf6300.bin:system/etc/firmware/brf6300.bin \
   $(proprietary)/tiwlan.ini:system/etc/wifi/tiwlan.ini \
   $(proprietary)/Fw1251r1c.bin:system/etc/wifi/Fw1251r1c.bin

PRODUCT_COPY_FILES += \
   $(proprietary)/libaudioeq.so:system/lib/libaudioeq.so \
   $(proprietary)/libgps.so:system/lib/libgps.so \
   $(proprietary)/libhgl.so:system/lib/libhgl.so \
   $(proprietary)/libhtc_acoustic.so:system/lib/libhtc_acoustic.so \
   $(proprietary)/libhtc_ril.so:system/lib/libhtc_ril.so \
   $(proprietary)/libOmxCore.so:system/lib/libOmxCore.so \
   $(proprietary)/libqcamera.so:system/lib/libqcamera.so \
   $(proprietary)/libcamera.so:system/lib/libcamera.so

PRODUCT_COPY_FILES += \
   $(proprietary)/libgps.so:obj/lib/libgps.so \
   $(proprietary)/libOmxCore.so:obj/lib/libOmxCore.so

After the build is finished, I flashed the images again to the phone and did a reboot. This time donut boots and shows a home screen.

Donut Home Screen

Donut Home Screen

About phone screen

About phone screen

Although the phone boots, you can’t do anything serious with it. For example you cannot make phone calls because the simcard is not recognized. This also prevents the use of 3G connection. When enabling Wifi the system crashes and reboots (and ends in an endless boot sequence because Wifi is set to enabled but cannot be started).  The camera and media playing seems to work fine. But missing the phone functionality makes it not useful.

So next question is, how to get the phone functionality working? When looking at the proprietary files which are not added this time to the image, I did not find one related to this functionality. So is it related to something else or should we search for the solution inside the closed parts of the Android Dev Phone (maybe the radio part)?

If the issue is related to the closed parts of the system, then we should wait for HTC when they provide us with an updated version of the proprietary files. It is a pity that this dependency exists for a open sourced operating system. Shouldn’t it be possible to develop open variants of the proprietary files by looking at the hardware specifications of the Dream?

To be continued… (hopefully soon)

Building donut for dream – First attempt: a black screen

Yesterday I started downloading the source code from the donut branch again to see if it was possible to get it running on the HTC Dream (Android Dev Phone).

I build the source the same way as building cupcake but this time I used the defaults (like the prebuilt kernel and wlan.ko module) and did not change the htc_dream.mk build script.

The libcamera.so proprietary file is needed (and should be extracted from the official image) to make a sucessfull build (succesfull like that it builds). This is a difference with cupcake.

After flashing the phone, it shows the two boot logo’s and than a black screen. Looking at the debug information (shown inside logcat within Eclipse) you can see that there is an endless loop whereby android crash (the system_server) and is started over again (and crash… etc). Some of the errors are shown in this discussion (http://groups.google.com/group/android-platform/browse_thread/thread/929aa624d2da63a7).

So not a bootable donut version yet. For the record the steps I took

Initialize repo and get the source

cd ~
mkdir mydroid
cd mydroid
repo init -u git://android.git.kernel.org/platform/manifest.git -b donut
repo sync

Extract proprietary files (after source is downloaded)

cd ~/mydroid/vendor/htc/dream-open
./extractfiles.sh

You can also use the unyaffs method (described in this post http://www.johandekoning.nl/index.php/2009/06/07/building-android-15-getting-the-source/). But don’t forget to copy the libcamera.so from the lib folder

cp ~/htc/lib/libcamera.so ~/mydroid/vendor/htc/dream-open/proprietary/libcamera.so

Build source

Create a buildspec.mk file (inside the ~/mydroid directory) to define that a htc-dream build should be made. Because the prebuilt kernel is used, the file has the following contents:

TARGET_PRODUCT:=htc_dream

Save the file and start the make command from the mydroid directory

make

Flashing the phone

After build is finished flash the image files to your phone within fastboot (more details at http://www.johandekoning.nl/index.php/2009/07/03/building-android-1-5-flashing-the-phone/).

fastboot flash boot boot.img
fastboot flash system system.img
fastboot flash recovery recovery.img
fastboot flash userdata userdata.img

And reboot the device

fastboot reboot

Result

Now you will have a non bootable donut version :) I will try a second attempt whereby I use less proprietary files to see if it boots (this suggestion is made in the same discussion about building donut http://groups.google.com/group/android-platform/browse_thread/thread/929aa624d2da63a7)

Proprietary patch is now part of Android source tree

When building Android 1.5 (cupcake) for the HTC Dream (Android Dev Phone), you had to apply patch (10899) with to command

repo download platform/vendor/htc/dream-open 10889/4

But this patch is now part of the android source tree (for the tree different branches: master, cupcake and donut). This will simplify the build process and therefore I will update the blogpost.

There is also the discussion with the different branches (which one to use). Inside the building Android 1.5 posts I use the cupcake-release branch. There is a good explaination about the different branches written by Jean-Baptiste Queru at http://groups.google.com/group/android-platform/browse_thread/thread/3670ed63a7d9e3ab Reading this post I decide from the development perspective to update the blogposts so that the cupcake branch is used.

While there is less development on the cupcake branch, I did not managed to get a working donut build. Will download the source code again in the coming days to perform another build. I will post the results on this blogpost.

New Android 1.5 branch available

Inside the Android repository there is a new branch available with the name cupcake-release. On the Android Platform Forum (http://groups.google.com/group/android-platform/browse_thread/thread/4853d33c28abb5f5) this is what being said about this new branch

cupcake-release is the branch that is used to build devices, whereas
cupcake is the branch that is used to build the SDK (we separate them
for a variety of reasons). Until 1.5r2 (mid-May) they were identical
for all practical purposes, so the distinction (which had existed on
our internal servers for a long time) didn’t get reflected on the
outside, but since mid-May they’ve been drifting a bit and we decided
to reflect the differences on the outside.

The current state of cupcake-release is a loose match for the CRC01
release that is being deployed to some consumer devices.

Admittedly, we still need to do a better job at matching the various
forms of the version numbers, especially for the device builds.

I updated the blogposts about building Android 1.5. It will now use the cupcake-release branch. So read the blogposts (again) if you want to build your own Android version based on this source.

Building Android 1.5 – Chinese translation

Weiguo (a visitor of this website) made a chinese translation of the building Android 1.5 blogpost serie. So if you prefer chinese you can find the details here http://www.hiapk.com/bbs/thread-7714-1-1.html

FYI This version and the chinese version are not updated together (by one person). So difference between the two versions will probaly occur