2014-09-28

Build PA (Paranoid Android) for Nexus 5 (hammerhead) in MacOSX Mavericks

Thanks for this post in XDA [GUIDE] Setting up a build environment on OSX 10.9 Mavericks so that I can build PA on my old Macbook Pro without many troubles.

Preparation

Install Xcode/JDK/Homebrew as the XDA post mentioned. However, the installation of Xcode is not really necessary. It saves you some work, though. The CommandLineTools is enough to finish the build if you manually set the variable mac_sdk_version in build/code/combo/HOST_darwin-x86.mk instead of obtaining it from xcodebuild.

Download prebuilt kernel/proprietary files for hammerhead

Kernel

Sync or download from Google site

 git clone https://android.googlesource.com/device/lge/hammerhead-kernel

This is a long process. If you don't want to waste time, just download the vmlinux.bz2 and zImage-dtb.

device/lge/device.mk


Set TARGET_PREBUILT_KERNEL to your download location.


Proprietary files

Just download and extract.

build/core/combo/HOST_darwin-x86.mk

The first change is to add 10.9 to the variable mac_sdk_verions_supported.


The second change is to instruct build system to use the correct toolchain (missing stdarg.h in 10.8+). This is different from what was recommended in the XDA post.




The third change is to use gstat instead of stat.

# $(1): The file to check
define get-file-size
GSTAT=$(which gstat) ; \
if [ ! -z "$GSTAT" ]; then \
gstat -c "%s" $(1) ; \
else \
stat -f "%z" $(1) ; \
fi
endef

Build

As https://github.com/AOSPA/manifest says,

./rom-build.sh hammerhead

2014-08-13

The project-based environment

I've been tweaking the environment for my work, mostly programming, for years. I don't use any fancy IDE or desktop environment. Some of my co-workers use Citrix Client and this is actually recommended by our IT department. But, considering the just acceptable performance of connecting to remote sever, I am much more inclined to use terminal and switch to Citrix if I need to use any GUI application.

It is common that a company need to maintain several versions of a product for years and programmers need to port changes to different branches. Sometimes, a programmer need to run same experiment on different version to observe behavior or performance differences. It would be much safer if these runs are separated by different terminals even at the same machine.

The workspace-based flow is probably the most suitable one I've found. My configuration is pretty simple but effective. It's based on screen/tmux/emacs and submitted on GitHub. 

Check it out on Workspace-based configuration


2012-02-04

Implement an AppWidget for BozaAlarm - Part I: Limitation

Today, I released BozaAlarm v4.10 to the Android Market. What's new in this version is the simple AppWidget to display the next enabled alarm.


Here, I'd like to talk about how I implemented this simple widget. Before I go too far, you probably need to take a look at least these two topics,

  1. AppWidgetProvider
  2. App Widget Design Guidelines
Just as I said before, there are some limitations in App Widget design and understand these should save you some time.

Basically, the Launcher process hosts AppWidgetHostView for each App Widget and talk with your process through RPC calls. You can image there are many RPC (binder) calls between Launcher and your process. That's why you will use RemoteViews to package your update actions in your process and apply them on the App Widget on the Launcher side. In fact, the RemoteViews is implemented as Command pattern in software terminology.

Now, you can imagine why AppWidget design is so restricted.

Moreover, because it's always unsafe to load classes from other process in a process, you're not allowed to use custom classes in your widget layout. Only built-in widget classes can be used in your layout xml file and only methods tagged by RemotableMethod in these classes are allowed.