Recently, during a project, that involved code signing and custom deployment/updating the apk, I discovered that if an apk is debug-signed and gets downloaded, the installer will not update the apk, in fact, it will refuse to work with an installation error!
That was a rather simple error but to show that it is often overlooked from Google’s pages on the code signing, and going on a wild-goose chase wondering why the installer refuses to install. This article is just to serve a quick tip and short reminder!
There was a lesson to be learnt from it – if an apk needs to be distributed/published and has a custom deploy outside of the market, make sure it is release-signed before custom deployment, otherwise, frustration will step in and customers will not have the latest version.
A big gotcha I discovered, suppose you want to fire an intent to bring up a System Settings screen like this
final settingIntent = new Intent(Settings.xxxx);
final int INTENT_SETTING_ACTIVITY = 1;
startActivityForResult(settingIntent, INTENT_SETTING_ACTIVITY);
And accordingly to the SDK, there’s a return code used to check the status of the Settings activity, which looks like this in the call-back code:
@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data){
super.onActivityResult(requestCode, resultCode, data);
if (requestCode == INTENT_SETTING_ACTIVITY) {
if (resultCode == RESULT_OK) {
// Handle the good condition
}else{
// Handle the bad condition
}
}
}
Watch out!
That condition will fail – for some obscure reason the logic fails.
You can make it succeed by replacing the ‘RESULT_OK’ with a 0 and all should be okie.
This is by far the best blog posting I’ve ever read and the author explains a lot when it comes to producing a Android game called “Theseus and Minotaur”, from concept to production and the challenges along the way, such as using AdSense to market it, using Illustrator to polish up graphics, and a few nice tips also.
The story spans a year coverage from start to finish and documented along the way… There’s a lot of insight into it and a worthy blog post to keep coming back to.
Please do read it and let him know you appreciate his blog posting.
(The url has been bit.ly’ified, the real url is http://kerebus.com/2011/03/my-year-as-an-amateur-android-game-developer/?android)
Hello again, I have updated the code on github to make it a daemon server that will handle the simple and intuitive command set to control the FM Radio. As from the previous blog posting, the code has been revamped. I have discovered a thing or two about the Android NDK that made be go “WTF”…
Read more »
Cyanogenmod ROM 7 is currently undergoing testing and receiving huge feedback, currently for the Orange’s San Francisco/ZTE Blade, there’s still a lot to be ironed out, one of the notable features inherently missing is the usage of the FM Radio.
Read more »
Ok, to keep to the topic as per in the previous posting about how to compile the kernel for Android, I thought I’d share some scripts that I use myself to make life a bit easier….
- ak_stg1 – (Android Kernel, Stage 1), takes in parameters to create a boot.img.
- ak_stg2 – (Android Kernel, Stage 2), again, takes in parameters, copies the modules across to a specified directory.
- ak_stg3 – (Android Kernel, Stage 3), to create a clockworkmod updater script – work in progress….
ak_stg1 bash script.
#!/bin/sh
usage(){
cat << EOF
usage: $0 options
This script creates a kernel boot image for flashing with ClockworkMod 3.0.0.x [Stage 1]
OPTIONS:
-h Show this message
-k Location of recently compiled zImage
-r Location of ramdisk
EOF
}
invoke_mkbootimg(){
echo "$@" | awk '{ system($0); }'
}
KERNEL_ZIMAGE=""
RAMDISK_IMAGE=""
RESERVED_STMT="androidboot.hardware=blade console=ttyMSM2,115200 g_android.product_id=0x1354"
BASE_ADDR=0x2A00000
BOOTIMGF=boot.img
while getopts "hk:r:" OPTION
do
case $OPTION in
h)
usage
exit 1;;
k)
KERNEL_ZIMAGE=$OPTARG
;;
r)
RAMDISK_IMAGE=$OPTARG
;;
?)
usage
exit 1
;;
esac
done
if [[ -z $KERNEL_ZIMAGE ]] || [[ -z $RAMDISK_IMAGE ]]
then
usage
exit 1
fi
BOOTMAKE="$HOME/bin/mkbootimg"
BOOTMAKE_OPTS=" --base $BASE_ADDR --cmdline "\'"$RESERVED_STMT"\'" --kernel $KERNEL_ZIMAGE --ramdisk $RAMDISK_IMAGE --output $BOOTIMGF"
invoke_mkbootimg $BOOTMAKE $BOOTMAKE_OPTS
ak_stg2 bash script.
#!/bin/sh
usage(){
cat << EOF
usage: $0 options
This script copies the freshly built kernel modules for flashing with ClockworkMod 3.0.0.x [Stage 2]
OPTIONS:
-h Show this message
-k Location of recently compiled kernel source
-m Location of where to copy the modules to
EOF
}
KERNEL_PATH=""
MODULES_PATH=""
while getopts "hk:m:" OPTION
do
case $OPTION in
h)
usage
exit 1;;
k)
KERNEL_PATH=$OPTARG
;;
m)
MODULES_PATH=$OPTARG
;;
?)
usage
exit 1
;;
esac
done
if [[ -z $KERNEL_PATH ]] || [[ -z $MODULES_PATH ]]
then
usage
exit 1
fi
cat $KERNEL_PATH/modules.order | sed s/^kernel\//g | while read -r line
do
cp $KERNEL_PATH$line $MODULES_PATH
done
Now, no fuss, no muss, and less prone to errors on the command line. w00t. \o/
I promised the forum members over at Modaco, to develop a simple application designed for the ZTE Blade/Orange San Francisco handset. As the title of this blog post, it is exactly that.
A bit of background – I am constantly plugging in the cable into the handset for at most 2 minutes max, just to copy files on it, worrying about the battery getting messed up or shortening the battery life. I set about to pursue an alternative to allow plugging in the cable without charging the battery.
This is the application that is the simplest Android application, which selectively enables/disables the battery charging. It is now available on github repository for anyone to download and tinker with the code.
The binaries are available to install directly on to the handset.
Warning: Do not run this on any other handset!!!
Here are the steps required to build your own kernel for your Android handset. All commands are italicized and precedes the $HOME variable to indicate the directory.
Prerequisites:
- Linux box up and running that contains the full developers tool-kit such as bison, flex, automake, bash, gcc, git, curl, kernel sources of your choice, adb. Your mileage will vary in accordance to different Linux distributions of your choice so refer to your package manager if you do not have the above developer tools. I am using Slackware 13.0 distribution.
- A Android based handset, in my case, its Orange’s San Francisco/ZTE Blade, running Modaco Custom ROM 11, and also, that you are using a ROM Manager, in my case, I use Clockwork Mod recovery.
- Tools to extract the kernel from your android’s boot image, namely, split_bootimage.pl which can be found here.
- Java – You will need Java 1.5 runtime and sdk, if you ever want to build a Android release from the Android Open Source (AOS), crucially, 1.5 is required for releases up to Froyo (Eclair, Donut, Cupcake releases), Gingerbread and upwards requires Java 1.6 or better. The thing about it is, it’s difficult to obtain the official 1.5 from Sun since Oracle took over….
- That you have $HOME/bin in your $PATH, this is where the split_bootimg.pl and repo, mkbootimg, testsign.jar will be found in.
Steps:
- Obtain the Android SDK from the official download page here, in my case, I installed it into $HOME/ANDROID.
- Pull down the entire Android Source tree by following the instructions from here. I installed this into $HOME/mydroid, this is a clone of the current source tree as maintained in the public repository. Be warned, this will take a while depending on your broadband connection, the source is well over 3.5Gb. You need to follow the instructions there, this step is required so you could obtain the necessary tools to build the kernel.
- Now when that’s done, I cloned the repository residing on github into $HOME/repository.
- $HOME/repository: git clone https://github.org/ZTE-BLADE/ZTE-BLADE-2.6.32.git
- Obtain the original ROM that is used in your handset and unzip the ROM into $HOME/myrom.
- $HOME/myrom: unzip -d my_rom.zip
- There should be two directories – META-INF and system. The one that we are interested in is boot.img.
- Using the split_bootimg.pl, we extract the information from boot.img:
- $HOME/myrom: split_bootimg.pl boot.img
- There should be two files, boot.img and boot.img-ramdisk.cpio.gz(your mileage will vary as the ROM may be different…) boot.img is the actual kernel, the ramdisk.img is the image that is loaded into ram which the kernel runs the initialization of hardware etc.
- Plug in your handset and using adb, obtain the kernel’s configuration
- $HOME: adb pull /proc/config.gz $HOME/androidconfig.gz
- Go into the kernel’s sources and issue the following commands:
- $HOME/repository/ZTE-BLADE-2.6.32: zcat $HOME/androidconfig.gz > .config
- Now, we need to set up a special flag to indicate that we’re cross-compiling to the handset’s chipset architecture $HOME/repository/ZTE-BLADE-2.6.32: export CCOMPILER=$HOME/mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-
- You can at this stage, if you’re feeling adventurous, to browse through the configuration of the kernel via the kernel’s menu: $HOME/repository/ZTE-BLADE-2.6.32: make menuconfig
- To build the kernel, issue this, $HOME/repository/ZTE-BLADE-2.6.32: make ARCH=arm CROSS_COMPILE=$CCOMPILER
- The above step will take a while…
- The kernel will reside in $HOME/repository/ZTE-BLADE-2.6.32/arch/arm/boot/zImage
- Also, watch out for the optional kernel modules, this can be found in $HOME/repository/ZTE-BLADE-2.6.32/modules.order
- Navigate back to the $HOME/myrom, and go into the system/lib/modules directory:
- cat $HOME/repository/ZTE-BLADE-2.6.32/modules.order | sed s/^kernel\//g | awk ‘{ system(sprintf(“cp $HOME/repository/ZTE-BLADE-2.6.32%s .\n”, $0)); }’
- What we have done here, is copied the freshly built optional kernel modules here.
- Navigate back to $HOME/myrom and copy the freshly built kernel image here.
- $HOME/myrom: cp $HOME/repository/ZTE-BLADE-2.6.32/arch/arm/boot/zImage .
- Now, to recreate the boot image, this part is extremely important, ensure the hexadecimal address is correct as this is where the kernel will get loaded on the handset in the region of memory as specified by the hexadecimal address. Check around first before doing this, as when you re-flash the new ROM, the addresses will conflict and worst case – the handset will refuse to boot. For the Orange’s San Francisco/ZTE Blade, the address is 0x2A0000:
- $HOME/myrom: mkbootimg –base 0x2A00000 –cmdline ‘androidboot.hardware=blade console=ttyMSM2,115200 g_android.product_id=0×1354′ –kernel zImage –ramdisk boot.img-ramdisk.cpio.gz -o boot.img (Thanks to hecatae from blade.modaco.com for the correction by pointing out that –cmdline was left out – whoops!
)
- Next step, re-zip up the ROM:
- $HOME/myrom: zip -r my_new_rom.zip META-INF boot.img system
- Finally, we need to re-sign the newly created ROM:
- $HOME/myrom: java -classpath $HOME/bin/testsign.jar testsign my_new_rom.zip my_new_rom_signed.zip
Now, copy the file my_new_rom_signed.zip to your SDCARD on your handset and reboot, using your ROM manager to install and flash the ROM. In my case, I can tell Clockwork Mod Recovery to install the zip and flash the system.
There’s a site that is remarkably similar to the StackExchange site format, such as StackOverflow.com, called ForceClose, a lot of interesting questions that is geared and orientated towards the Android system. A Q&A site specifically for the Android platform.
Incidentally, the acronym that is bandied around FC means exactly that, Force Close, a dreaded programming error that causes the application to crash and a dialog box appears prompting to Force Close the application.
I highly recommend this site, plus the subscription is worth it IMHO – CommonsWare, where you get 3 books for a subscription for a year, in which you can download it and learn at your own pace… it’s not all that difficult, if you’re new to Java, well, there would be a learning curve. If you come from a different programming language, you will easily pick up the pace of the tutorials and explanations…
At $40 for a year, including updates on the books.. Excellent treasure trove!
In short – highly recommended. Cheers to Mark Murphy of CommonsWare for his time in writing those books! \o/
Well, after taking a hiatus from the blogging sphere for a while, I thought I’d send out my New Year Greetings to all readers of this blog, sure it’s being a while but over time I will tell what’s been happening…
Well, 2011 is here, this year is going to be exciting… there’s new things happening in the Samsung bada world, and also in the android world…
Will let you on to a secret, I am in love with Android… in a geeky nerdy way that one could describe, the beauty and simplicity of it plus the fact combined with the Linux kernel, this makes it a truly a geeky system, the joys of finding out so much on what can be done with it… over the coming few days I will be blogging about all sorts on Android, and not forgetting Samsung’s Bada…
Til then… have fun and practice safe hex \o/
Well, as I have blogged about this on previous occasion, I can now breathe a sigh of relief and voted to close this site proposal as the crew (Hi Wit, Nour
) over at badadev.com has come up with their own innovative site aptly named Ask Badadev, so thanks to GeekyBob, and the rest of the pirate crew, to those who have joined in and gave their support in the site proposal.
It is a mixed blessing in disguise now we have a superior bada community there now @ ask.badadev.com…
Long may it last and wish every success in that adventure on the bada seas….
arr arr
Recently I was tackled with a task to be able to put a thread into the background, and from the main UI thread, to be able to pass a message into the thread, this left me stumped… Read more »
Now that there’s three different SDK’s to download, the script will have to be modified to take into account of the different directory names used, for SDK 1.0.0, some, if not all, have a ‘-stable’ at the end of the directory name, now that there’s what, currently:
- 1.0.0 SDK
- 1.0.0b SDK
- 1.1.0b SDK
so it means, the 1.1.0b will have a different name other than ‘-stable’ which would imply unstable? and also heavy lifting will be required to use the script, perhaps, an external file in which the script can read in the variables for each directory without having to modify the main script itself…
stay tuned and feel free to put in a pm in github’s project page if you want to post issues as such with the script itself.
What a confusing subject matter in this Android arena when it comes to ListActivity? Read more »
I have opened up the project on github that is a replacement bash script intended for Linux, to ease building the Codesourcery’s cross-compiler bada toolchain that targets the Samsung Wave. Read more »
Samsung, if you are reading this, this is my open letter to you. Read more »
Ever since Samsung released the Wave handset, with 1Million (Global sales) sold in June, and yet 1Million sold in Europe alone… with its new OS called Bada, it is still very much in a stage of infancy, with a neat SDK using C++, as I am registered on six forums about Samsung Wave and the Bada platform, I have noticed that the questions asked, are duplicated across those forums, which inspired me to come up with a novel solution… Read more »
Samsung hosted a developer’s challenge – to come up with an application that targets the Bada platform. There’s two phases, the first is the Simulator Phase, in which the application must work in the simulator and the submission date was set in stone for 31st August 2010. Read more »
If you are an owner of a Wave S8500 handset – do not be tempted to do down the route in flashing with unofficial firmware nor trick Kies into thinking your handset is in need of an update… Read more »