Jeff Mixon

Just another WordPress site. Literally.

RSS Feed

SmartSquare: An open-source Foursquare app for Android and the Sony SmartWatch

I purchased a Sony SmartWatch long before rumors of an [insert any major tech company name here] watch began. I’ve always had an affinity for watches so I naturally couldn’t resist picking up an Android-related “smart” watch that I could build apps on and for. It was like my calculator watch in middle school on steroids.

The two immediately obvious use cases for such a watch were an Rdio controller and Foursquare. With the latter, I wanted to be able to check-in straight from my watch–no need to whip out a phone, unlock the screen, find the app, etc. etc. Thus, several months ago I wrote a free app called SmartSquare that let you do just that.


I’ve now decided to go ahead and release the source code to SmartSquare under the GPLv2 open-source license. You can grab the source from my GitHub repository. Hopefully the project will be useful to some other Android engineers out there looked to get started on SmartWatch app development.

Examining build.prop tweaks for Android ICS: A comprehensive guide (Part 2)

Screenshot of a build.prop file on a Samsung Galaxy S3This is the second part of my ongoing series looking at common build.prop tweaks for Android ICS and whether or not they can make any real impact on your device. I highly recommend reading Part 1 first if you have not already done so. This article covers a little bit of everything: speed tweaks, battery tweaks, and privacy tweaks will all be looked at in-depth and my conclusions presented in MythBusters fashion.

dalvik.vm.checkjni, and ro.kernel.checkjniBUSTED x3
These properties are usually lumped into the general “make things run faster” tweak category. First, let me say that ro.kernel.checkjni does not exist and will do nothing. However, setting either dalvik.vm.checkjni to “true” or to 1 will enable JNI Extended Checking:

property_get("dalvik.vm.checkjni", propBuf, "");
if (strcmp(propBuf, "true") == 0) {
    checkJni = true;
} else if (strcmp(propBuf, "false") != 0) {
    /* property is neither true nor false; fall back on kernel parameter */
   property_get("", propBuf, "");
   if (propBuf[0] == '1') {
       checkJni = true;

The JNI is the Java Native Interface and is the mechanism by which Java applications and services can interact with native C/C++ components. When Java applications invokes the JNI, very little safety checking occurs to make sure that the Java application is making valid and appropriate requests to the JNI. JNI Extended Checking performs extra checks to catch coding mistakes before it actually attempts to execute them. The Dalvik documentation has this to say:

“The extended JNI checks will cause the system to run more slowly, but they can spot a variety of nasty bugs before they have a chance to cause problems.”

Google plainly admits that enabling Extended Checking will incur a performance penalty. Clearly, you should not enable JNI Extended Checking unless you are debugging a JNI application. But what about disabling it? Just a few lines above the previous code block, we see this:

char* stackTraceFile = NULL;
bool checkJni = false;
bool checkDexSum = false;

The checkJni default value is already false, and rightly so. Setting either property to false or 0 in your build.prop is simply redundant and will have no added effect on your device.

This property purports to significantly increase your battery life by putting signaling your device to use a better power mode when your phone is idle. Recommended values range from 0,1,4 with the most common be 1. Battery tweaks are very contentious topics, so I am going to be extremely thorough on this one. While I find no references to this property anywhere in the ICS code base (more on that later), I do realize this is a configuration property referenced in the Linux/Android kernel. Indeed, if I open up source for the SGH-T999 (Samsung Galaxy S3) I can see the following logic in the pm.c file:

static int msm_pm_sleep_mode = CONFIG_MSM7X00A_SLEEP_MODE;
module_param_named(sleep_mode, msm_pm_sleep_mode, int, S_IRUGO | S_IWUSR | S_IWGRP);

That line basically sets up the parameter named sleep_mode to be assigned into the msm_pm_sleep_mode variable. Some of you familiar with the Linux kernel probably already see the problem here, but let’s keep looking at this for a moment. What about the widely recommended value of 1? In the header for this class, we see the following:

enum msm_pm_sleep_mode {

This enum is used to represent valid values for the msm_pm_sleep_mode variable we saw above. Since enums are zero-based, we know that MSM_PM_SLEEP_MODE_POWER_COLLAPSE_SUSPEND has a value of 0 while MSM_PM_SLEEP_MODE_POWER_COLLAPSE has our recommended value of 1. Power Collapse is also know as Deep Sleep and is a mode you absolutely want on a mobile device. You don’t need to be an embedded hardware engineer to figure out that Suspend Power Collapse is likely going to offer you more battery savings than just Power Collapse on its own at the cost of a time penalty each time the device has to wake and suspend.

So where did pm.sleep_mode=1 ever come from? It’s hard to know for sure, but this commit by Google to the Android kernel in 2008 could be a clue:

diff --git a/arch/arm/mach-msm/pm.c b/arch/arm/mach-msm/pm.c
index 2547279..ed2f112 100644
--- a/arch/arm/mach-msm/pm.c
+++ b/arch/arm/mach-msm/pm.c
@@ -28,13 +28,13 @@
 #include "clock.h"
 enum {

This commit moves MSM_PM_SLEEP_MODE_POWER_COLLAPSE_SUSPEND from the 1 index to the 0 index. Prior to this commit, pm.sleep_mode=1 might have actually selected the Suspend Power Collapse mode. After this commit, however, it actually selects a mode less battery efficient. This underscores the dangers of Google search and forums where tweaks get copied over and over again when they actually stopped working a long time ago.

So we now know what pm.sleep_mode does and what the values mean, but there are two glaring issues with this property still. One is that this setting does not seem to exist on non-MSM (Qualcomm) chipsets. This means that your shiny Tegra based devices (HTC One X, Nexus7, etc.) do not have this setting. I looked at the One X kernel source specifically and did not find any reference to this setting.

This second issue is, as I mentioned earlier, that this property does not exist anywhere in the ICS code base. This means that adding this value to your build.prop will have no effect at all. This parameter is a kernel parameter and will only work when passed directly to the kernel on boot. Modules in the Linux kernel have the ability to register parameters which can be passed via the kernel boot string to the specific module in ${modulename}.${paramname} fashion. For example, all this code we’ve been looking at is contained in the “pm” (Power Management) module. In the first code snippet, we see it registering a parameter named “sleep_mode”. This is where the pm.sleep_mode syntax originates. You would have to repackage your kernel’s ramdisk with this parameter for it to have any effect on your device.

On the Galaxy S3, the default value is already set to use Suspend Power Collapse in the kernel configuration file. This is likely true with most modern Qualcomm-based devices. Other devices don’t even have this property and might its own implementation of Power Collapse that is potentially controlled by entirely different parameters. As a general rule, all devices are going to be optimized for battery efficiency above almost everything else, so if that’s what you’re worried about the most, you should be extremely hesitant to change any of these kinds of settings anyway.

This property purports to disable sending data to the Google Checkin Service. The Google Checkin Service is part of the Google Services Framework and is responsible for sending various log files from your device to Google presumably for support related purposes. Along with the log files, the Checkin Service sends pretty much every detail about your device, including your device type and software version, ESN/IMEI, MAC address, and more.

In light of this information, it sounds great to be able to disable the transmissions of such reports. Unfortunately, ro.config.nocheckin does not do this. In fact, it doesn’t do anything at all, at least on public releases of the Android SDK and Google Services Framework. The notion that it did likely came from the fact that this property is in fact mentioned in the core Android Makefile:

# TODO: this should be eng I think.  Since the sdk is built from the eng
# variant.
tags_to_install := user debug eng
ADDITIONAL_BUILD_PROPERTIES += ro.config.nocheckin=yes

What’s happening here is the Makefile is basically setting up the build.prop file for the Android emulator that will be packaged with the SDK. Indeed, this property is defined in the ICS emulator build.prop file. This property is not mentioned anywhere in the ICS code base which makes sense considering that the Google Checkin Service is located in the separate and proprietary Google Services Framework. Although there is no source code available for the GSF, I reversed-engineered the ICS version of GSF:

Google Checkin Service Reversed Engineered

In fact, I reverse-engineered the Google Services Framework for Jelly Bean, ICS, Gingerbread, and Froyo. I also reverse-engineered the Google Login Service, Android Market/Play Store, and the source code for the QEMU-based Android emulator itself. Not only was there no reference to ro.config.nocheckin anywhere, there also appeared to be no mechanism at all to turn off the transmission of Checkin reports.

One thing I did find in my investigation of this property, however, is that HTC apparently has their own Checkin Service that mimics the Google Checkin Service. The HTC Checkin Service appears on many HTC phones and I pulled the APK off a One X, reversed-engineered it, and found this:

HTC Checkin Service

The HTC Checkin Service can be disabled with the property set to 1. I suspect this property is where the misconception that the Google Checkin Service could be disabled originated.

I have not seen any real description associated with this property, but judging from its name I assume people think it disables some kind of logging mechanism. This property does not appear anywhere in the ICS codebase, but I saw it listed in mostly HTC build.prop files, so I tore apart a stock HTC Sensation ROM and finally found this property buried in the ROM’s services.jar file:

private static boolean getForceDisableULog()
  return SystemProperties.getBoolean("profiler.force_disable_ulog", false);

The “ulog” referred to in this property is an HTC-specific service that HTC calls the “User Behavior Logging Service”. This service is centered around tracking user behavior related to the HTC Sense launcher. The HTC ULog tracks some basic things like the number of ANRs and/or crashes, but it also potentially tacks some pretty scary things like your wallpaper selection, your installed apps, and your location.

Things looked promising for this property at first. However, it soon became apparent that while this property is in fact referenced several times in various HTC-related services, it is in fact never used. A configuration class used to define the value of these parameters has this in its constructor:

if (!Build.TYPE.equals("user"))
   profile_force_disable_ulog = false;
   profile_force_disable_ulog = true;

And in the UserBehaviorLoggingService we see:

if (ProfileConfig.getProfileForceDisableUlog())
  this.mEnableHTCUBLog = false;
  Utils.logD("UserBehaviorLoggingService", "HTC_UB is disabled in UserBehaviorLoggingService");

A whole series of configuration properties are set by their respective build.prop value, yet the profile_force_disable_uload variable is assigned based on the build type name instead. This is strange since everything else is set up to use the build property. It is possible that on older HTC devices this property actually works and that HTC changed it since then so that users could not disable the service themselves.

It is important to reiterate that this is an HTC-specific property. If you are not running an HTC phone (with Sense), then you do not have to worry about the ULog service. However, even on an HTC device, setting profiler.force_disable_ulog will do nothing. It appears the only way to disable the ULog service would be to change your to something other than “user”, but I do not know the ramifications of doing so.

profiler.force_disable_err_rptCONFIRMED (HTC ONLY)
Since I was poking around in HTC code already, I went ahead and looked in to the profiler.force_disable_err_rpt property which is commonly seen with the profiler.force_disable_ulog property. Unlike the latter, however, this one actually does turn off sending device crash log data to HTC.

public boolean isEnableHTCErrorReport(ProcessRecord paramProcessRecord)
  int i = 1;
  int j = 0;
  if ((!ProfileConfig.getProfileForceDisableErrorRport()) && (Settings.Secure.getInt(this.mContext.getContentResolver(), "send_htc_error_report", 0) != 0))
   ... // Sends the error report

Again, this an HTC-specific property. This will do nothing on a device by any other manufacturer. However, claiming that this will make your device run faster/smoother/better is tenuous at best. This setting is really only useful if you’re concerned about anonymous data being uploaded from your device to HTC.

This property is supposed to “keep the launcher in memory” under the assumption that it would somehow make it faster. Unfortunately, this is a leftover Gingerbread property that no longer functions in ICS.


// These values are set in system/rootdir/init.rc on startup.
HOME_APP_ADJ = getIntProp("ro.HOME_APP_ADJ", true);


static final int HOME_APP_ADJ = 6;

Google likely removed the ability to configure this value via a build.prop setting in ICS so that users could not set inappropriate values here.

As we have seen many times already, there are no “magic properties” that you can set that will simply make your phone [insert desired superlative]. That is not to say that all build.prop settings are pointless. Some can actually provide some useful functionality. The key is not to blindly throw a slew of “tweaks” into your build.prop, but to carefully consider each one and know what they do (if anything) before using them.

That’s it for part two. Let me know what build.prop settings you want to see in part three!

Custom Galaxy S3 Kernel ‘Zaventh’ R3 Released

This is a kernel I’ve made for the T999 to learn more about kernels and also to enable some features that I wanted. I built it on top of Romanbb’s Adama 003 kernel, so please go thank him there.

My philosophy is to build a stable kernel that is tuned for real-world performance and not benchmarks. I have been running this kernel for a while now with great success, but as usual I can’t be responsible for anything that happens to your device.

New in R3

  • SIO scheduler
  • Patched from 3.0.36 to 3.0.40
  • Insecure adbd binary (adb remount command now works)
  • Default scripts now executed before init.d scripts


  • Insecure
  • init.d support
  • OC to 1.89Ghz
  • L2 Overclock
  • UV/OV
  • Add smartassv2, interactive, and conservative governors
  • BFQ, SIO schedulers
  • Patched to 3.0.40
  • TCP proportional rate reduction
  • ARM topology support
  • Enable RCU_BOOST
  • IPv6 privacy support
  • NTFS/TUN module support
  • thermald tweaks

Galaxy S3 Kernel R2 Quadrant Benchmark ResultsGalaxy S3 Kernel R2 AntuTu Benchmark ResultsGalaxy S3 Kernel R3 Settings Screen

  • Samsung’s proprietary exFAT modules will not work with this kernel. Make sure your SD card is FAT32 or EXT4.
  • Please don’t flash this if you don’t know exactly what you’re doing as I’m too lazy to include n00b instructions.
  • You should already be rooted and have busybox installed into /system/xbin before flashing this kernel. As always, wipe all caches after flashing.

Thanks to Romanbb for the initial kernel including OC/UV/OC hacks.

SHA1: f2f4b2873d0a3842ea25471c4339c1de40b4bf0a