Jeff Mixon

Just another WordPress site. Literally.

RSS Feed

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!

Series Navigation<< Examining build.prop tweaks for Android ICS: A comprehensive guide (Part 1)
Tags: , , , , , , , , , , , .
  • Trackbacks
  • Comments
  • tom p
    November 6, 2012

    Particularly with HTC devices, these are the ones I’m most interested in knowing more about:

    I’ve changed these many times over the years, but now it seems that this one:


    may override or conflict with those traditional parameters

    I only say this since the latter has only started popping up on devices recently

  • oreo
    November 7, 2012

    Thanks Jeff! I’m so glad this great project is going on! No new tweaks to suggest, I’ve already listed them all in part1’s comments. Rock on!

  • Flo
    November 10, 2012

    Once again, great work! You really investigate build.prop the way it should! +10 for that, btw, i have some suggestions:
    persist.sys.shutdown.mode=hibernate (i know this one doesn’t work at all, but i’m just curious why)

  • Nilesh
    November 17, 2012

    Any idea about what does? On Qualcomm chipset.

    • Jeff
      November 30, 2012

      A cursory inspection indicates it does nothing, but I will check it out in Part 3. 😉

      • Nilesh
        November 30, 2012

        Seems like it really does nothing. I removed it and finding no changes.
        Waiting for your third part for the official bust 🙂

  • klarkent
    November 18, 2012

    Wow great explanation!

  • tom yorke
    December 13, 2012



  • Neo
    December 22, 2012

    ro.HOME_APP_ADJ=1 works fine on my xperia mini pro (sk17i) ICS. Before this tweak my launcher was constantly reloaded after closing apps and games. Now works without any reloading, like a charm. 🙂

  • Whoo
    December 24, 2012

    The ones that supposedly improve the data speeds:

  • byostaff
    January 7, 2013


    what this:

  • bray424
    January 16, 2013

    A few lines I’ve been dying to find out about:

    Seen this with values of gpu, cpu, dyn, and mpd

    This one was labeled as “Enable the more efficient tile based rendering system”

    This one is always “Enable the QMI gps driver”, and I haven’t been able to find anything out what a qmi gps is.

  • Slobodan
    February 17, 2013

    Great work! It was pleasure to read.
    When can we expect part3 part 4… 🙂
    Also I was wondering about
    why does my backlight wont work always when screen is on.
    Keep up the good work!

  • Guilherme
    February 23, 2013

    Please take a look at the WiFi tweaks!

  • Moko Rockofellon
    May 8, 2013

    I get FC while loading memory and CPU demanding applications (games) yet I have 2GB RAM. Would it make sense to double heapgrowthlimit and heapsize or would those values be overridden by the actual apk?

  • Leo
    August 11, 2013

    I hope part 3 is in the works! It’s very interesting! Thank you very much!

  • Brian
    September 17, 2013

    Wow, this was really helpful! 🙂

  • dt192
    January 6, 2014

    Hi i’ve seen and and im sure a third similar one that seemed to be a mix of the two, are these the same thing? do eithe of them do anything?

    [WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.

  • rashdan
    April 14, 2014

    Can we control or tweak touch screen sensitivity using build.prop ?

  • Robert Huot
    October 29, 2014

    How about a list of the ones that do work? Anyone know where to find? Thanks for the valuable information. I would have been pissed if I wasted my time changing stuff that doesn’t work.

  • No trackbacks yet.

Leave a Reply