Demystifying Android rendering: Jank and ANR

Almost everyone developing an Android app has seen something like this in their device logs.

I/Choreographer(1200): Skipped 60 frames!  The application may be doing too much work on its main thread.

On most devices, the Android platform tries to render a new frame every 16 milliseconds (60 fps).   The rendering requires that whatever work is happening on the UI thread should finish in that timeframe (well, actually in less than that). Any unit of work (== Runnable) scheduled on the UI thread has to fit in that. When the work takes longer, then frames are skipped. One skipped frame is 16 ms of the hung screen. The UI looks janky and unresponsive and if the user interacts with the screen and application does not respond in time (5 seconds) then Application Not Responding (ANR) shows up.

Another interesting scenario where the work can take longer is when the work involves acquiring a lock (for example, for executing synchronized code). Any synchronized code on the main thread is almost always a bad idea since you have no control over who could be holding the lock. And the developer writing the code to run on a background thread has no idea that holding a particular lock can cause any problems. Android has two tools to debug this. One of them is dumpsys for the statistical info; the other one is Method profiling via Android Device Monitor for identifying the culprits.

$ adb shell dumpsys gfxinfo com.google.android.gm
...
Janky frames: 10337 (12.37%)
90th percentile: 17ms
95th percentile: 25ms
99th percentile: 69ms
...

And, by the way, Choreographer is the class that does the actual rendering work.

 

Floating point in user-facing strings

Priceline floating point mistake

Incorrect floating representation of 507.45

%f in user-facing strings is dangerous. Depending on the architecture, programming language involved, version of that language and compiler optimization flags, results can vary slightly. And if there are multiple languages involved in the serving stack, it is almost impossible to argue with the outcome. If those variations are immaterial, then use %.1f or %.2f to get one or two digits of precision after the decimal point, respectively. Otherwise, don’t use %f at all.

 

Tabs vs spaces for code indentation

One argument which some people might give in favor of using tabs is that it allows the viewer to decide how the code should appear to them. And hence, it separates the logic (indentation) from its appearance. The biggest flaw in that argument is that it renders the concept of line length limits meaningless. Line length limits and the associated rules of wrapping bring a good structure to the code.  Someone looking at a piece of code with 3-levels of nesting and tab-length set to 8 will see a very different line length from someone using a tab-length of 2. Always expand tabs.

File size should always be of “long” type

int getTextFileSize(String fileName) {
  return (int) (new File(BASE_DIR, fileName).length();  // WRONG
}

A 32-bit signed int can deal with ~2GB worth of data. And if your code is not going to deal with files larger than 2GB, why worry? But what if  someone wants to use the same code for a video file some day? Or What if someone writes another code to iterate over all the files in the BASE_DIR directory? Most likely they will be inclined to use int for the final sum as well. Adding integers in most languages results in int and automatic overflows into a negative number (and even worse, back to a positive number). The caller code might think that BASE_DIR does not exist. Therefore, the best future-proofing is to never have file size stored as an integer. Even, Android platform got it wrong with StatFs#getBlockSize and corrected it by adding StatFs#getBlockSizeLong.

Google I/O 2016: Android notes

General

  1. Multitasking – multi-window mode and picture-in-picture mode. This includes the ability to launch window in adjacent activity, and drag and drop between activities.
  2. Notifications – Custom quick settings tile for an activity
  3. Multi-locale – users can specify locale beyond their primary locale
  4. ScopedDirectoryAccess for the shared storage
  5. New file-level encryption mode (as opposed to block-level encryption) and the corresponding Direct Boot
  6. Java 8, Jack, and ndk support in Gradle
  7. GCC deprecated in favor of Clang

TechTalk on Image size/compression

  1. PNG – Get image down to 256-bit palette (if possible) or compress them using Zopfli. Test the difference with butteraugli
  2. Convert PNG to Vector drawable using Potrace. Vector drawable are natively supported on Android 5.0 and above. Use compat to use them on the older versions. Or generate PNG for the older versions (not recommended)
  3. WebP is another option (Note: Speaker failed to mention that WebP is natively supported only on Android).
  4. Avoid JPEGs. They are usually larger in size.

Read More

My rm -rf moment

Yes, it did happen, and no, I am not stupid enough to execute rm -rf *. It was a bit more convoluted than that. I was trying to prepare a customized SD card image for the Android emulator. The fastest way to do that was to mount the SD card on my GNU/Linux machine and modify the files. The files on the SD card have root as the owner. Therefore, the easiest way to maintain a clean state was to make all modifications using sudo. My script included a command rm -r ${base_dir}/${old_file}. While executing the script, due to an error, both the variables were not set. It took me a few hours to recover; I never committed the broken script, so, I did not harm anyone else. But since then, my bash scripts have always included set -o nounset.

Android command-line: gradle and testing

For android projects, some engineers use Android Studio (new), some use Eclipse with ADT (old), few like me still savor command line, this blog post is about handling (building, installing and testing) android projects from command line.

  1. To create android project
    $ android create project --target 4 --name TestAndroidApp --path ./test_android_app --activity Main --package net.ashishb.TestAndroidApp --gradle --gradle-version 1.0.+ 
  2. After changing to directory test_android_app (cd test_android_app), fix a bug
    # Replace "runProguard" with "minifyEnabled" in build.gradle
    $ sed -i '' 's/runProguard/minifyEnabled/' build.gradle

     

  3. Some useful gradle commands
    $ gradle tasks  # Lists all tasks.
    $ gradle assembleDebug  # Assemble debug build
    $ gradle installDebug  # Install debug build
    $ gradle assembleRelease  # Install release build
  4. The code will be in src directory, eg. for the Main activity, code is in src/main/java/net/ashishb/TestAndroidApp/Main.java and test is in src/androidTest/java/net/ashishb/TestAndroidApp/MainTest.java
  5. For testing, modify the Main class and add square method,
    public static int square(int x) {
          return x * x;
    }
    

    And in MainTest

    public void testSquare() {  // Tests must start with test prefix.
       this.assertEquals(100, Main.square(10));
    }
  6. Modify build.gradle to add a testing config
    android {
        ...
    
        defaultConfig {
          testApplicationId "net.ashishb.TestAndroidApp.test"
          testInstrumentationRunner "android.test.InstrumentationTestRunner"
          testHandleProfiling true
          testFunctionalTest true
        }
    
        ...
    }

     

  7. Run the test(s)
    $ gradle installDebug installDebugTest && adb shell am instrument -w -e class net.ashishb.TestAndroidApp.MainTest#testSquare net.ashishb.TestAndroidApp.test/android.test  # Runs the testSquare test.
    
    $ gradle installDebug installDebugTest && adb shell am instrument -w  net.ashishb.TestAndroidApp.test/android.test.InstrumentationTestRunner  # Runs all tests.
  8. Complete code can be seen at https://github.com/ashishb/android_gradle_demo

Android, Gradle and compile-time only dependencies

Android plugin for Gradle does not support Java-style compile time only dependencies.

After spending a few hours on trying to build android app targeted for Amazon SDK (without using Amazon’s Android specific plugin but just their jar stubs for maps, ADM and Home widget), I finally found that the one way to support compile-time dependencies is following.

For application project

configurations {
    provided
}

dependencies {
    // ...
    provided fileTree(dir: "${project.rootDir}/path_to_libs_dir", include: '*.jar')
}

// Android's version of sourceSets.main.compileClasspath
android.applicationVariants.each { variant ->
    variant.javaCompile.classpath += configurations.provided
}

For the library project

configurations {
    provided
}

dependencies {
    // ...
    compile fileTree(dir: 'libs', include: '*.jar')
    provided fileTree(dir: "${project.rootDir}/patch_to_libs_dir", include: '*.jar')
}

android.libraryVariants.all { variant ->
    // Exclude the jar files from making its way into the final apk.
    // Irrespective of what the path_to_libs_dir is the final jar files end up in libs dir.
    variant.packageLibrary.exclude('libs/lib1.jar')
    variant.packageLibrary.exclude('libs/lib2.jar')
    // ...
}

References

  1. https://stackoverflow.com/questions/16613722/gradle-configurations-not-working-as-expected-in-new-android-build-system
  2. http://stackoverflow.com/a/24157721
-->