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. 其它堆栈信息查询