Third-Party Android* Application Debug Reference on Intel® Processor-based Platforms Part 2

Contents


Debug Third-Party Vendor Applications

Debug Java application
Debug x86 native library of application

App Issues—Highlights

Application Usage Pre-condition
Fail to install app
App has hard code dependence on ARM abi/arch property, etc.
App has dependence on OEM framework (like Samsung changes its framework)
App has some dependence on native library which is missing on Intel processor- based platform
App doesn’t have permission
Data base structure difference
App has dependence on ISV function package like <uses-library android:name="xxx_feature" /> in AndroidManifest.xml
com.google.android.vending.licensing.LicenseValidator.verify Issue related with paid app
How to add resources into the apk file
Google Play Store Filter Details

Debug Third-Party Vendor Applications

There are many third-party vendor applications available on the Android market, making them runnable on mobile platform is very important for the success of mobile platform on the market. The problem is that there is no source code available for these third-party vendor applications, and they do not run well on some mobile platforms sometimes, how can we identify the issue?

Debug Java application

There are many tools available for debug android java application, they can help developer to debug android application quickly and easily .

Below is a list of Android debug tools and links for how to download them:

  1. baksmali:Analyze odex / dex file into smali file., You need to put files under /system/framework in the same working directory.

    Command: java -jar baksmali.jar -x file.odex

    Download link: http://code.google.com/p/smali/downloads/list

  2. smali:Make smali files into classes.dex files.

    Command: java -Xmx512M -jar smali.jar out -o classes.dex

  3. keytool: Create apk certificates.

    keytool -genkey -v -alias CERT -keyalg RSA -keysize 2048 -validity 10000 -keystore CERT.keystore

  4. jarsigner:apk sign tool

    jarsigner -verbose -keystore CERT.keystore to_sign.apk CERT

  5. dex2jar:Decompile classes.dex into jar file

    link: http://code.google.com/p/dex2jar/downloads/list

  6. JD-GUI: Check Java source from jar file

  7. apktool:Decompile resource /xml/smali files from apk. It can also compile apk file using smali

    Download link: http://code.google.com/p/android-apktool/downloads/list

  8. AXMLPrinter:Convert apk’s xml file into readable file.

    Download link: http://code.google.com/p/android4me/downloads/list

  9. zipalign: Optimize apk file size

    Command: zipalign -v 4 unaligned.apk aligned.apk

Smali debug

Google provides the apktool to decompile Dalvik dex into smali code (Dalvik byte code).

After using apktool, there will be a smali directory with all smali files for application dex.

For smali opcodes, please refer to this link:

http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html

Smali file general format is as follows:

.class < permission> [decoration word] < class name>

.super < parent class>

.source <source code file name>

For example:

Open MainActivity.smali, the first 3 lines are as following:

.class public Lcom/droider/crackme0502/MainActivity;

.super Landroid/app/Activity;

.source "MainActivity.java"

1st line – this is class name MainActivity. Its package is com.droider.crackme0502

2nd line – MainActivity’s super class is android.app.Activity

3rd line – Source code name is MainActivity.java

The class consists of many fields and methods. In smali, a field is declared as “.field” instruction with the following format:

.field <permission> static [ decoration key word] < field name>:< field type>

For static field in smali, the annotation in smali begins with #

instance fields, and the format is as follows:

# instance fields

.field <permission> static [ decoration key word] < field name>:< field type>

For example:

# instance fields

.field private btnAnno:Landroid/widget/Button;

1st line – annotation by baksmali

2nd line – field btnAnno is android.widget.Button

If there is a method in the class, there will be smali code for method, begin with the “.method” instruction.

There are direct methods and virtual methods.

# direct methods

.method <access permission> [ decoration key word] < prototype>

<.locals>

[.parameter]

[.prologue]

[.line]

<smali code>

.end method

“virtual methods” are similar to direct ones.

Interface begins with “.implements” instruction.

# interfaces

.implements < interface name>

annotation begins with “.annotation”:

# annotations

.annotation [ property] < class name>

    [ filed =  value]

.end annotation

# instance fields

.field public sayWhat:Ljava/lang/String;

    .annotation runtime Lcom/droider/anno/MyAnnoField;

        info = "Hello my friend"

    .end annotation

.end field

Tips:

With smali code being so difficult to write, how can we write smali code quickly?

The answer is Eclipse. You can create an Android project in Eclipse, then use Java code to write what the code you want, then create apk file with dex. Finally you can get smali code for your function by apktool and paste the smali code in another place for usage.

For example: Log.x API in Java code. You can decompile it into smali, then paste it into application smali code for debugging message print.

invoke-static {v11, v12}, Landroid/util/Log;->e(Ljava/lang/String;Ljava/lang/String;)I

When debugging application programs, you can use one of the following two methods:

  1. Add a log in smali code

    1. Add more registers in the “.local” variable, e.g., v11,v12

    2. Add log smali code in place

          const-string v11, "@@@@"

          const-string v12, "interceptPowerKeyDown enter"

          invoke-static {v11, v12}, Landroid/util/Log;->e(Ljava/lang/String;Ljava/lang/String;)I

          if register are v28 and v29, use following code:

          invoke-static/range {v28 .. v29}, Landroid/util/Log;->e(Ljava/lang/String;Ljava/lang/String;)I

  2. Print call stack in smali:

    1. Add a register in “.local” variable. e.g., v11

    2. Add print call stack smali code in place

          new-instance v11 Ljava/lang/Exception;

          invoke-direct {v11, Ljava/lang/Exception;-><init>()V

          invoke-virtual {v11, Ljava/lang/Exception;->printStackTrace()V

Smali Code Troubleshooting

You need to resolve run-time errors after debug and changing your smali code. To get smali code run-time errors, you can use the following commands:

  adb logcat | grep dalvikvm

  adb logcat | grep VFY

  VFY information will show the smali error file, the routine and error causes. Dalvikvm information will show call stacks, context , etc.

Typical runtime errors:

  1. The variable list isn’t consistent with declaration:

  2. 2. The routine call type is incorrect

    For example: Use invoke-virtual for public/package routine. Use invoke-director for private routine.

  3. 3. apk is not signed properly

  4. 4. Use adb logcat | grep mismatch to check which package signature is incorrect

Smali Debug Troubleshooting

After changing the smali code, you need to package it by running “apktool b.” Typically, there will be some error messages, such as the following:

  1. res/values/styles.xml:166: No resource found that matches the given name '@*android:style/Widget.Button error. You need to change styles.xml 166 line '@*android:style/Widget.Button  into  @android:style/Widget.Button

  2. Many error lines like :\apktool\apk\res\values\public.xml:3847: error: Public symbol xxxxx The declaration is not defined.

    All these errors are actually due to the first error line:

    res/values/strings.xml:242: error: Multiple substitutions specified in non-positional format. Did you mean to add the formatted="false" attribute? string.xml

    Check line 242 in the strings.xml file to find problem string and fix it.

  3. Function calls (invoke-virtual etc. instructions) only can use v0~v15 register as parameter,there will be errors if using v16, etc. There are two ways to fix this:

    1. Use invoke-virtual/range {p1 .. p1} instruction

    2. Add move-object/from16 v0, v18 instruction

  4. pN is an equal variable number + N. For example, “.local” is declared as 16,You can use register v0~v15. p0 is equal to v16,and p1 is equal to v17.

  5. Jump label conflict

    You will get this message if there are two of the same jump labels. For example, cond_11 will make the compile fail. You can change them to different names to resolve the conflict like ABCD_XXXX.

  6. Use no-definition variable

    The variable can be used as declared in “.local” instruction. For example, .local 30 shows this routine can only use v0 ~ v29, if use v39, there will be error.

Debug x86 native library of application

For example, let’s say you have an apk with x86 native library libcmplayer_14.so. When the application runs on an Intel processor-based platform, there is a tombstone showing a crash in libcmplayer_14.so. The following paragraphs show how to deduce potential problems by checking the libcmplayer_14.so API call to Intel processor-based platform.

Step1: Use readelf to check the Intel processor-based platform libraries, which will be used by libcmplayer_14.so. This will give you some sense about to which component the issue may be related.

readelf -d libcmplayer_14.so

Dynamic section at offset 0xd8b8 contains 33 entries:

TagTypeName/Value
0x00000001(NEEDED)Shared library: [libdl.so]
0x00000001(NEEDED)Shared library: [liblog.so]
0x00000001(NEEDED)Shared library: [libz.so]
0x00000001(NEEDED)Shared library: [libui.so]
0x00000001(NEEDED)Shared library: [libmedia.so]
0x00000001(NEEDED)Shared library: [libbinder.so]
0x00000001(NEEDED)Shared library: [libutils.so]
0x00000001(NEEDED)Shared library: [libstdc++.so]
0x00000001(NEEDED)Shared library: [libgui.so]
0x00000001(NEEDED)Shared library: [libandroid.so]
0x00000001(NEEDED)Shared library: [libsurfaceflinger_client.so]
0x00000001(NEEDED)Shared library: [libm.so]
0x00000001(NEEDED)Shared library: [libc.so]
0x0000000e(SONAME)Library soname: [libcmplayer.so]
0x00000010(SYMBOLIC)0x0
0x00000019(INIT_ARRAY)0xe89c
0x0000001b(INIT_ARRAYSZ)16 (bytes)
0x0000001a(FINI_ARRAY)0xe8ac
0x0000001c(FINI_ARRAYSZ)12 (bytes)
0x00000004(HASH)0xd4
0x00000005(STRTAB)0x8f0
0x00000006(SYMTAB)0x350
0x0000000a(STRSZ)2409 (bytes)
0x0000000b(SYMENT)16 (bytes)
0x00000003(PLTGOT)0xe9f4
0x00000002(PLTRELSZ)496 (bytes)
0x00000014(PLTREL)REL
0x00000017(JMPREL)0x12a4
0x00000011(REL)0x125c
0x00000012(RELSZ)72 (bytes)
0x00000013(RELENT)8 (bytes)
0x6ffffffa(RELCOUNT)6
0x00000000(NULL)0x0

Step2: Use the objdump tool to find the UND API call used by libcmplayer_14.so, which you can find API name that the libcmplayer_14.so may use and could be potential problem call.

objdump -T libcmplayer_14.so | grep UND

00000000      DF *UND*    00000000 _ZNK7android7RefBase9incStrongEPKv

00000000      DF *UND*    00000000 rewind

00000000      DF *UND*    00000000 pthread_attr_setschedparam

00000000      DF *UND*    00000000 fwrite

00000000      DO *UND*   00000000 __sF

00000000      DF *UND*    00000000 usleep

00000000      DF *UND*    00000000 memcpy

00000000      DF *UND*    00000000 realloc

00000000      DF *UND*    00000000 pthread_mutex_init

00000000      DF *UND*    00000000 pthread_attr_init

00000000      DF *UND*    00000000 strcat

00000000  w   DF *UND* 00000000 __deregister_frame_info_bases

00000000      DF *UND*    00000000 _ZN7android7Surface4lockEPNS0_11SurfaceInfoEPNS_6RegionE

00000000      DF *UND*    00000000 __cxa_finalize

00000000      DF *UND*    00000000 sched_get_priority_max

00000000      DF *UND*    00000000 malloc

00000000      DF *UND*    00000000 dlsym

00000000      DF *UND*    00000000 strlen

00000000      DF *UND*    00000000 pthread_mutex_lock

00000000      DF *UND*    00000000 __cxa_atexit

00000000      DF *UND*    00000000 sched_get_priority_min

00000000      DF *UND*    00000000 snprintf

00000000      DF *UND*    00000000 __android_log_print

00000000      DF *UND*    00000000 dlerror

00000000      DF *UND*    00000000 setjmp

00000000      DF *UND*    00000000 pthread_mutex_destroy

00000000      DF *UND*    00000000 fclose

00000000      DF *UND*    00000000 fread

00000000      DF *UND*    00000000 fopen

00000000      DF *UND*    00000000 __stack_chk_fail

00000000      DF *UND*    00000000 time

00000000      DF *UND*    00000000 strtok

00000000      DF *UND*    00000000 pthread_create

00000000      DF *UND*    00000000 _ZNK7android7RefBase9decStrongEPKv

00000000  w   DF *UND* 00000000 __register_frame_info_bases

00000000      DF *UND*    00000000 _ZN7android10AudioTrack5startEv

00000000      DF *UND*    00000000 pthread_cond_signal

00000000      DF *UND*    00000000 pthread_mutexattr_init

00000000      DF *UND*    00000000 sscanf

00000000      DF *UND*    00000000 pthread_cond_timedwait

00000000      DF *UND*    00000000 pthread_cond_init

00000000      DF *UND*    00000000 _ZN7android10AudioTrack5writeEPKvj

00000000      DF *UND*    00000000 pthread_attr_setschedpolicy

00000000      DF *UND*    00000000 memset

00000000      DF *UND*    00000000 sprintf

00000000      DF *UND*    00000000 fseek

00000000      DF *UND*    00000000 pthread_mutex_unlock

00000000      DF *UND*    00000000 pthread_cond_destroy

00000000      DF *UND*    00000000 strstr

00000000      DF *UND*    00000000 ftell

00000000      DF *UND*    00000000 free

00000000      DF *UND*    00000000 atoi

00000000      DF *UND*    00000000 strchr

00000000      DF *UND*    00000000 printf

00000000      DF *UND*    00000000 _ZN7android10AudioTrack5pauseEv

00000000      DF *UND*    00000000 pthread_cond_wait

00000000      DF *UND*    00000000 strdup

00000000      DF *UND*    00000000 puts

00000000      DF *UND*    00000000 dlopen

00000000      DF *UND*    00000000 _ZN7android10AudioTrack4stopEv

00000000      DF *UND*    00000000 _ZN7android10AudioTrack5flushEv

00000000      DF *UND*    00000000 strcpy

00000000      DF *UND*    00000000 pthread_join

Step3: Add a log or use another debug method to the libraries and API on the Intel processor-based platform used by libcmplayer_14.so to find the crash position.

GDB check core dump

gdb.sh

  1. Find the core dump file by using the command:

    adb shell cat /logs/history_event

    #V1.0 CURRENTUPTIME   0001:05:08

    #EVENT  ID                                       DATE                      TYPE

    REBOOT  8a41fa9bc91dc23cc5a2   1982-01-01/00:04:40  SWUPDATE         0000:00:00

    STATE   e4fd39f21a9630bf4187        1982-01-01/00:04:40  DECRYPTED      

    CRASH   4be805a6b721775813d6    2013-02-06/09:16:00  TOMBSTONE /mnt/sdcard/logs/crashlog0

    CRASH   00526c3de09fd880c454      2013-02-06/09:16:16  APCOREDUMP /mnt/sdcard/logs/crashlog1

    You find the core dump file is in /mnt/sdcard/logs/crashlog1

  2. Get the core dump file and the application’s native x86 library into the host. For example:

    adb pull /mnt/sdcard/logs/crashlog1

    adb pull /data/app-lib/com.zeptolab.ctr.ads-1/libctr-jni.so

  3. Copy the application’s native x86 library into the project symbol lib path. For example:

    cp libctr-jni.so ~/JB/ target/product/blackbay/symbols/system/lib

  4. Use gdb.sh in attachment (you may need to do some path change in the gdb.sh script on your host) to run gdb and analyze the core dump. For example:

    cd ~/JB/

    gdb.sh app_process out/target/product/blackbay

    core ~/temp/crashlog1/1360114650_app_process_5145.core

Now you can use any of the gdb commands to analyze the core dump file. For example, use the “bt” command to get call back trace.

objdump check native library

Same example as above:

  1. Get the code base related to the bug

  2. Build the code base for the bug

  3. cd <aosp>/out/target/product/<platform>/symbols/system/lib. There will be a symbol for lib here

  4. objdump -d libjni_latinime.so > tmp.log to decompile the lib

  5. Open tmp.log to find eip 880b. You can find the error code position for the decompiled routine name in tmp.log

    For example, you can use c++filt to turn _ZN8latinimeL30latinime_BinaryDictionary_openEP7_JNIEnvP8_jobjectP8_jstringxxiiii into a readable function name like the following:

c++filt _ZN8latinimeL30latinime_BinaryDictionary_openEP7_JNIEnvP8_jobjectP8_jstringxxiiii

latinime::latinime_BinaryDictionary_open(_JNIEnv*, _jobject*, _jstring*, long long, long long, int, int, int, int)

GDB debug assembly code

Target Device:

gdbserver :port - -attach ID

Host PC:

           adb forward tcp:1234 tcp: 1234

                gdb.sh app_process <symbol path>

           #target remot :1234

b *0x80123432  //break in 0x80123432 address

x/64xw 0x80123432  //show 64 number 4bytes memory content from address 0x80123432 in hex format

x/s 0x80123432  //display a string from address 0x80123432

info register //check all register value

info symbol 0x80123432  //get symbol information from address 0x80123432

nexti //execute next asm instruction

display $eax //add expression value

p expression//show expression value

disassemble _ZN14ProfileManager18WriteTrophiesStateEP7__sFILERKN13PlayerProfile21ProfileActiveTrophiesE

//show asm code of function

using c++filt tool to demangle function name as following:

_ZN14ProfileManager18WriteTrophiesStateEP7__sFILERKN13PlayerProfile21ProfileActiveTrophiesE

ProfileManager::WriteTrophiesState(__sFILE*, PlayerProfile::ProfileActiveTrophies const&)

Apk Install Directory

Since JB, if you donwload paid apps from google playstore and install them. The install path is /data/app-asec and the format is .asec.

If you want to decompile apk, you need to download and install it on ICS platform.

android version

installed path

file format on device

ICS

/data/app

.apk

JB

/data/app-asec

.asec

When installing paid applications in JB, you can try to find the installed package in the /mnt/asec directory.

For example, modern combat 2 would look like this:

/mnt/asec/com.gameloft.android.ANMP.GloftBPHM.ML-1/pkg.apk  is the apk installation package.

Downloaded app data may in the following position:(use fina –name * GloftBPHM*  to search)

/mnt/shell/emulated/0/Android/data/com.gameloft.android.ANMP.GloftBPHM.ML

/data/media/0/Android/data/com.gameloft.android.ANMP.GloftBPHM.ML

/storage/sdcard0/Android/data/com.gameloft.android.ANMP.GloftBPHM.ML <-/storage The data in this directory is mostly likely created by the application itself when launched.

x86 Debug Case

Antutu tombstone issue [BZ 107342]
  1. Run the 3d bench test after DUT encrypted. A tombstone will happen. The x86 emulator also has the problem, so the app should have responsibility for the issue.

  2. Run cat /logs/his* to find the tombstone core dump file. Copy Antutu library 3drating.5 and libabenchmark.so into out/target/platform/redhookbay/symbols/system/lib

  3. Use the “GDB check core dump” method to open the core dump file. Use the bt command to show the call stack as follows:

    #0  0x5e361ef5 in native_window_set_buffers_format (format=4, window=0x0) at system/core/include/system/window.h:749

    #1  ANativeWindow_setBuffersGeometry (window=0x0, width=0, height=0, format=4) at frameworks/base/native/android/native_window.cpp:63

    #2  0x60f4be20 in Ogre::AndroidEGLWindow::_createInternalResources(ANativeWindow*, AConfiguration*) () from /home/zwang/r4_2_stable/out/target/product/redhookbay/symbols/system/lib/3drating.5

    #3  0x60f4c4dd in Ogre::AndroidEGLWindow::create(std::string const&, unsigned int, unsigned int, bool, std::map<std::string, std::string, std::less<std::string>, Ogre::STLAllocator<std::pair<std::string const, std::string>, Ogre::CategorisedAllocPolicy<(Ogre::MemoryCategory)0> > > const*) () from /home/zwang/r4_2_stable/out/target/product/redhookbay/symbols/system/lib/3drating.5

    #4  0x60f4af8e in Ogre::AndroidEGLSupport::newWindow(std::string const&, unsigned int, unsigned int, bool, std::map<std::string, std::string, std::less<std::string>, Ogre::STLAllocator<std::pair<std::string const, std::string>, Ogre::CategorisedAllocPolicy<(Ogre::MemoryCategory)0> > > const*) () from /home/zwang/r4_2_stable/out/target/product/redhookbay/symbols/system/lib/3drating.5

    #5  0x60f428eb in Ogre::GLES2RenderSystem::_createRenderWindow(std::string const&, unsigned int, unsigned int, bool, std::map<std::string, std::string, std::less<std::string>, Ogre::STLAllocator<std::pair<std::string const, std::string>, Ogre::CategorisedAllocPolicy<(Ogre::MemoryCategory)0> > > const*) () from /home/zwang/r4_2_stable/out/target/product/redhookbay/symbols/system/lib/3drating.5

    #6  0x61095091 in Ogre::Root::createRenderWindow(std::string const&, unsigned int, unsigned int, bool, std::map<std::string, std::string, std::less<std::string>, Ogre::STLAllocator<std::pair<std::string const, std::string>, Ogre::CategorisedAllocPolicy<(Ogre::MemoryCategory)0> > > const*) () from /home/zwang/r4_2_stable/out/target/product/redhookbay/symbols/system/lib/3drating.5

    #7  0x60ecaf05 in OgreAndroidBaseFramework::initRenderWindow(unsigned int, unsigned int, unsigned int) () from /home/zwang/r4_2_stable/out/target/product/redhookbay/symbols/system/lib/3drating.5

    #8  0x60ec2b71 in ogre3d_initWindow () from /home/zwang/r4_2_stable/out/target/product/redhookbay/symbols/system/lib/3drating.5

    #9  0x5f09e271 in Java_com_antutu_ABenchMark_Test3D_OgreActivity_initWindow () from /home/zwang/r4_2_stable/out/target/product/redhookbay/symbols/system/lib/libabenchmark.so

    #10 0x40dce170 in dvmPlatformInvoke () at dalvik/vm/arch/x86/Call386ABI.S:128

    #11 0x40e27a68 in dvmCallJNIMethod (args=0x57941df8, pResult=0x8000cf10, method=0x57c11e10, self=0x8000cf00) at dalvik/vm/Jni.cpp:1174

    #12 0x40df197b in dvmCheckCallJNIMethod (args=0x57941df8, pResult=0x8000cf10, method=0x57c11e10, self=0x8000cf00) at dalvik/vm/CheckJni.cpp:145

    #13 0x40e2da5d in dvmResolveNativeMethod (args=0x57941df8, pResult=0x8000cf10, method=0x57c11e10, self=0x8000cf00) at dalvik/vm/Native.cpp:135

    #14 0x40f2ec8d in common_invokeMethodNoRange () from /home/zwang/r4_2_stable/out/target/product/redhookbay/symbols/system/lib/libdvm.so

    #15 0x57941df8 in ?? ()

    #16 0x40de1626 in dvmMterpStd (self=0x8000cf00) at dalvik/vm/mterp/Mterp.cpp:105

    #17 0x40ddefc4 in dvmInterpret (self=0x8000cf00, method=0x579e0b68, pResult=0xbffff604) at dalvik/vm/interp/Interp.cpp:1954

    #18 0x40e590ec in dvmInvokeMethod (obj=0x0, method=0x579e0b68, argList=0x4207c260, params=0x4207c170, returnType=0x417e42d0, noAccessCheck=false) at dalvik/vm/interp/Stack.cpp:737

    #19 0x40e6cf67 in Dalvik_java_lang_reflect_Method_invokeNative (args=0x57941f00, pResult=0x8000cf10) at dalvik/vm/native/java_lang_reflect_Method.cpp:101

    #20 0x40f2ec8d in common_invokeMethodNoRange () from /home/zwang/r4_2_stable/out/target/product/redhookbay/symbols/system/lib/libdvm.so

    #21 0x57941f00 in ?? ()

    #22 0x40de1626 in dvmMterpStd (self=0x8000cf00) at dalvik/vm/mterp/Mterp.cpp:105

    #23 0x40ddefc4 in dvmInterpret (self=0x8000cf00, method=0x579d63c0, pResult=0xbffff8c8) at dalvik/vm/interp/Interp.cpp:1954

    #24 0x40e57e1c in dvmCallMethodV (self=0x8000cf00, method=0x579d63c0, obj=0x0, fromJni=true, pResult=0xbffff8c8, args=<optimized out>) at dalvik/vm/interp/Stack.cpp:526

    #25 0x40e1ba6e in CallStaticVoidMethodV (env=0x8000a020, jclazz=0x1d400015, methodID=0x579d63c0, args=0xbffff97c "\t") at dalvik/vm/Jni.cpp:2111

    #26 0x40dfb440 in Check_CallStaticVoidMethodV (env=0x8000a020, clazz=0x1d400015, methodID=0x579d63c0, args=0xbffff97c "\t") at dalvik/vm/CheckJni.cpp:1679

    #27 0x402685ba in _JNIEnv::CallStaticVoidMethod (this=0x8000a020, clazz=0x1d400015, methodID=0x579d63c0) at libnativehelper/include/nativehelper/jni.h:793

    #28 0x40269e71 in android::AndroidRuntime::start (this=0xbffffa50, className=0x80001208 "com.android.internal.os.ZygoteInit", options=<optimized out>) at frameworks/base/core/jni/AndroidRuntime.cpp:1005

    #29 0x80000fd0 in main (argc=4, argv=0xbffffaf8) at frameworks/base/cmds/app_process/app_main.cpp:190

  4. Debug from framework API, which is found:

    android_view_Surface_getNativeWindow: get surface = 0x802fbbc8 return a valid ANativeWindow*

    ANativeWindow_setBuffersGeometry. The input parameter is ANativeWindow* = null

    So there should be something happening between the above two APIs that result in the tombstone happening.

  5. Antutu uses ORGE render engine in the call stack. We can find the ORGE render engine source code at this link:

    http://code.metager.de/source/xref/ogre/RenderSystems/GLES/src/EGL/Android/OgreAndroidEGLWindow.cpp

    It is found ANativeWindow* point value is changed in void AndroidEGLWindow::create as following. This results in the mWindow being a NULL value and a tombstone happening.

    void AndroidEGLWindow::create(const String& name, uint width, uint height, bool fullScreen, const NameValuePairList *miscParams) {
    
    ...
    	mWindow = (ANativeWindow*)(Ogre::StringConverter::parseInt(opt->second));
    ...
    	_createInternalResources(mWindow, config);
    ...
    }
    
  6. On Intel processor-based platforms, memory points like ANativeWindow* will be higher than 0x80000000, (ARM platforms will lower than 0x80000000 ), which results in unsigned int -> int -> string -> int change problem. This problem won’t happen on ARM platforms.

    In Antutu issue, the ANativeWindow* stored in opt->second should be used as unsigned int, parseInte will result to return 0 and Antutu tombstone issue.

App Issues—Highlights

Application Usage Pre-condition

Error Symptom:

When many applications appear to fail, they haven’t really failed. It is due to some usage pre-condition that is ignored by the tester or end user and later causes failures. Some typical pre-conditions are as follows:

  1. sim card location difference (sim cards in the U.S., China, France have different 3G locations)

  2. Wi-Fi*/3G Internet connection differences. Some apps have specific locations or requirements for Wi-Fi/3G connection.

  3. Poor Wi-Fi/3G connection environment. Poor connections will result in some apps re-trying the Internet connection many times, which results in poor power consumption and crashes.

  4. Screen resolution/dpi constriction. Many applications have requirements for on screen resolution/dpi to work.

  5. GMS services. Google play service, Google service framework, etc. turn off. Many GMS apps depend on underlying GMS services to work.

Solution:

Make sure you use apps that meet all of the above pre-conditions.

Fail to install app

Error Symptom:

Applications downloaded from Play store fail to install to device, or fail to install apk by adb install.

Solution:

Make sure usb/sd card write is ok. Make sure houdini hook in PMS works well.

App has hard code dependence on ARM abi/arch property, etc.

Error Symptom:

Dalvik cannot resolve the link for the ARM library or cannot find the native method implementation because it fails to copy the native library into the device when app is run.

Major app function check fail, etc.

Solution:

Remove app hard code check by changing its smali code or ask app ISV to fix.

App has dependence on OEM framework (like Samsung changes its framework)

Error Symptom:

Fail to find some field, method, or class.

Solution:

Change smali code to mask related field/method/class usage.

Copy related framework class into your device.

App has some dependence on native library which is missing on Intel processor- based platform

Error Symptom:

UnSatisfiedException exception with missed native library name.

Solution:

Check app library dependence and copy related library into device.

App doesn’t have permission

Error Symptom:

no permission

Solution:

Add <user-permision /> into AndroidMenifest.xml

Data base structure difference

Error Symptom:

Miss some field or type mis-match

Solution:

Decompile apk, check smali code to find SQL-related string (ex: create table … ), edit SQL string to fit data base, and package back into apk.

App has dependence on ISV function package like <uses-library android:name="xxx_feature" /> in AndroidManifest.xml

Error Symptom:

no-permission to access some feature when launch the app

Solution:

Change AndroidManifest.xml to remove these <uses-library> tage or copy these feature jar package from other mobile platform into your target device to have a try.

com.google.android.vending.licensing.LicenseValidator.verify Issue related with paid app

If you see this issue, you can repo it using the following steps:

Error Symptom:

Issue log as following:

E/AndroidRuntime(27088): FATAL EXCEPTION: background thread

E/AndroidRuntime(27088): java.lang.NullPointerException

E/AndroidRuntime(27088): at com.google.android.vending.licensing.LicenseValidator.verify(LicenseValidator.java:99)

E/AndroidRuntime(27088): at com.google.android.vending.licensing.LicenseChecker$ResultListener$2.run(LicenseChecker.java:228)

Repo Steps:

(a) Install apk

(b) Remove Google account on the device

(c) Launch this app

How to add resources into the apk file

Example: to add one string resource, we need to add into values/strings.xml

<string name="newstring">content</string>

                public.xml under values directory record all resource ids. Find the latest <public type="string" ...> element, then add  <public type="string" name="newstring" id="0x7f0700a0" />

                Change smali file to use the new string resource as follows:

invoke-virtual {p0}, Lcom/sini/SfsdfsActivity;->getResources()Landroid/content/res/Resources;

move-result-object v0

const v1, 0x7f0700a0

invoke-virtual {v0, v1}, Landroid/content/res/Resources;->getString(I)Ljava/lang/String;

Google Play Store Filter Details

Google filter link: http://developer.android.com/google/play/filters.html

  • Device DPI Filter

    Google standard DPI: 320, 240 (HDPI), 160 (MDPI), and possibly 120 (LDPI)

    If your device is another DPI, many of the applications in the Play store will be unavailable.

  • Device Feature Filter

    Google Play Store will call the API PackageManager.getSystemAvailableFeatures and hasSystemFeature to get all the features on the device.

    It will filter applications according to the features available on device.

  • Take the example of MFLD PR phone JB 4.1

    If camera-related features are not available in the return value in API PackageManager.getSystemAvailableFeatures and hasSystemFeature, MFLD PR phone won’t find needed camera features like: smart compass, wechat, etc.

    If camera-related features are available, in the return value in API PackageManager.getSystemAvailableFeatures and hasSystemFeature, MFLD PR phone can find needed camera features like: smart compass, wechat, etc.

    Notes:

    You need to clear data and cache of Google Play Service and Google Play Store to make the feature change take effect on the target device.

  • Features available on MFLD PR phone are as follows:

    root@android:/ # pm list features
    feature:reqGlEsVersion=0x20000
    feature:android.hardware.bluetooth
    feature:android.hardware.camera
    feature:android.hardware.camera.autofocus
    feature:android.hardware.camera.flash
    feature:android.hardware.camera.front
    feature:android.hardware.faketouch
    feature:android.hardware.location
    feature:android.hardware.location.gps
    feature:android.hardware.location.network
    feature:android.hardware.microphone
    feature:android.hardware.nfc
    feature:android.hardware.screen.landscape
    feature:android.hardware.screen.portrait
    feature:android.hardware.sensor.accelerometer
    feature:android.hardware.sensor.barometer
    feature:android.hardware.sensor.compass
    feature:android.hardware.sensor.gyroscope
    feature:android.hardware.sensor.light
    feature:android.hardware.sensor.proximity
    feature:android.hardware.telephony
    feature:android.hardware.telephony.gsm
    feature:android.hardware.touchscreen
    feature:android.hardware.touchscreen.multitouch
    feature:android.hardware.touchscreen.multitouch.distinct
    feature:android.hardware.touchscreen.multitouch.jazzhand
    feature:android.hardware.usb.accessory
    feature:android.hardware.usb.host
    feature:android.hardware.wifi
    feature:android.software.live_wallpaper
    feature:android.software.sip
    feature:android.software.sip.voip

Para obter informações mais completas sobre otimizações do compilador, consulte nosso aviso de otimização.