This is my tech diary. I try to write about my hobby projects to remember what I've done for reference and for fun. Hopefully techy people with similar interests can benefit as well.
I wrote a clone of the game Reversi/Othello for Android three years ago and it actually made some progress on Google Play (Market as it was called then). It was downloaded nearly 1000 times and a lot of players seems to have enjoyed it because I could see in the highscore lists and the Analytics statistics that they spent quite some time on trying to beat the AI to gain access to even harder levels.
Unfortunately, the name Othello Legends was a bad choice since it was trademarked. That meant that after 6 months the game was suspended from Google Play. Since I put quite a lot of effort into the game it is a shame that it disappeared and I have now done a refactoring to the new name Porthello Legends :-).
My Android tablet died last summer and all I got to test with is an pretty old HTC Desire which the game seems to work fine on. It would be interesting to get feedback on how the game performs on newer phones/tablets as well.
A first version of Othello Legends is now published to the Android Market, check out https://market.android.com/details?id=se.noren.android.othello! The game is the classic Othello/Reversi with a twist for unlocking harder levels when beating opponents. Compete with other players by increasing your total scores.
The aim of the project was to learn how to build an Android application of some complexity with features like OpenGL rendering, integration with backend server, Google AdMob for serving ads, Google Analytics tracking of application usage, SD storage and possibility to run on both phones and tablets with appealing layout and performance.
Lesson learned 1 - 3D
Accelerated 3D graphics is hard even if you're experienced with desktop OpenGL. To make OpenGL ES work on all devices requires a lot of testing which you can't do without devices. And generally debugging accelerated graphics in the Android emulator is no fun. Therefore, use a library to leverage yourself from the low level details. I looked into jMonkeyEngine, libgdx which are general and large frameworks with quite massive APIs which probably would have worked out great but seemed to have some threshold for a newcomer to overcome.
In the end I decided to work with the more limited jPCT which has worked out very well. A stable and reliable library with an active community. jPCT handles 3DS-models well which makes it easy to create environments via some tooling.
I used the open source modeller Blender which is free and has support for all you would need as sculpt modelling and texture UV coordinate tooling. Antother appealing feature of jPCT is that is developed both for Android and as standard Java for desktop so you can port your apps between them without great effort.
Lesson 2 - Revenue model
If you haven't decided whether charging for your app or using ads I can only say that Ads are easy! If you're familiar with Google AdSense for creating ads on your websites you'll find it intuitive to work with Google AdMob. If you have an Android Activity made up of standard Android layouts you can simply add an AdView view to your layout and the Ad library will populate the container with ads.
Compared to the standard Google AdSense interfaces for managing and following up your ad reports AdMob is more limited and not as well polished but who cares? Will revenues be larger with mobile app ads than with ordinary web ads? I'll come back later on that.
Lesson 3 - Mobile is not desktop
Memory is scarse when you go down the 3D pathway. I early discovered that you must be cheap on your textures and the polygon levels of your meshes. The devices have no problem with rendering polygon heavy meshes with impressive framerates, but you soon run out of memory if you don't do clever texture unloads when you don't need them. My lesson here was: Create a game engine with strict modules for each game state so that you can be sure to deallocate all resources when you change state and use more low res textures than you usually would.
Lesson 4 - Tune your app after how your users use it
So in this game each level becomes more difficult and it seems like a good tuning approach to make the difficulties of the first two levels easy enough to to make sure all players passes them. After that it should be exponentially more difficult. How to know how your app users are doing? I notices that the game was way too hard when I tried it on people. Some sort of surveillance would be nice without intruding in the users' privacy. Lesson here is to not invent anything new. By using Google Analytics you can track how users travel around in your application by marking different states as you would use Google Analytics to mark web pages in a web site to follow traffic around your site and adapt your game to how users respond.
Lesson 5 - Android is not Java
Another more depressive lesson learned is that when you plan to reuse some Java library first make a Google search whether anyone has had difficulties using it on the Android platform. For example the JSON marshaller Jackson proved to be hard to use.
My current Android application project is starting to make sense. Unfortunately it crasches after a few levels of playing due to java.lang.OutOfMemoryError. Up to that point I hadn't put much thinking into the memory model of Android applications and simply consumed memory without hesitations. I've now been forced to rewrite some critical parts of the application and i thought I'll write a few words to remember the most useful tools I came across.
First of all, Android apps have small heaps. And with different sizes, it's up to the vendor of the device to decide. Here's a few numbers I came across:
G1 = 16 Mb
Droid = 24 Mb
Nexus One = 32 Mb
Xoom = 48 Mb
GalaxyTab = 64 Mb
So you see that allocated heaps are far from using the entire RAM of the devices since no application should be able to clog the system. The natural approach to solving a memory problem would be to increase the heap but that is not so easy. If you have a rooted phone you may edit
/system/build.props
and set the heap size via dalvik.vm.heapsize=24m
Or, if you're running on a tablet (3.x) Android version there is a manifest setting to ask for a large heap
but that is no guarantee and you will instead be punished with longer GC cycle times.
On the other hand, changing the VM heap size in your emulator is easy, and could be a good thing in order to verify that your app works on devices with smaller heaps. To do that, fire up your Android SDK and AVD Manager and click edit on your virtual device. Under hardware, there is a setting Max VM application heap size.
So the conclusion is that you have to live with small heaps and limited memory. How to get an estimate of your consumed memory and how much there is available then?
Run your application in the emulator or connect your real device via USB and use the Android Debug Bridge (adb). It's located in your Android SDK tools folder.
To dump memory info for all your running applications use $>adb shell dumpsys meminfo
To understand this table we must know that you have a managed heap, dalvik, and a native heap. For example some graphics are stored in native heap. But important, it is the sum of these heaps that can not exceed the VM heap size. so you can't fool the runtime by putting more stuff in either native or managed heap. So to me, the most important numbers are the number under dalvik and total above. The dalvik heap is the managed VM heap and the native numbers are memory allocated by native libraries (malloc).
You'll probably see these numbers fluctating each time you run the command, that is because objects are allocated by the runtime all the time but GCs are not run particularly often. So, in order to know that you really have garbage collected all unused objects you must either wait for the Android debug log in logcat to say something like GC_FOR_MALLOC or GC_EXTERNAL_MALLOC or similar to that which indicates that the GC has been invoked. Still, this does not mean that all unused memory has been released since the inner workings of the GC might not have done a complete sweep.
You can of course ask for a GC programmatically by System.gc();
But that is never a good option. You should have trust in the VM to garbage collect for you. If you for example want to allocate a large memory chunk the gc will be invoked if necessary.
You can force a gc using the Dalvik Debug Monitor (DDMS). Either start it from Eclipse or from the ddms tool in the Android SDK installation folders.
If you can't see your process right away, go to menu Actions and Reset adb. After that you can turn on heap updates via the green icon Show heap updates. To force a GC, click on Cause GC.
If you wish to monitor the memory usage programmatically there are a few APIs you can use.
ActivityManager.getMemoryInfo() can be used to get an idea of how the memory situation is for the whole Android system. If running low on the gauges you can expect background processes to be killed off soon.
For example, to see how much memory is allocated in the native heap, use: Debug.getNativeHeapAllocatedSize()
So back to DDMS. This tool can also create heap dumps which are particulary useful when tracing down memory leaks. To dump the heap, click on the icon Dump HPROF file. There are many tools for analyzing heap dumps but the one I'm most familiar is the Eclipse Memory Analyzer (MAT). Download it from http://www.eclipse.org/mat/.
MAT can't handle the DDMS heap dumps right away, but there is a converter tool in the Android SDK.
So simply run this command.
Then you can open the converted heap dump in MAT. An important concept here is retained size. The retained size of an object found in the heap is how much memory could be freed if this object could be garbage collected. That includes the object itself, but also child objects which no other objects outside of the retained set has references to.
MAT gives you an overview of where your memory is allocated and has some good tooling on finding suspicious allocations that could be memory leaks.
So to find my memory leak, I used the dominator tree tab which sorts the allocated objects by retained heap
and I soon discovered that the GLRendered object held far too many references to a large 512x512 texture.
The tool becomes even more valuable when the leaking objects are small but many. The dominator tree tell you right away that you have a single object holding a much larger retained heap than you would expect it to.
If you want to learn more, check out this speech by Patrick Dubroy on Android memory management from Google IO 2011 where he explains the Android memory model in more detail.
I've been working with persistent state between launches of my Android application and wanted to easily inspect my application data between launches. I discovered the power of the Android Debug Bridge or adb tool. In short a dev tool that lets you hook up against a running Android simulator.
You'll find it in your sdk folder under platform-tools. On my machine: C:\Program Files (x86)\Android\android-sdk\platform-tools\adb.exe
A few handy commands:
- List currently running devices: >adb devices List of devices attached emulator-5554 device
- Launch a terminal shell against a running device >adb -s emulator-5554 shell
Then you can do your ordinary linux stuff like cd, ls, cat etcetera to get to know your Android device.
My happiest discovery was that the preference file you fetch and save via the SharedPreference API: SharedPreferences settings = getSharedPreferences("OthelloLegendsPrefs", 0);
are located under the path /data/data/se.noren.android.othello/shared_prefs/OthelloLegendsPrefs.xml
and is a simple XML file which you can inspect and edit.
So, to pull a file from the simulator to your development computer >adb -s emulator-5554 pull <remotefile> <localfile>
Similarly, to upload a file to the device >adb -s emulator-5554 push <localfile> <remotefile>
I'm spending some spare time on an Android Reversi game which could need some performance tuning. After figuring out how the tooling works for Android profiling it works like a charm.
There are two ways to profile an application, using the debugging server DDMS or manually decide which parts of the code base are interesting for inspection. DDMS could be useful if you are inspecting code you might not be able to recompile. DDMS can also be used to inspect memory usage and more.
The easiest approach however is to use the debug interface provided by the Android API in your sources to specify when to start generating profiling information and when to end.
public int[] alphabeta(Board b, int maxDepth, long maxTime) {
Debug.startMethodTracing("othello_profiling");
// Here goes code to profile
Debug.stopMethodTracing();
return result;
}
Run your program and you'll see in the VM logs when the profiler kicks in. (As usual the performance of your app in the emulator will sink to the bottom when profiling is enabled)
Now you got your profiling info written to the SD card of your Android emulator device. If you run into permission issues when writing to the SD card, add something like this to your Android Manifest.
Voila! You get a profiling view similar to what you get from common profilers like JProfiler, hprof etcetera. Here you can see each methods execution time and which parents and children methods it has connection to and much more.
Theres more you can do with the trace file. Traceview can also show you each threads exectution and calls in chronological order. You can simple zoom in on the interesting parts.
You may also want to try the tool dmtracdedump to create graphs over your call stack. See the Android documentation for more information.
