Contents
Debug Third-Party Vendor Applications
Debug Java application
Debug x86 native library of application
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:
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
smali:Make smali files into classes.dex files.
Command: java -Xmx512M -jar smali.jar out -o classes.dex
keytool: Create apk certificates.
keytool -genkey -v -alias CERT -keyalg RSA -keysize 2048 -validity 10000 -keystore CERT.keystore
jarsigner:apk sign tool
jarsigner -verbose -keystore CERT.keystore to_sign.apk CERT
dex2jar:Decompile classes.dex into jar file
JD-GUI: Check Java source from jar file
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
AXMLPrinter:Convert apk’s xml file into readable file.
Download link: http://code.google.com/p/android4me/downloads/list
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:
Add a log in smali code
Add more registers in the “.local” variable, e.g., v11,v12
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
Print call stack in smali:
Add a register in “.local” variable. e.g., v11
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
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:
The variable list isn’t consistent with declaration:
2. The routine call type is incorrect
For example: Use invoke-virtual for public/package routine. Use invoke-director for private routine.
3. apk is not signed properly
4. Use adb logcat | grep mismatch to check which package signature is incorrect
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:
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
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.
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:
Use invoke-virtual/range {p1 .. p1} instruction
Add move-object/from16 v0, v18 instruction
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.
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.
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:
Tag | Type | Name/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
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
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
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
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:
Get the code base related to the bug
Build the code base for the bug
cd <aosp>/out/target/product/<platform>/symbols/system/lib. There will be a symbol for lib here
objdump -d libjni_latinime.so > tmp.log to decompile the lib
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]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.
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
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
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.
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); ... }
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:
sim card location difference (sim cards in the U.S., China, France have different 3G locations)
Wi-Fi*/3G Internet connection differences. Some apps have specific locations or requirements for Wi-Fi/3G connection.
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.
Screen resolution/dpi constriction. Many applications have requirements for on screen resolution/dpi to work.
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