概述

Atlas整个启动过程的时序如下图所示,本篇只关注下图中的1-5步。

入口

我们都知道,app的入口是application,那么atlas的入口application是什么呢,看一下app模块中manifest中的定义

看样子,是DemoApplication
真的是这样的吗?
当然不是

我们看一下反编译后的manifest

为什么会是AtlasBridgeApplication呢,manifest中明明写的很清楚 : DemoApplication。
事实上为了接入的方便,Atlas在编译期就替换了入口application。不过,Atlas保证在运行期时会调用DemoApplication的相关方法。

1. AtlasBridgeApplication.attachBaseContext

我们看一下AtlasBridgeApplication中的相关方法

@Override
protected void attachBaseContext(Context base) {
    super.attachBaseContext(base);
    //...一些逻辑

    //1. 构造BridgeApplicationDelegate对象
    Class BridgeApplicationDelegateClazz = getBaseContext().getClassLoader().loadClass("android.taobao.atlas.bridge.BridgeApplicationDelegate");
    Constructor<?> con = BridgeApplicationDelegateClazz.getConstructor(parTypes);
    mBridgeApplicationDelegate = con.newInstance(this,getProcessName(...);

    //2. 执行BridgeApplicationDelegate的attachBaseContext方法
    Method method = BridgeApplicationDelegateClazz.getDeclaredMethod("attachBaseContext");
    method.invoke(mBridgeApplicationDelegate);
}

可以看到,代码虽长,但其实就只干了两件事。

  • 反射并构造BridgeApplicationDelegate的实例
  • 执行BridgeApplicationDelegate的attachBaseContext方法。

先看BridgeApplicationDelegate的构造方法。

//BridgeApplicationDelegate.java
public BridgeApplicationDelegate(Application rawApplication...){
    mRawApplication = rawApplication;
    PackageManagerDelegate.delegatepackageManager(
        rawApplication.getBaseContext()
    );
}

没什么内容,直接跟进delegatepackageManager的函数实现

//PackageManagerDelegate.java
public static void delegatepackageManager(Context context){
      mBaseContext = context;
      //1. 反射pm
      PackageManager manager = mBaseContext.getPackageManager();
      Class ApplicationPackageManager = Class.forName("android.app.ApplicationPackageManager");
      Field field = ApplicationPackageManager.getDeclaredField("mPM");
      field.setAccessible(true);
      Object rawPm = field.get(manager);
      //2. 动态代理pm
      Class IPackageManagerClass = Class.forName("android.content.pm.IPackageManager");
      mPackageManagerProxyhandler = new PackageManagerProxyhandler(rawPm);            
      mProxyPm = Proxy.newProxyInstance(mBaseContext.getClassLoader(), new Class[]{IPackageManagerClass}, mPackageManagerProxyhandler);
      //3. 替换pm
      field.set(manager, mProxyPm);
}

可以看到,这段代码的核心思想就是将系统的pm,替换为我们实现的PackageManagerProxyhandler。我们先不关注PackageManagerProxyhandler的实现,接着看BridgeApplicationDelegate中函数attachBaseContext的实现。

2. BridgeApplicationDelegate. attachBaseContext

BridgeApplicationDelegate.java

public void attachBaseContext(){
    //2.1 hook之前准备工作
    AtlasHacks.defineAndVerify();

    //2.2 回调预留接口
   launcher.initBeforeAtlas(mRawApplication.getBaseContext());

   //2.3 初始化atlas     
   Atlas.getInstance().init(mRawApplication, mIsUpdated);

   //2.4 处理provider    
    AtlasHacks.ActivityThread$AppBindData_providers.set(mBoundApplication,null);
}

函数实现大概分为四个部分,也是本篇文章的重点关注部分

  • hook之前的准备工作
  • 回调预留接口
  • 初始化atlas
  • 处理provider

我们也一个来看。

3. AtlasHacks.defineAndVerify

在开始分析之前,我们要知道,Android上动态加载方案,始终都绕不过三个关键的点:

  • 动态加载class
  • 动态加载资源
  • 处理四大组件 能够让动态代码中的四大组件在Android上正常跑起来

为了实现这三个目标,会在系统关键调用的地方进行Hook。比如,为了能够动态加载class,通常都会对classloader上动一些手脚,resource也是类似。

这里多提一句,在四大组件的处理上,atals与插件化有着很大的差异。

  • 插件化的核心思想其实是埋坑机制+借尸还魂 :通过预先在manifest中预留N个组件坑,在runtime时,通过“借尸还魂”实现四大组件的运行。
  • atlas不一样,它是在编译期就已经各个bundle的manifest写入到apk中。所以运行时,bundle中的组件可以和常规声明的组件一样正常运行,不用再做额外的处理。

回过头来,我们看看atlas为了实现上述目的,做了哪些准备工作。在跟进defineAndVerify函数的实现之前,先看一下AtlasHacks类中定义的字段

//AtlasHacks.java

     // Classes
    public static HackedClass<Object>                           LoadedApk;
    public static HackedClass<Object>                           ActivityThread;
    public static HackedClass<android.content.res.Resources>    Resources;

    // Fields
    public static HackedField<Object, Instrumentation>          ActivityThread_mInstrumentation;
    public static HackedField<Object, Application>              LoadedApk_mApplication;
    public static HackedField<Object, Resources>                LoadedApk_mResources;

    // Methods
    public static HackedMethod                                  ActivityThread_currentActivityThread;
    public static HackedMethod                                  AssetManager_addAssetPath;
    public static HackedMethod                                  Application_attach;
    public static HackedField<Object, ClassLoader>              LoadedApk_mClassLoader;

    // Constructor
    public static Hack.HackedConstructor                        PackageParser_constructor;

给这段代码点个赞,非常的干净和清晰。代码定义了atlas框架所需要hook的所有的类、方法、属性等等字段。

  • 处理资源,hook Resources
  • 处理class,hook LoadedApk_mClassLoader
  • ...

现在,在看defineAndVerify函数的实现

//AtlasHacks.java
public static boolean defineAndVerify() throws AssertionArrayException {
     allClasses();
     allConstructors();
     allFields();
     allMethods();
}

实际上这四个级别的函数调用,对应之前定义的字段,为这些字段进行赋值。

//AtlasHacks.java
public static void allClasses() throws HackAssertionException {
    LoadedApk = Hack.into("android.app.LoadedApk");
    ActivityThread = Hack.into("android.app.ActivityThread");
    Resources = Hack.into(Resources.class);
    ActivityManager = Hack.into("android.app.ActivityManager");
    //...
}

public static void allFields() throws HackAssertionException {
    ActivityThread_mInstrumentation = ActivityThread.field("mInstrumentation").ofType(Instrumentation.class);
    ActivityThread_mAllApplications = ActivityThread.field("mAllApplications").ofGenericType(ArrayList.class);
}

//...

这几个函数的代码并不复杂,是对定义的Class、Field、Method和Contructor 这些字段进行初始化赋值工作。

执行到这里时,atlas框架的准备工作完成,接下来,就是整个框架的初始化了。

4 回调预留接口

时序图中的第4步,即BridgeApplicationDelegateattachBaseContext方法中,,做了一个接口回调。

BridgeApplicationDelegate.java

public void attachBaseContext(){
   String preLaunchStr = (String) RuntimeVariables.getFrameworkProperty("preLaunch");
   AtlasPreLauncher launcher = (AtlasPreLauncher) Class.forName(preLaunchStr).newInstance();
   launcher.initBeforeAtlas(mRawApplication.getBaseContext());
   //...
}

函数通过“preLaunch”字段读取一个类名,反射该类上的initBeforeAtlas方法。
AtlasPreLauncher实际上是一个接口,供接入者使用。在这个点,atlas还没有开始对系统进行hook,仍然是Android原生态的运行时环境。

那么这个preLaunch的字段在哪里定义的呢,我们反推一下。

RuntimeVariables.java

public static Object getFrameworkProperty(String fieldName){
    //...
    Field field = FrameworkPropertiesClazz.getDeclaredField(fieldName);
    return field.get(FrameworkPropertiesClazz);
}

实现很简单,读取FrameworkProperties上的静态属性字段,接着跟进。

public class FrameworkProperties {
}

什么情况,怎么什么都没有? 所谓反常即为💊,直接看反编译后的代码

FrameworkProperties.java

public class FrameworkProperties{
  //...
  public static String autoStartBundles;
  public static String preLaunch;

  static{
    autoStartBundles = "com.taobao.firstbundle";
    preLaunch = "com.taobao.demo.DemoPreLaunch";
  }
}

从反编译后的代码可以看到,"prelaunch"对应的内容是com.taobao.demo.DemoPreLaunch,那么这个值是在 什么时候写入又是在哪里配置 的呢?

大家回想一下,在之前Atlas之Gradle配置中提到过,atlas的gradle插件在编译期搞了很多事情,我们看gradle中的设置

atlas{
     tBuildConfig {
        autoStartBundles = ['com.taobao.firstbundle']
        preLaunch = 'com.taobao.demo.DemoPreLaunch'
    }
}

FrameworkProperties中的字段完美对应。

这个部分牵涉开发-编译-运行三个阶段,放一张图捋一下关系。

5 atlas.init

准备工作做好之后,就是初始化了。

Atlas.java

public void init(Application application,boolean reset) {
    //读取配置项
    ApplicationInfo appInfo = mRawApplication.get...;
    mRealApplicationName = appInfo.metaData.getString("REAL_APPLICATION");
    boolean multidexEnable = appInfo.metaData.getBoolean("multidex_enable");

    if(multidexEnable){
      MultiDex.install(mRawApplication);
   }
    //...   
}

首先是读取manifest中的配置数据multidexEnablemRealApplicationName,这两个数据也是在编译期由atlas插件写到manifest中的。

multidexEnable 是true,这个在gradle中可配
mRealApplicationName 实际上是DemoApplication,即app工程在manifest中指定的启动路径。

捋清楚这几个参数之后,往下看Atlas框架初始化实现

Atlas.java

public void init(Application application,boolean reset) {
   //...
   Atlas.getInstance().init(mRawApplication, mIsUpdated);
}

public void init(Application application,boolean reset) throws AssertionArrayException, Exception {
     //...

     //1. 换classloader 
     AndroidHack.injectClassLoader(packageName, newClassLoader);
     //2. 换Instrumentatio
     AndroidHack.injectInstrumentationHook(new InstrumentationHook(AndroidHack.getInstrumentation(), application.getBaseContext()));
     //3. hook ams
     try {
         ActivityManagerDelegate activityManagerProxy = new ActivityManagerDelegate();
         Object gDefault = null;
         if(Build.VERSION.SDK_INT>25 || (Build.VERSION.SDK_INT==25&&Build.VERSION.PREVIEW_SDK_INT>0)){
             gDefault=AtlasHacks.ActivityManager_IActivityManagerSingleton.get(AtlasHacks.ActivityManager.getmClass());
         }else{
               gDefault=AtlasHacks.ActivityManagerNative_gDefault.get(AtlasHacks.ActivityManagerNative.getmClass());
         }
         AtlasHacks.Singleton_mInstance.hijack(gDefault, activityManagerProxy);
      }catch(Throwable e){}
      //4. hook H
      AndroidHack.hackH();
}

这段代码,就是对系统关键节点进行了hook,具体的hook实现这里就不贴出了,如果感兴趣,可以参考demo源码以及田维术的blog,如何hook,以及为什么在这里hook,在文章中都讲的非常清楚。

函数中的hook点

hook点 实例
ActivityThread.mLoadedApk.mClassLoader DelegateClassLoader
ActivityThread.mInstrumentation InstrumentationHook
ActivityManagerNative.gDefault.get ActivityManagerDelegate
android.app.ActivityThread$H.mCallback ActivityThreadHook

6. 处理provider

在第2步的2.4部分,对provider进行了处理

BridgeApplicationDelegate.java

public void attachBaseContext(){
    //...

   //2.4 处理provider
   Object mBoundApplication = AtlasHacks.ActivityThread_mBoundApplication.get(activityThread);
   mBoundApplication_provider = AtlasHacks.ActivityThread$AppBindData_providers.get(mBoundApplication);
   if(mBoundApplication_provider!=null && mBoundApplication_provider.size()>0){
           AtlasHacks.ActivityThread$AppBindData_providers.set(mBoundApplication,null);
    }
}

第4行代码读取provider数据,如果有provider信息的话,则在第6行从系统删除,让系统认为apk并没有申请任何provider。

为什么这么做?回顾一下app启动的流程

可以看到,在第4步和第7步两个关键调用之间,第5步调用了函数installContentProviders,跟进去看一下。

private void installContentProviders(Context context, List<ProviderInfo> providers) {
    for (ProviderInfo cpi : providers) {
        installProvider(context, null, cpi,...);
    }
}

收集了所有provider的信息,然后调用installProvider函数

private IActivityManager.ContentProviderHolder installProvider(Context context,IActivityManager.ContentProviderHolder holder, ProviderInfo info,...) {
    final java.lang.ClassLoader cl = c.getClassLoader();
   localProvider = (ContentProvider)cl.loadClass(info.name).newInstance();
   //...
}

可以看到,函数是根据在manifest中登记的provider信息,实例化对象。
那么问题来了,有些provider是存在于bundle中的,主dex中并不存在。如果不处理,在这里程序会因为ClassNotFind崩溃。所以这里要先清除掉provier的信息,延迟加载。


上篇先到这里,各位先喝口水,再来下篇的分析。

results matching ""

    No results matching ""