1.从系统服务 ActivityManagerService开始
我们看 AMS声明:
public class ActivityManagerService extends IActivityManager.Stub
implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
可以看到AMS继承了 IActivityManager.Stub 这类,在代码中是搜索不到这个类的定义的,搜索 IActivityManager可以看到其是在一个 IActivityManager.aidl 文件中声明的接口。
interface IActivityManager {
// Since these transactions are also called from native code, these must be kept in sync with
// the ones in frameworks/native/libs/binder/include/binder/IActivityManager.h
// =============== Beginning of transactions used on native side as well ======================
ParcelFileDescriptor openContentUri(in String uriString);
void registerUidObserver(in IUidObserver observer, int which, int cutpoint,
String callingPackage);
void unregisterUidObserver(in IUidObserver observer);
boolean isUidActive(int uid, String callingPackage);
// =============== End of transactions used on native side as well ============================
// Special low-level communication with activity manager.
void handleApplicationCrash(in IBinder app,
in ApplicationErrorReport.ParcelableCrashInfo crashInfo);
int startActivity(in IApplicationThread caller, in String callingPackage, in Intent intent,
in String resolvedType, in IBinder resultTo, in String resultWho, int requestCode,
int flags, in ProfilerInfo profilerInfo, in Bundle options);
可以看到这里只是声明了 IActivityManager接口,以及接口里的一些函数,并没有函数的实现,也没有 IActivityManager.Stub的声明。
实际上,这个 aidl 在代码运行的时候也没有用处,aidl 文件存在的意义在于它可以指导编译过程帮助我们实现有一定特定套路的适合 Binder 通信的 Java 代码的实现。
像 IActivityManager.Stub这个类实际就是编译阶段根据 IActivityManager.aidl 生成 IActivityManager.java 这个Java文件的时候自动生成的一个辅助Binder通信的类。当我们编译完成代码后,生成的 IActivityManager.java文件会在源码的out目录下:
test@1:~/source/out$ find . -name IActivityManager.java
./target/common/obj/JAVA_LIBRARIES/framework-full_check_intermediates/core/java/android/app/IActivityManager.java
./target/common/obj/JAVA_LIBRARIES/framework-full_intermediates/core/java/android/app/IActivityManager.java
./target/common/obj/JAVA_LIBRARIES/framework-base_intermediates/core/java/android/app/IActivityManager.java
^C
这个文件最终会被编译到对应的 dex文件中去。我们看看这个文件:
/*
* This file is auto-generated. DO NOT MODIFY.
* Original file: frameworks/base/core/java/android/app/IActivityManager.aidl
*/
package android.app;
/**
* System private API for talking with the activity manager service. This
* provides calls from the application back to the activity manager.
*
* {@hide}
*/
public interface IActivityManager extends android.os.IInterface
{
/** Local-side IPC implementation stub class. */
public static abstract class Stub extends android.os.Binder implements android.app.IActivityManager
{
private static final java.lang.String DESCRIPTOR = "android.app.IActivityManager";
文件开头的注释很清晰了:
/*
* This file is auto-generated. DO NOT MODIFY.
* Original file: frameworks/base/core/java/android/app/IActivityManager.aidl
*/
接下来我们发现 IActivityManager 被声明成一个 interface,且继承了 android.os.IInterface 这个接口。
public interface IInterface
{
/**
* Retrieve the Binder object associated with this interface.
* You must use this instead of a plain cast, so that proxy objects
* can return the correct result.
*/
public IBinder asBinder();
}
IInterface 只有一个接口函数需要实现,就是 asBinder函数,这里暂不深究。
我们看看Stub是个什么东西:
public static abstract class Stub extends android.os.Binder implements android.app.IActivityManager {
IActivityManager.Stub继承了 android.os.Binder 且实现了 IActivityManager 接口,IActivityManager.aidl中声明的接口,都会在 Stub中实现,稍后我们再看接口函数的实现。
由于 ActivityManagerService extends IActivityManager.Stub,所以 AMS对象也是会继承Binder,同时需要实现 IActivityManager 里面的所有接口函数。
我们还是从怎么使用AMS开始分析,首先是 getService,上一篇已经分析过:
mCallingUid = ActivityManager.getService().getLaunchedFromUid(activityToken);
getService返回的是一个 IActivityManager的实例对象:
public static IActivityManager getService() {
return IActivityManagerSingleton.get();
}
private static final Singleton<IActivityManager> IActivityManagerSingleton =
new Singleton<IActivityManager>() {
@Override
protected IActivi