A72n企业开发者实现方案.md

A72n企业开发者实现方案

官方接入文档:https://bdev.oppo.com.

• oppo_mdm_sdk.jar分析 通过官方文档提供的依赖方式为compileOnly猜测该jar只是提供编译时依赖的，真正的实现是在系统的framework里面，反编译分析发现该jar里面都是空实现，猜想得以验证。 为了进一步验证系统中是否有相关的类，采用写代码的方案来验证，反射查看系统中是否存在sdk中相关的类：

  try {
            Class klazz = Class.forName("com.oppo.enterprise.mdmcoreservice.manager.DeviceControlerManager");
            Log.e("ooooo", "ooooo klazz = " + klazz);
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
  

wtf,抛异常了“Class Not Found”,难道猜测错误了？进一步分析该异常的原因，猜测： 1.oppo修改了ClassLoader的相关记载机制，无权限不加载； 2.oppo对dexPath做了改动，加入了相关权限验证。

反编译framework

全文搜索com.oppo.enterprise.mdmcoreservice发现了LoadedApk这个类中有相关的字符串，找到相关代码：

public static void makePaths(ActivityThread activityThread, boolean isBundledApp, ApplicationInfo aInfo, List<String> outZipPaths, List<String> outLibPaths) {
        ...
        if (activityThread != null) {
            try {
                if (ActivityThread.getPackageManager().hasSystemFeature("oppo.business.custom", 0) && ActivityThread.getPackageManager() != null && isPackageContainsOppoCertificates(aInfo.packageName)) {
                    addCustomMdmJarToPath(outZipPaths);
                }
            } catch (Exception e) {
                Log.w(TAG, "addCustomMdmJarToPath errror");
            }
        }
        ...
    }

    private static void addCustomMdmJarToPath(List<String> outPaths) {
        outPaths.add(Environment.getOppoCustomDirectory().getAbsolutePath() + "/framework/OppoMdmInterface.jar");
        outPaths.add(Environment.getOppoCustomDirectory().getAbsolutePath() + "/framework/OppoMdmAdapter.jar");
    }

至此发现该jar包的加载机制：当机型是定制机且该应用里面包含oppo的证书时才会将相关的jar包添加到dexpath中。 相关的jar包存放在/my_custom目录下，进一步发现该目录下存在sdk的framework实现及server端的相关实现，server的代码存放在/my_custom/priv-app/OppoMdmCoreService/OppoMdmCoreService.apk中，该apk具有system权限，在该apk里面实现了oppo证书校验及相关定制接口的能力。这样做的好处是尽量少改动系统server端的代码，通过代理apk和运行在system_server进程中的oppomdmservice通信。具体实现可参考OppoMdmCoreService.apk。