android動態分析
⑴ Android 動態廣播 和 靜態廣播的區別
同一優先順序的廣播接收器，動態的要比靜態注冊的早。 動態注冊：即由代碼注冊的廣播接收器靜態注冊：即在 AndroidManifest.xml 中注冊的廣播接收器 優先順序： 當廣播為有序發送的時候，要按這個排序並順序發送。 sendBroadcast 發送的是無序廣播。sendOrderedBroadcast 發送的是有序廣播。 好了，現在尋找問題原因，在找原因前肯定有這樣的想法，一個有序隊列，既然允許有相同的優先順序存在，那麼在同優先順序內要不然有排序子因素，要不基就是按照某種操作可能影響順序。後者可能性很大。 打開源碼，順著 動態注冊廣播接受器 找，最後是 ActivityManagerService.java 這個文件找到了 registerReceiver 的實現。同地也看到，存儲的廣播接收器列表是 HashMap mRegisteredReceivers 這個變理。 裡面有一段代碼為： ReceiverList rl = (ReceiverList)mRegisteredReceivers.get(receiver.asBinder()); if (rl == null) { rl = new ReceiverList(this, callerApp, Binder.getCallingPid(), Binder.getCallingUid(), receiver); if (rl.app != null) { rl.app.receivers.add(rl); } else { try { receiver.asBinder().linkToDeath(rl, 0); } catch (RemoteException e) { return sticky; } rl.linkedToDeath = true; } mRegisteredReceivers.put(receiver.asBinder(), rl); } 在裡面查找有沒有這個 Receiver ， 如果沒有 put 進去。 看到這里貌似沒有對廣播的順序做處理。是不是有別的地方做排序呢，找找成員變理，發現一個可疑的變數：final ArrayList mOrderedBroadcasts沒錯，感覺就應該是它了。 找找對它的操作，只有一處 mOrderedBroadcasts.set ，把代碼摘錄一下： BroadcastRecord r = new BroadcastRecord(intent, callerApp, callerPackage, callingPid, callingUid, requiredPermission, sticky, false); mOrderedBroadcasts.set(i, r);在這里放入了一個 BroadcastRecord 對像，而這個對像中主要的東西其實是 receivers向上跟蹤 int NT = receivers != null ? receivers.size() : 0; int it = 0; ResolveInfo curt = null; BroadcastFilter curr = null; while (it < NT && ir < NR) { if (curt == null) { curt = (ResolveInfo)receivers.get(it); } if (curr == null) { curr = registeredReceivers.get(ir); } if (curr.getPriority() >= curt.priority) { // Insert this broadcast record into the final list. receivers.add(it, curr); ir++; curr = null; it++; NT++; } else { // Skip to the next ResolveInfo in the final list. it++; curt = null; } } 發現了一段 對 receivers 排序的代碼，並且判斷也是 priority 的值，用的是 >= 方式 感覺的找到了地方，但是對 Activity Manager Service 這個模塊卻更加的不懂了，以後有機會一定要分析一下這塊是怎樣設計的，才能確定本文的問題所在。暫時記錄，以後分析！
⑵ androidkillsamli2_class未找到apk源碼
bbsmax
androidkiller未找到對應的apk源碼
解決AndroidKiller APK 反編譯失敗，無法繼續下一步源碼反編譯!
查看安卓APK源碼破解
如何查看華為EMUI系統APK源碼？
Mybatis Mapper介面是如何找到實現類的-源碼分析
Android動態方式破解apk前奏篇(Eclipse動態調試smail源碼)
android.mk android源碼編譯
Android事件傳遞機制詳解及最新源碼分析——Activity篇
Django-restframework 之認證源碼分析
Mybatis 源碼學習系列
基於JDK1.8，Java容器源碼分析
vue2源碼分析:patch函數
Jdk源碼-集合類主要原理和解析
Struts2 源碼分析——Hello world
【原創】express3.4.8源碼解析之中間件
【分享】Maven插件的源碼下載（SVN）
10個經典的Android開源項目(附源碼包)
json.net 比jsonIgnore 更好的方法 修改源碼
編譯 wl18xx驅動源碼
微信小程序源碼推薦
WPF 依賴屬性源碼 洞察微軟如何實現DependencyProperty
Cytoscape源碼下載地址和編譯辦法
熱門專題
ABAP的CASE WHENSPRINGBOOT 接收參數實體屬性名映射別名REDISTEMPLATE 死循環ROBOTFRAMWORK RIDE開發版本2.0BUNITY 設置LAYERMASKUNIAPP啟動獲取配置EXCEL表格之間去除關聯開源SSL證書生成 WEB工具KICAD隱藏敷銅重新布線TARJAN求強連通分量WORD英文狀態下加NON-BREAKING SPACECAP 怎麼設置RABBITMQ訂閱者名字自行定義泛化名字進行替換原文WAN口之間的底層通信原理AKKA2.1.0官方ISUPEROBJECT轉化為字元串C# STRING轉DOUBLE保留STRING小數點後的0MAC NTFS 插件BITBUCKET備份恢復MATLABGUI滑鼠響應事件
Home
Powered By WordPress
⑶ Android-ARouter原理解析
ARouter使用的是APT（Annotation Processing Tool）註解處理器，通過給對應的類添加註解，在編譯器動態生成對應的路由表文件。這里以分析ARouter的RouteProcessor。在ARouter的使用配置上，需要給base庫配置
然後給每個組件都配置annotationProcessor，如果使用kotlin，則使用kapt
接著給每個組件都配置上下面的內容：
這個配置主要是通過這個annotationProcessorOptions獲取到key為AROUTER_MODULE_NAME的值，這個值其實就是mole的name，這個的作用就是作為一個Root文件的命名的，因為一個mole中可能會有多個group，而多個group歸屬於一個Root，而ARouter的做法就是將一個mole作為一個Root。
Element 是一個介面，它只在編譯期存在和Type有區別，表示程序的一個元素，可以是package，class，interface，method,成員變數，函數參數，泛型類型等。
它的子類包括ExecutableElement, PackageElement, Parameterizable, QualifiedNameable, TypeElement, TypeParameterElement, VariableElement。
Element的子類介紹：
ExecutableElement:表示類或者介面中的方法，構造函數或者初始化器。
PackageElement :表示包程序元素
TypeELement:表示一個類或者介面元素
TypeParameterElement:表示類，介面，方法的泛型類型例如T。
VariableElement：表示欄位，枚舉常量，方法或者構造函數參數，局部變數，資源變數或者異常參數。
Element只在編譯期可見
asType()： 返回TypeMirror,TypeMirror是元素的類型信息，包括包名，類(或方法，或參數)名/類型。TypeMirror的子類有ArrayType, DeclaredType, DisjunctiveType, ErrorType, ExecutableType, NoType, NullType, PrimitiveType, ReferenceType, TypeVariable, WildcardType ，getKind可以獲取類型。
equals(Object obj)： 比較兩個Element利用equals方法。
getAnnotation(Class<A> annotationType)： 傳入註解可以獲取該元素上的所有註解。
getAnnotationMirrors()： 獲該元素上的註解類型。
getEnclosedElements()： 獲取該元素上的直接子元素，類似一個類中有VariableElement。
getEnclosingElement()： 獲取該元素的父元素,如果是PackageElement則返回null，如果是TypeElement則返回PackageElement，如果是TypeParameterElement則返回泛型Element
getKind()：返回值為ElementKind,通過ElementKind可以知道是那種element，具體就是Element的那些子類。
getModifiers()： 獲取修飾該元素的訪問修飾符，public，private。
getSimpleName()： 獲取元素名，不帶包名，如果是變數，獲取的就是變數名，如果是定義了int age，獲取到的name就是age。如果是TypeElement返回的就是類名。
getQualifiedName()：獲取類的全限定名，Element沒有這個方法它的子類有，例如TypeElement，得到的就是類的全類名（包名）。
具體的註解處理流程如下：
首先，看下屬性註解處理器生成的文件示例：
AutowiredProcessor這個註解處理器的目的，就是通過這個註解處理器給對應的類中的屬性進行賦值的操作。
AutowiredProcessor註解處理器流程：
⑷ Android Native庫的載入及動態鏈接
我們從一個簡單的NDK Demo開始分析。
下面從 System.loadLibrary() 開始分析。
下面看 loadLibrary0()
參數 loader 為Android的應用類載入器，它是 PathClassLoader 類型的對象，繼承自 BaseDexClassLoader 對象，下面看 BaseDexClassLoader 的 findLibrary() 方法。
下面看 DexPathList 的 findLibrary() 方法
回到 loadLibrary0() ，有了動態庫的全路徑名就可以裝載庫了，下面看 doLoad() 。
nativeLoad() 最終調用 LoadNativeLibrary() ，下面直接分析 LoadNativeLibrary() 。
對於JNI注冊，這里暫不討論，下面看 OpenNativeLibrary() 的實現。
下面看 android_dlopen_ext() 的實現
接下來就Android鏈接器linker的工作了。
下面從 do_dlopen() 開始分析。
find_library() 當參數translated_name不為空時，直接調用 find_libraries() ，這是裝載鏈接的關鍵函數，下面看它的實現。
find_libraries() 中動態庫的裝載可以分為兩部分
下面從 find_library_internal() 開始分析。
下面分析 load_library()
下面看另一個 load_library() 的實現
下面分析ELF文件頭以及段信息的讀取過程，也就是LoadTask的 read() ，它直接調用ElfReader的 Read() 方法。
動態庫的裝載在LoadTask的 load() 中實現。
下面看ElfReader的 Load() 方法
動態庫的裝載已經完成，下面看鏈接過程。
下面看 prelink_image()
鏈接主要完成符號重定位工作，下面從 link_image() 開始分析
下面以函數引用重定位為例分析 relocate() 方法
⑸ 手機調試Android程序出異常時不列印堆棧信息
列印堆棧是調試的常用方法，一般在系統異常時，我們可以將異常情況下的堆棧列印出來，這樣十分方便錯誤查找。實際上還有另外一個非常有用的功能：分析代碼的行為。android代碼太過龐大復雜了，完全的靜態分析經常是無從下手，因此通過列印堆棧的動態分析也十分必要。
Android列印堆棧的方法，簡單歸類一下
1. zygote的堆棧mp
實際上這個可以同時mp java線程及native線程的堆棧，對於java線程，java堆棧和native堆棧都可以得到。
使用方法很簡單，直接在adb shell或串口中輸入：
[plain] view plain
kill -3 <pid>
輸出的trace會保存在 /data/anr/traces.txt文件中。這個需要注意，如果沒有 /data/anr/這個目錄或/data/anr/traces.txt這個文件，需要手工創建一下，並設置好讀寫許可權。
如果需要在代碼中，更容易控制堆棧的輸出時機，可以用以下命令獲取zygote的core mp:
[java] view plain
Process.sendSignal(pid, Process.SIGNAL_QUIT);
原理和命令行是一樣的。
不過需要注意兩點：
adb shell可能會沒有許可權，需要root。
android 4.2中關閉了native thread的堆棧列印，詳見 dalvik/vm/Thread.cpp的mpNativeThread方法：
[cpp] view plain
dvmPrintDebugMessage(target,
"\"%s\" sysTid=%d nice=%d sched=%d/%d cgrp=%s\n",
name, tid, getpriority(PRIO_PROCESS, tid),
schedStats.policy, schedStats.priority, schedStats.group);
mpSchedStat(target, tid);
// Temporarily disabled collecting native stacks from non-Dalvik
// threads because sometimes they misbehave.
//dvmDumpNativeStack(target, tid);
Native堆棧的列印被關掉了！不過對於大多數情況，可以直接將這個注釋打開。
2. debuggerd的堆棧mp
debuggerd是android的一個daemon進程，負責在進程異常出錯時，將進程的運行時信息mp出來供分析。debuggerd生 成的coremp數據是以文本形式呈現，被保存在 /data/tombstone/ 目錄下(名字取的也很形象，tombstone是墓碑的意思)，共可保存10個文件，當超過10個時，會覆蓋重寫最早生成的文件。從4.2版本開 始，debuggerd同時也是一個實用工具：可以在不中斷進程執行的情況下列印當前進程的native堆棧。使用方法是:
[plain] view plain
debuggerd -b <pid>
這可以協助我們分析進程執行行為，但最最有用的地方是：它可以非常簡單的定位到native進程中鎖死或錯誤邏輯引起的死循環的代碼位置。
3. java代碼中列印堆棧
Java代碼列印堆棧比較簡單， 堆棧信息獲取和輸出，都可以通過Throwable類的方法實現。目前通用的做法是在java進程出現需要注意的異常時，列印堆棧，然後再決定退出或挽救。通常的方法是使用exception的printStackTrace()方法：
[java] view plain
try {
...
} catch (RemoteException e) {
e.printStackTrace();
...
}
當然也可以只列印堆棧不退出，這樣就比較方便分析代碼的動態運行情況。Java代碼中插入堆棧列印的方法如下：
[java] view plain
Log.d(TAG,Log.getStackTraceString(new Throwable()));
4. C++代碼中列印堆棧
C++也是支持異常處理的，異常處理庫中，已經包含了獲取backtrace的介面，Android也是利用這個介面來列印堆棧信息的。在Android的C++中，已經集成了一個工具類CallStack，在libutils.so中。使用方法：
[cpp] view plain
#include <utils/CallStack.h>
...
CallStack stack;
stack.update();
stack.mp();
使用方式比較簡單。目前Andoid4.2版本已經將相關信息解析的很到位，符號表查找，demangle，偏移位置校正都做好了。
[plain] view plain
5. C代碼中列印堆棧
C代碼，尤其是底層C庫，想要看到調用的堆棧信息，還是比較麻煩的。 CallStack肯定是不能用，一是因為其實C++寫的，需要重新封裝才能在C中使用，二是底層庫反調上層庫的函數，會造成鏈接器循環依賴而無法鏈接。 不過也不是沒有辦法，可以通過android工具類CallStack實現中使用的unwind調用及符號解析函數來處理。
這里需要注意的是，為解決鏈接問題，最好使用dlopen方式，查找需要用到的介面再直接調用，這樣會比較簡單。如下為相關的實現代碼，只需要在要 列印的文件中插入此部分代碼，然後調用getCallStack()即可，無需包含太多的頭文件和修改Android.mk文件：
[cpp] view plain
#define MAX_DEPTH 31
#define MAX_BACKTRACE_LINE_LENGTH 800
#define PATH "/system/lib/libcorkscrew.so"
typedef ssize_t (*unwindFn)(backtrace_frame_t*, size_t, size_t);
typedef void (*unwindSymbFn)(const backtrace_frame_t*, size_t, backtrace_symbol_t*);
typedef void (*unwindSymbFreeFn)(backtrace_symbol_t*, size_t);
static void *gHandle = NULL;
static int getCallStack(void){
ssize_t i = 0;
ssize_t result = 0;
ssize_t count;
backtrace_frame_t mStack[MAX_DEPTH];
backtrace_symbol_t symbols[MAX_DEPTH];
unwindFn unwind_backtrace = NULL;
unwindSymbFn get_backtrace_symbols = NULL;
unwindSymbFreeFn free_backtrace_symbols = NULL;
// open the so.
if(gHandle == NULL) gHandle = dlopen(PATH, RTLD_NOW);
// get the interface for unwind and symbol analyse
if(gHandle != NULL) unwind_backtrace = (unwindFn)dlsym(gHandle, "unwind_backtrace");
if(gHandle != NULL) get_backtrace_symbols = (unwindSymbFn)dlsym(gHandle, "get_backtrace_symbols");
if(gHandle != NULL) free_backtrace_symbols = (unwindSymbFreeFn)dlsym(gHandle, "free_backtrace_symbols");
if(!gHandle ||!unwind_backtrace ||!get_backtrace_symbols || !free_backtrace_symbols ){
ALOGE("Error! cannot get unwind info: handle:%p %p %p %p",
gHandle, unwind_backtrace, get_backtrace_symbols, free_backtrace_symbols );
return result;
}
count= unwind_backtrace(mStack, 1, MAX_DEPTH);
get_backtrace_symbols(mStack, count, symbols);
for (i = 0; i < count; i++) {
char line[MAX_BACKTRACE_LINE_LENGTH];
const char* mapName = symbols[i].map_name ? symbols[i].map_name : "<unknown>";
const char* symbolName =symbols[i].demangled_name ? symbols[i].demangled_name : symbols[i].symbol_name;
size_t fieldWidth = (MAX_BACKTRACE_LINE_LENGTH - 80) / 2;
if (symbolName) {
uint32_t pc_offset = symbols[i].relative_pc - symbols[i].relative_symbol_addr;
if (pc_offset) {
snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d pc %08x %.*s (%.*s+%u)",
i, symbols[i].relative_pc, fieldWidth, mapName,
fieldWidth, symbolName, pc_offset);
} else {
snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d pc %08x %.*s (%.*s)",
i, symbols[i].relative_pc, fieldWidth, mapName,
fieldWidth, symbolName);
}
} else {
snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d pc %08x %.*s",
i, symbols[i].relative_pc, fieldWidth, mapName);
}
ALOGD("%s", line);
}
free_backtrace_symbols(symbols, count);
return result;
}
對sched_policy.c的堆棧調用分析如下,注意具體是否要列印，在哪裡列印，還可以通過pid、uid、property等來控制一下，這樣就不會被淹死在trace的汪洋大海中。
[plain] view plain
D/SchedPolicy( 1350): #00 pc 0000676c /system/lib/libcutils.so
D/SchedPolicy( 1350): #01 pc 00006b3a /system/lib/libcutils.so (set_sched_policy+49)
D/SchedPolicy( 1350): #02 pc 00010e82 /system/lib/libutils.so (androidSetThreadPriority+61)
D/SchedPolicy( 1350): #03 pc 00068104 /system/lib/libandroid_runtime.so (android_os_Process_setThreadPriority(_JNIEnv*, _jobject*, int, int)+7)
D/SchedPolicy( 1350): #04 pc 0001e510 /system/lib/libdvm.so (dvmPlatformInvoke+112)
D/SchedPolicy( 1350): #05 pc 0004d6aa /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+417)
D/SchedPolicy( 1350): #06 pc 00027920 /system/lib/libdvm.so
D/SchedPolicy( 1350): #07 pc 0002b7fc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
D/SchedPolicy( 1350): #08 pc 00060c30 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+271)
D/SchedPolicy( 1350): #09 pc 0004cd34 /system/lib/libdvm.so
D/SchedPolicy( 1350): #10 pc 00049382 /system/lib/libandroid_runtime.so
D/SchedPolicy( 1350): #11 pc 00065e52 /system/lib/libandroid_runtime.so
D/SchedPolicy( 1350): #12 pc 0001435e /system/lib/libbinder.so (android::BBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+57)
D/SchedPolicy( 1350): #13 pc 00016f5a /system/lib/libbinder.so (android::IPCThreadState::executeCommand(int)+513)
D/SchedPolicy( 1350): #14 pc 00017380 /system/lib/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+183)
D/SchedPolicy( 1350): #15 pc 0001b160 /system/lib/libbinder.so
D/SchedPolicy( 1350): #16 pc 00011264 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+111)
D/SchedPolicy( 1350): #17 pc 000469bc /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+63)
D/SchedPolicy( 1350): #18 pc 00010dca /system/lib/libutils.so
D/SchedPolicy( 1350): #19 pc 0000e3d8 /system/lib/libc.so (__thread_entry+72)
D/SchedPolicy( 1350): #20 pc 0000dac4 /system/lib/libc.so (pthread_create+160)
D/SchedPolicy( 1350): #00 pc 0000676c /system/lib/libcutils.so
D/SchedPolicy( 1350): #01 pc 00006b3a /system/lib/libcutils.so (set_sched_policy+49)
D/SchedPolicy( 1350): #02 pc 00016f26 /system/lib/libbinder.so (android::IPCThreadState::executeCommand(int)+461)
D/SchedPolicy( 1350): #03 pc 00017380 /system/lib/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+183)
D/SchedPolicy( 1350): #04 pc 0001b160 /system/lib/libbinder.so
D/SchedPolicy( 1350): #05 pc 00011264 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+111)
D/SchedPolicy( 1350): #06 pc 000469bc /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+63)
D/SchedPolicy( 1350): #07 pc 00010dca /system/lib/libutils.so
D/SchedPolicy( 1350): #08 pc 0000e3d8 /system/lib/libc.so (__thread_entry+72)
D/SchedPolicy( 1350): #09 pc 0000dac4 /system/lib/libc.so (pthread_create+160)
6. 其它堆棧信息查詢