Jun 29 2014

Get ready for ART

Category: Android,Java,Linuxadmin @ 4:43 pm

ART will be the defacto VM for Android starting from L version. The VM is due for revamping as it has evolved slowly but now it is going full force. There is a very good introduction to understand ART from Google I/O and following are some of the key points that I’ve noted regarding ART:

* Doug Lea memory allocator will be replaced with a new ‘rosalloc’ (this is because Doug Lea’s implementation are not suitable for multithreaded implementation)
* ‘rosalloc’ allocated big memory (such as Arrays) to different area to make it easier for compaction by GC
* Sticky GC (less object to scan) and runs more frequently. Only scan objects that was created after the last GC
* Regular CMS collector will be run less frequently to avoid pauses (runs 1 times vs Sticky GC runs 5 times kind of ratio)
* New GC called ‘Moving GC’
* Boot startup time will be slower than before due to the optimization that needs to be performed in VM in order to reduce the GC pauses time.
* Zygote start or app start will be a bit slower than normal but we gain the increase performance during runtime because of the heavy weight lifting that are done upfront before the application are executed

Watch the video in full and you will be able to understand more in terms of what the whole thing means to you as developer. Overall I can say that in order to gain more performance there are few things that have to give such as faster startup and boot time which is bearable as considering those are not the important steps in using an app from user’s perspective. As long as user has a buttery experience with the app (audio,video,etc) developers should be thankful :)

Screenshot from 2014-06-30 08:37:39 Screenshot from 2014-06-30 08:38:39 Screenshot from 2014-06-30 08:39:13
Screenshot from 2014-06-30 08:40:42 Screenshot from 2014-06-30 08:47:55 Screenshot from 2014-06-30 09:08:51
Screenshot from 2014-06-30 09:09:42 Screenshot from 2014-06-30 09:10:43 Screenshot from 2014-06-30 08:49:59
Screenshot from 2014-06-30 08:51:52 Screenshot from 2014-06-30 08:52:48 Screenshot from 2014-06-30 08:54:14
Screenshot from 2014-06-30 08:56:25 Screenshot from 2014-06-30 08:57:17

Screenshot from 2014-06-30 08:58:11

Screenshot from 2014-06-30 09:01:09 Screenshot from 2014-06-30 09:03:14 Screenshot from 2014-06-30 09:04:53
Screenshot from 2014-06-30 09:05:57 Screenshot from 2014-06-30 08:44:09

Tags: , , , ,

Jun 24 2014

ODROID June 2014 Edition

Category: Android,Java,Linux,Open Sourceadmin @ 5:19 pm

ODROID June 2014 edition is out and for this edition I contributed article titled ‘Android Image Files: A Peek Into the Compressed Files That Make Android Portable and Lightweight’. The article talked about the different image files that are generated by Android build system that runs the ODROID board. Most of the Android devices out there uses the same image file and tools to unpack and repack.

Tags: , , , , , , ,

May 31 2014

Busybox Android-x86

Category: Android,Linuxadmin @ 6:14 am

Been looking at busybox lately inside Android-x86 and was thinking of using one of it’s built-in tool as it was not enabled by default. Looking around tutorials found out that it’s supposed to be simple, but apparently there are few steps that need to be done before you can enable and use the chosen tool.

NOTE: The code version that I’m using is bit different than what is available from http://git.android-x86.org/?p=platform/external/busybox.git;a=log;h=jb-x86

1. Inside the Android.mk of busybox you need to specify the busybox config that you want to use. It is advisable to just use the one you need, in my case I choose full-x86


2. The way busybox works is it reads configuration from a .config file (similar to Linux kernel). In Android-x86 it stores the configuration files inside file names as .config-<type> the <type> correspond to the BUSYBOX_CONFIG that we specify in step 1. In my case the config file that I need to modify is called .config-full-x86


Use a text editor to edit the config that need to be enabled

3. Before running step 3 make sure you have done the following command from the top level Android directory:

source build/envsetup.sh

lunch <device_target>

after completing the above 2 commands run mm command from the /external/busybox/ directory, the command will copy the edited configuration file to .config file and at the same time it will generate different header files that are required to make the new application made available when you execute it. This header files are required to be generated to avoid the error applet not found when you try to run the new configured application.

4. After completing the above 3 steps build Android-x86 as per normal build



May 28 2014

ODROID May 2014 Edition

Category: Android,Java,Linux,Open Sourceadmin @ 6:04 pm

ODROID May 2014 edition is out and for this edition I contributed article “Android Booting Process”. In this article I walk through the process of how actually Android boots up, this will help reader to give an insight on what are the different parts that come into play when booting the device running Android.


May 21 2014

sfdisk and Android-x86 installer

Category: Android,Java,Personaladmin @ 4:11 am

Been busy with putting together an automated installer to install Android-x86 on an Intel box. Android-x86 comes by default with it’s own generic installer which does fine for normal user but for us it was not suitable, so I need to rip it apart and put it together again. One of thing I learn in depth was about partitioning and the tools that are available. The installer application that comes with Android-x86 make extensive use of bash script which is different as normally in ARM world there is no installer as everything is defined beforehand, but not in x86 world. The good thing is the image file generated by Android-x86 includes linker and glibc which makes it easier to run any normal Linux tools. Out of the box the Android-x86 is using cfdisk but because we want to build an automated installer we decided to use sfdisk.

The sfdisk need to be packaged inside the installer image (install.img) so the 32-bit binary need to be copied to the bootable/newinstaller/install folder. sfdisk has got it’s own format which is very easy to use, following is the setup from my local /dev/sda

/dev/sda1 : start= 2048, size=195309568, Id=83, bootable
/dev/sda2 : start=195313662, size=273547266, Id= 5
/dev/sda3 : start= 0, size= 0, Id= 0
/dev/sda4 : start= 0, size= 0, Id= 0
/dev/sda5 : start=195313664, size= 39059456, Id=82
/dev/sda6 : start=234375168, size=234485760, Id=83

using this format it’s just a matter of defining what partition we want to create, the size and the type of the file system.

The one thing to remember any file that is inside the /bootable/newinstaller/install/scripts folder will be executed, so any bash script that need to be executed from the install directory need to be created outside the scripts/ folder.

NOTE: the sfdisk that you can use is the normal sfdisk that comes with your Linux installation. The reason why it works without any extra files (linker, glibc) is because those files are already made available inside the install.img file as the installer are running under a normal environment, and not inside Android


May 15 2014

Taobao Experience

Category: Hardware,Open Source,Personaladmin @ 8:18 pm

I’ve been curious (and a bit obsessed) lately with TFT and how it works, so have been scouring around the ‘net to find easy but affordable solution for Arduino and for Cortex-M family, so I decided to jump into building something simple for my own, and chosen RA8875 chip. The chip is not expensive but can’t be bought from Digikey or any other supplier, nor eBay or Aliexpress, but it can be bought from taobao.com. Looked around for a Taobao agent and tried using taobaoring.com which have got good reviews about and the best part about it I can pay via Paypal (without small charges), but save me the hassle.

Put the order in and the whole process from ordering to getting the items took me close to 9 days, the shipping took around 3-4 days period while the rest was taken for ordering, payment and packing, which is still very good. I used EMS for shipping as don’t want to take the risk with cheaper option for now, but future will probably use cheaper shipping for bigger quantity. Here are some pictures:

The only problem I notice was the way they wrap the IC, they did not wrap it thoroughly or pay attention about it as can be seen in the picture the RA8875 chip was out of the plastic black container that it was supposed to be on. I just hope the pins are not bend or anything otherwise it will be a pain to fix it.

IMG_20140516_122141 IMG_20140516_123519 IMG_20140516_123513
IMG_20140516_123319 IMG_20140516_123244 IMG_20140516_123235
IMG_20140516_123227 IMG_20140516_123218 IMG_20140516_123212
IMG_20140516_123200 IMG_20140516_122427 IMG_20140516_122413
IMG_20140516_122625 IMG_20140516_122538 IMG_20140516_122522

May 15 2014

Arduino Zero

Category: Hardware,Open Source,Personaladmin @ 5:09 pm

Been looking around for information about the chip that Arduino Zero is using – A06-0736 EDBG. This is actually chip that is use for debugging and programming the ATSAMD21 chip. Not a lot of information out there in the wild but found the following:

http://www.atmel.com/Images/Atmel-42096-Microcontrollers-Embedded-Debugger_User-Guide.pdf — in-depth information about the EDBG chip
http://avr.2057.n7.nabble.com/EDBG-is-up-for-testing-td20722.html — the EDBG protocol is made available in avr-dude

The EDBG chip is not available for public and searching Digikey and other suppliers turns nothing, which makes me think that the IC is probably used for Atmel vendors as a competitive advantage or other non-Atmel vendors. However, if we want to build something similar to Zero the best bet is to use an AVR chip instead of the A06-0736 to program the ATSAMD21 chip and for software use avr-dude to program it.


Apr 16 2014

My Android Journey

Category: Java,Open Source,Personaladmin @ 10:57 pm

Been getting emails and questions this year from a number of people asking me how did I get into Android and how do I know so much in terms of Android itself. The short answer I can say is “Persistent, long night hours and hunger for knowledge”, but I will outlined more in detail about the journey.

I don’t have any experience in embedded software or hardware, so when I found Android 2years ago it was like an alien for me, but that did not stop me. When I got my first Nexus S phone and found out that the source code was available for me to do anything I want with it, I was hook and that was the start of the journey. I’ve always been a very strong proponent for open source and putting open source project together by reading code and hacking it away has always been my strong point, so it was like a natural fit for me to start learning in depth about Android. In the beginning it was very hard to find where to start and what to do, so what I did was start lurking around XDA forums and start reading through hundreds of technical posting that was available discussing about the different areas of phones, operating system, bootloaders and many more topics. The journey was very bumpy as everytime I think I know something another thing I read point me to something else that I was not aware of, it’s like putting all the pieces together like a big jigsaw puzzle. I had the aha moment when I start hacking away the Huawei U8150 phone that I bought off-the-plan and start ripping it apart and start using the ROM that was made available by other developers and start making my own ROM for Gingerbread 2.3.7, from that point onward everything seem to fall into its own places and I begin to understand the whole process from the hardware side.

After learning about the phone systems and how the different component works with each other, I start digging through the Linux kernel side. Linux to me was not very alien but I don’t have idea how the whole different system works. This time I start lurking around the Linux Kernel mailing list and start comparing the different patches that was submitted by different developers/vendors to understand how the different subsystem works. The only book I read was the free Linux Device Drivers book as it contains a lot of more information if you want to learn about the kernel. Learning kernel is really harder than I thought but I was lucky enough to have learn and program in C/C++ before, so it helped a bit. Learning device drivers requires a different mind side than what I was used to and it was challenging at the same time frustrating, nevertheless I plough through. While learning kernel I also spend a lot of time learning the Android code and stack, was very fortunate to find a lot of reading materials from slideshare.net that explain a number of concepts and architecture of Android, and also vieweing Google’s video collection.

It took me close to 1.5 years of personal research to understand the complete hardware and software that runs on a device using Android stack. Even until now there are part of Android that I’m still learning and it’s the experience of learning something new that really excite me in Android world. Personally I think the most important thing to remember when embarking on a personal crusade to learn something new you must have the passion and willingness to learn, without this 2 key ingredients you only learn half of what you can really achieve. Managing time is very important as having family you must be able to split your time, and this requires high discipline and dedication on your part to be fair with everybody involved in the family.

Best advice I can give is have fun with what you doing and don’t let anything get in your way if you are aiming for something !

Tags: , , , ,

Apr 08 2014

4.3inch Arduino Experiment

Category: Hardware,Open Sourceadmin @ 6:50 am

buydisplay.com is a very nice website that sells a number of TFT, OLED and few other kind of displays. For the price that you pay for you get a nice product with good documentation, trust me there are China vendors that don’t provide you with anything, so getting something for the price that you pay is really worth it.

Few months ago I bought 4.3 and 7inch screen from buy-display.com and didn’t get the chance to play with it until last Saturday. The sole reason why I put it off was to find enough time for me to work with it because working with hardware are always twice the effort than working with software, mainly also I don’t have that many years experience with hardware under my belt and thus will take longer for me to troubleshoot. The board that I’m using uses RA8875 chip which is the exact same chip that Adafruit sell on their website and the best part is they have posted the Arduino library to talk to the RA8875 chip, which makes my life easier as I don’t have to spend too much time in converting the buy-display STC code that they have on their website. Since the library was written for 4-wire SPI so I need to prepare the screen board for this by soldering the side header pins. Due to my clumsiness I didn’t realised that I was soldering the header pins

IMG_20140405_104439 IMG_20140405_104450
IMG_20140405_104524 IMG_20140405_104513

and I found this out after comparing the soldered pins with pins from other board. Initially I thought I’m going to leave the pins where they are and thought of using FPC connector, but the pins were getting in the way, so need to remove the pins. Due to constrained space I was not able to unsolder the pins properly and in the process rip the track from the pins to the connector, which means that I can’t use the header pins anymore and I have to resort to using the FPC connector.

IMG_20140405_125319 IMG_20140405_125325
IMG_20140405_125335 IMG_20140405_125420

Luckily I bought extra FPC connector when ordering the screen so I can use that with the FPC cable that came with it. I have bought few FPC breakout board, which comes very handy in times like that, so it was now a matter of having a lot of patience in soldering the FPC connector to the breakout board. Once completed I hooked it up and nothing works. After looking around the datasheet I noticed that there was a paragraph that state need to set jumpers if need to use SPI as by default it was disabled and the part that is annoying is the jumper is a solder blob so need to remove some solder blob while adding new ones to some other jumpers.


After the jumper was set properly the screen works by flashing one time, and this is the time when I was at lost not sure what was happening. After digging around and using bit of common sense I realised that it could be a power issue as the serial console from Arduino was printing few messages and the connection dropped, which make me think something is not right. Luckily most of Arduino board accept external power supply, and grabbed a laptop power supply I plug it in to the my Arduino UNO and I can see the screen backlight works, but for 10sec as after that smoke came out from my Arduino, the power supply was too much for it. When I checked the output from the power supply noticed that it was rated for 19v, which was a BIG mistake for me to use it.

After taking 1 day break continue again and lucklily I have an Arduino Mega 2560 lying around, so grab that and change the pin number in the code but this time I carefully uses a 9v power supply and plug it in and I can see the backlight works nicely. I can see from the serial console that the messages are printed out perfectly without any problem which means that code works and the RA8875 chip responded to commands, now the question is why is it not displaying anything on the screen.

After few hours looking at the code, schematics and inspecting the board physically I accidentally touch the flex cable of the screen and noticed colour comes out on the screen, this is promising I thought.

IMG_20140407_221644 IMG_20140407_221637
IMG_20140407_221631 IMG_20140407_221453

After almost 30min playing with the cable looks like the FPC connector that connect the main RA8875 board with the screen was very loose. So I decided to tear things apart and try to place it properly.

IMG_20140407_224946 IMG_20140407_224952

The only way to fix the problem was to find the right position and hold it down with something heavy and tape it. I used a small foam pad and lots of kapton tape to tape it to the flex connector. The next thing I know the screen just works perfectly without any problem.

IMG_20140407_232538 IMG_20140407_232549
IMG_20140407_232605 IMG_20140407_232917

Tags: , , , , ,

Mar 29 2014

Dissecting Android Wear

Category: Android,Java,Linux,Open Sourceadmin @ 3:11 am

If you haven’t heard about Android Wear now will be a good time to head over this website to learn more about it, and if you have heard about it than hopefully you will learn something useful as what I’ve learned. What I’ve done is download and diassembled the Android_Wear_Beta.apk that is available from Google Play to studied how it works internally and also look at studying the logcat from the emulator. You will be surprised at how much information you can gather from logcat

Android Wear is a way for an external wearable device to get notifications from your mobile devices. There are 2 major components in the whole picture – the wearable and the mobile device, which translates to 2 different software – the wearable software and the mobile software (I’m going to call the wear application that runs on the emulator is called Wear).  The Wear emulator software stack runs the full Android stack which means that the wearable device will be running the same Android stack that your mobile is running (no idea if Google will change this in the future as this is something that they could change down the track, but I’m speculating they won’t). Put it simply the architecture is like a peer-to-peer architecture, the application that runs on the wearable will accept incoming data either through TCP socket or Bluetooth to display notifications and at the same time it will send command back to the mobile device when a certain activities are performed by the user – reply/open/speech gesture.

Following are the packages that can be found inside the .apk:


The code that does communication between the mobile device and wear is inside the com.google.android.clockwork.node package – socket and bluetooth management and listeners are all inside here.


Inside Wear there is a concept called ‘Asset’ object where this object travels between devices. This ‘Asset’ is what being displayed on the Wear device, the data class that encapsulate this ‘Asset’ is inside com.google.android.clockwork.data


One funny and memorable thing I found when cleaning the asset classes was when the asset failed to be delivered to Wear emulator the app shows up the data as follows


Communication Data Structure

This is the biggest chunk of the code inside Wear. Defining what information can be send back and forth between Wear peer is crucial and proper definition need to be done properly. Wear uses it’s own communication protocol by utilising extensively a project called micro-protobuf that resides inside the package com.google.protobuf.micro and project that are found inside Android source code called nano-protobuf. Looking at the transport mechanism that Wear will be using (Bluetooth) these 2 projects is the right candidate due to the bandwidth constraint. Was able to confirm that this is the right project by just replacing the disassembled code using this project and the app works just fine.


Looking into the Java classs structure for data that are relayed back to the Wear device it can be seen there are varieties of information that can be passed – route, image, flight, finance, currency, url, video, time, calculator and many more. There are few class that I find are related to advertisement that seems to piggyback inside the data structure that are being communicate to Wear device – namely YouTube information and vendor information (url, pricing information) that will be used to display onto the Wear device.


The other thing that I found inside the data structure is the possibility of passing information as part of an agenda things like car rental, flight information,


Voice & Speech

Speech by default is disabled in the Wear emulator image as there is a code that checked whether the app is running in an emulator. Speech is another big part inside Wear as it is understandable that this will be the main communication between Wear and the user. Haven’t got my head around how the speech will work, but one thing for sure it it using the OMX.google.aac.encoder codec to decode the inputstream

The other interesting package name that I saw com.x.google.common which I thought initially is a project from Google X, but after searching around found out that the same package is also used internally inside Google Glass


Few services are listed inside AndroidManifest.xml that handles bug report, submit feedback and phone handling. The phone handling service is interesting as it will notify the Wear that there is an incoming call and action will be performed based on user’s feedback from Wear.

On another side of the fence is the emulator that runs the Wear application. Extracting the emulator image the content is the same as normal emulator the difference that I can see is the application that is being hosted as can be seen below (ignore the -decode and _FILES prefix directories).



There are 3 main .apk that can be found inside the priv-app/ directory – ClockworkSettings.apk, ClockworkSetup.apk, PrebuiltClockworkHome.apk. On dissecting these 3 apps one of the .apk (PrebuiltClockworkHome.apk) represent resemblance to the application that inside Android_Wear_Beta.apk. The other interesting finding is inside the assets/ folder of the same apk we can see a binary file that resembles a file containing words that are recognised by the speech app in Wear


and sure enough there is a code inside PrebuiltClockworkHome app that read the file and interestingly the class is call HotwordRecognizerRunner.  This confirms that future wear devices will have speech recognition capability.



Next Page »