每日一问 | Call requires API level 23 (current min is 14) 扫描出来的原理是？

本篇回答将给大家介绍以下知识点：

1. Android Studio检测New API具体原理；
2. 功能原理分析的思路&技巧；
3. 同步Android Studio源码；
4. Debug Android Studio；

Android Studio检测New API的原理？

先简单概况一下： Android Studio的Editor会在每一次内容变更完毕后，给一个叫alarm pool的线程池提交一个MergingUpdateQueue（实现了Runnable），这个MergingUpdateQueue最终会执行到LintDriver的analyze方法，也算是Lint的入口了。

在检查文件之前，首先会初始化一个ApiLookup对象，这个对象在初始化时也会加载项目compileSdkVersion所对应的api-versions.xml文件，以byte[]的形式保存在内存中（不是文件流的byte[]哦，是处理过后的数据，可以通过索引来快速定位到某个类和某个方法的），同时还会写出到 /root/.AndroidStudio4.0/system/lint/ 目录下（我的是Linux系统，其他系统的目录应该会有变更），以bin作为后缀保存（下次会优先读取这个bin文件，如果那个api-versions.xml没有被修改过的话）。

当ApiVisitor开始visitCallExpression，调用ApiLookup的getMethodVersion方法获取目标方法【首次出现的版本号】时，就能通过索引从那个byte[]中快速取出，然后对比minSdk，如果比minSdk大的话，证明目标方法是New API，这时候就会反馈错误了。

详细分析：

咋一看这个问题感觉有点无从下手，就算知道它在哪里开启，知道它关联的是哪个文件，那又怎样？在没有AS源码的情况下，怎么能定位到具体代码位置呢？

其实我们可以用做逆向的方法：根据界面显示的一些相关的词来搜索。

在哪里搜？

当然是Android Studio程序目录里的plugins文件夹了，了解Android Studio的同学会知道，Android Studio只不过是IntelliJ IDEA中一个比较大型的插件，再加上对IntelliJ IDEA做了点修改而已，所以Android Studio特有的功能，基本上都会以jar的形式存放在plugins目录下。

我们可以用grep（Windows的同学可以去开那个Linux子系统）先定位到对应jar文件，再找到对应的class。关键词，就试试 @Reginer 同学说的设置里面的那个开关吧：

命令： grep -rn "Calling new methods on older versions"

嗯，一共有两个jar包含这个关键词，分别解压一下，然后进一步定位到具体文件，先是sdk-tools.jar：

搜到一个叫ApiDetector的class，而且这个class所在目录也有lint字眼，先记下来。

看看android.jar：

我们重点看第一条结果，com/android/tools/idea/lint/android-lint.xml第195行：

<globalInspection 
    hasStaticDescription="true" 
    shortName="AndroidLintNewApi" 
    displayName="Calling new methods on older versions" 
    bundle="messages.AndroidBundle" 
    enabledByDefault="true"
    level="ERROR"
    implementationClass="com.android.tools.idea.lint.AndroidLintNewApiInspection"/>

里面有个implementationClass属性，指向了一个叫AndroidLintNewApiInspection的类，对照着包名从解压出来的目录中找到这个class，拖进AS里（反编译）看看：

package com.android.tools.idea.lint;

import com.android.tools.lint.checks.ApiDetector;
import org.jetbrains.android.util.AndroidBundle;

public class AndroidLintNewApiInspection extends AndroidLintApiInspection {
    public AndroidLintNewApiInspection() {
        super(AndroidBundle.message("android.lint.inspections.new.api", new Object[0]), ApiDetector.UNSUPPORTED);
    }
}

咦？这个AndroidLintNewApiInspection导了刚刚在sdk-tools那边搜到的包含 "Calling new methods on older versions" 关键词的ApiDetector，还把ApiDetector的UNSUPPORTED传给了父类构造方法！

那现在来看看ApiDetector这个类以及它里面的UNSUPPORTED是什么：

直接拖进AS里会发现，这个类是用Kotlin写的，只能列出一些方法还有变量的声明，不能完全反编译。

用jadx打开看下吧：

public final class ApiDetector extends ResourceXmlDetector implements SourceCodeScanner, ResourceFolderScanner {

    ......

    @NotNull
    @JvmField
    public static final Issue UNSUPPORTED = Issue.Companion.create$default(Issue.Companion, "NewApi", "Calling new methods on older versions", "\n" +
     "                This check scans through all the Android API calls in the application and \\\n" +
      "                warns about any calls that are not available on **all** versions targeted by \\\n" +
       "                this application (according to its minimum SDK attribute in the manifest).\n\n" +
        "                If you really want to use this API and don't need to support older devices \\\n" +
         "                just set the `minSdkVersion` in your `build.gradle` or `AndroidManifest.xml` \\\n" +
          "                files.\n\n" +
           "                If your code is **deliberately** accessing newer APIs, and you have ensured \\\n" +
            "                (e.g. with conditional execution) that this code will only ever be called on \\\n" +
             "                a supported platform, then you can annotate your class or method with the \\\n" +
              "                `@TargetApi` annotation specifying the local minimum SDK to apply, such as \\\n" +
               "                `@TargetApi(11)`, such that this check considers 11 rather than your manifest \\\n" +
                "                file's minimum SDK as the required API level.\n\n" +
                 "                If you are deliberately setting `android:` attributes in style definitions, \\\n" +
                  "                make sure you place this in a `values-v`*NN* folder in order to avoid running \\\n" +
                   "                into runtime conflicts on certain devices where manufacturers have added \\\n" +
                    "                custom attributes whose ids conflict with the new ones on later platforms.\n\n" +
                     "                Similarly, you can use tools:targetApi=\"11\" in an XML file to indicate that \\\n" +
                      "                the element will only be inflated in an adequate context.\n" +
                       "                ", new Implementation(ApiDetector.class, EnumSet.of(Scope.JAVA_FILE, Scope.RESOURCE_FILE, Scope.MANIFEST),
                     Scope.JAVA_FILE_SCOPE, Scope.RESOURCE_FILE_SCOPE, Scope.MANIFEST_SCOPE), 
                    (String) null, Category.CORRECTNESS, 6, Severity.ERROR, false, true, (EnumSet) null, (Collection) null, 3344, (Object) null);

    ......

}

原来这个UNSUPPORTED是一个Issue！

接着往下看，Implementation的detectorClass它填的就是ApiDetector。还可以看到ApiDetector实现了SourceCodeScanner（熟悉Lint API的同学会知道UastScanner接口的方法都是来自于SourceCodeScanner的），SourceCodeScanner中有个createUastHandler方法，需要返回一个UElementHandler（检查代码的主要逻辑都在这个UElementHandler里面）看看ApiDetector它是怎么实现的：

public final class ApiDetector extends ResourceXmlDetector implements SourceCodeScanner, ResourceFolderScanner {

    ......

    @Nullable
    public UElementHandler createUastHandler(@NotNull JavaContext context) {
        if (this.apiDatabase == null || context.isTestSource() || !context.getMainProject().isAndroidProject()) {
            return null;
        }
        return new ApiVisitor(context);
    }

    ......

    private final class ApiVisitor extends UElementHandler {
        ......
    }
}

emmmm，它返回的是内部类ApiVisitor的实例。想一下，会出现题目中所说的 “Call requires API level 23 (current min is 14)“ ，都是在调用某个方法时出现的，也就是说，这个提示针对的是方法调用，而在UElementHandler中，【分析方法调用】的方法就是visitCallExpression，看看ApiVisitor是怎么重写的：

private final class ApiVisitor extends UElementHandler {

        public void visitCallExpression(@NotNull UCallExpression node) {
            PsiMethod method = node.resolve();
            if (method == null) {
                ......
                return;
            }
            visitCall(method, node, (UElement) node);
        }

        private final void visitCall(PsiMethod method, UCallExpression call, UElement reference) {
            int minSdk;
            int methodApi;
            ApiLookup apiDatabase = ApiDetector.this.apiDatabase;
            if (apiDatabase != null) {

                ......               

                if (!ApiLookup.startsWithEquivalentPrefix(owner, "android/support/")) {
                    String desc = evaluator.getMethodDescription(method, false, false);

                    ......

                    if (desc != null) {
                        int api = apiDatabase.getMethodVersion(owner, name, desc);
                        if (api != -1 && api > (minSdk = ApiDetector.this.getMinSdk(this.context))) {

                            ......

                            if (!ApiDetector.Companion.isSuppressed(this.context, api, reference, minSdk)) {
                                 report(ApiDetector.UNSUPPORTED, reference, location, "Call", signature, api, minSdk, ApiDetector.Companion.apiLevelFix(api), owner, name, desc);
                            }
                        }
                    }
                }
            }
        }
}

逻辑很清晰，检查是否New API的逻辑在后面的visitCall方法中：它首先会判断目标class的包名是不是android.support开头的（support包的代码不用检查），然后对比【目标方法首次出现的版本】和【项目中的minSdk版本】，如果前者更大，那么在minSdk的设备上运行，就很有可能会出问题了，所以接下来会调用report方法（如果没有加Suppress注解的话），看下它里面做了什么：

public final class ApiDetector extends ResourceXmlDetector implements SourceCodeScanner, ResourceFolderScanner {

    ......

    private final class ApiVisitor extends UElementHandler {

        ......

        private final void report(Issue issue, UElement node, Location location, String type, String sig, int api, int minSdk, LintFix fix, String owner, String name, String desc) {
            report(issue, node, location, ApiDetector.this.getApiErrorMessage(minSdk, node, api, type, sig), fix, owner, name, desc);
        }

        private final void report(Issue issue, UElement node, Location location, String message, LintFix fix, String owner, String name, String desc) {
            this.context.report(issue, node, location, message, fix);
        }
    }

    public final String getApiErrorMessage(int minSdk, UElement node, int requires, String type, String sig) {
        String apiLevel;
        int min = Math.max(minSdk, Companion.getTargetApi$default(Companion, node, (Function1) null, 2, (Object) null));
        if (requires <= 29) {
            apiLevel = String.valueOf(requires);
        } else {
            apiLevel = SdkVersionInfo.getCodeName(requires);
            if (apiLevel == null) {
                apiLevel = String.valueOf(requires);
            }
        }
        return StringHelper.usLocaleCapitalize(type) + " requires API level " + apiLevel + " (current min is " + min + "): `" + sig + '`';
    }
}

刚刚的visitCall调用的是第一个report方法，我们主要看它在调用下面的report方法时，传的第4个参数，它传的是getApiErrorMessage方法的返回值，看到这里大家应该心中有数了，getApiErrorMessage方法返回值的格式，就是题目中那个提示的格式了，拼接的第一个参数type，在上面的visitCall方法里传的是 "Call" ，可以翻回去看看。

在拼接完Error Message之后，会通过Context的report反馈错误。

emmmm，【如何判断】的逻辑是分析完了，但它究竟是怎么获取到目标方法【第一次出现的版本】的呢？难道每次都读取一次xml吗？那样不仅效率低而且也太浪费资源了吧。它到底是怎么做的？

从上面的visitCall方法中可以看到，它是通过ApiDatabase的getMethodVersion方法来获取的，看看里面做了什么：

public class ApiLookup extends ApiDatabase {

    public int getMethodVersion(String owner, String name, String desc) {
        int classNumber;
        if (this.mData == null || (classNumber = findClass(owner)) < 0) {
            return -1;
        }
        int api = findMember(classNumber, name, desc);
        if (api < 0) {
            return -1;
        }
        return api;
    }

    private int findMember(int classNumber, String name, String desc) {
        return findMember(classNumber, name, desc, 2);
    }    

    /* JADX WARNING: Removed duplicated region for block: B:22:0x00a7  */
    /* JADX WARNING: Removed duplicated region for block: B:23:0x00ab  */
    /* Code decompiled incorrectly, please refer to instructions dump. */
    private int findMember(int r23, java.lang.String r24, java.lang.String r25, int r26) {
        /*
            r22 = this;
            r3 = 1
            r0 = r22
            r1 = r23
            int r16 = r0.seekClassData(r1, r3)
            r0 = r22
            byte[] r3 = r0.mData
            r0 = r16
            int r19 = get3ByteInt(r3, r0)
            int r16 = r16 + 3
            r0 = r22
            byte[] r3 = r0.mData
            r0 = r16
            int r18 = get2ByteInt(r3, r0)
            if (r18 != 0) goto L_0x0023
            r3 = -1
        L_0x0022:
            return r3
        */
        throw new UnsupportedOperationException("Method not decompiled: com.android.tools.lint.checks.ApiLookup.findMember(int, java.lang.String, java.lang.String, int):int");
    }
}

最主要的findMember方法居然看不到。。。反编译不了。

那只好把Android Studio的源码下载下来了：

下载Android Studio源码

考虑到网络不畅通的同学，我在半个月前就已经同步好了4.1.0的源码，并上传到了百度云上，哈哈哈哈，因为太大了，国内的代码仓库都放不下，只能打包放网盘上了。

网盘链接: https://pan.baidu.com/s/14O9aD9GJCLTbTHm6KjpUdA 提取码: z96p

网盘上的是完整代码，解压出来15G左右。不过，里面很多平台相关的东西，还有jdk源码部分，对这次源码分析根本没用，所以我又专门把部分基础代码上传到了gitee上，地址：https://gitee.com/wuyr_/android-studio-4.1.0，同步下来之后，用 IntelliJ IDEA Community 直接打开就行。

当然了，如果你想直接从googlesource上同步源码，也是可以的：https://android.googlesource.com/platform/tools/base/+/studio-master-dev/source.md 这里是同步源码的官方教程。

好，打开源码之后，我们来看看刚刚那个ApiLookup的findMember方法，位置就在 /base/lint/libs/lint-checks/src/main/java/com/android/tools/lint/checks 目录下：

public class ApiLookup extends ApiDatabase {

    private int findMember(
            int classNumber, @NonNull String name, @Nullable String desc, int apiLevelField) {
        int curr = seekClassData(classNumber, CLASS_HEADER_MEMBER_OFFSETS);

        // 3 bytes for first offset
        int low = get3ByteInt(mData, curr);
        curr += 3;

        int length = get2ByteInt(mData, curr);
        if (length == 0) {
            return -1;
        }
        int high = low + length;

        while (low < high) {
            int middle = (low + high) >>> 1;
            int offset = mIndices[middle];

            int compare;
            if (desc != null) {
                // Method
                int nameLength = name.length();
                compare = compare(mData, offset, (byte) '(', name, 0, nameLength);
                if (compare == 0) {
                    offset += nameLength;
                    int argsEnd = desc.indexOf(')');
                    // Only compare up to the ) -- after that we have a return value in the
                    // input description, which isn't there in the database.
                    compare = compare(mData, offset, (byte) ')', desc, 0, argsEnd);
                    if (compare == 0) {
                        if (DEBUG_SEARCH) {
                            System.out.println("Found " + dumpEntry(offset));
                        }

                        offset += argsEnd + 1;

                        if (mData[offset++] == 0) {
                            // Yes, terminated argument list: get the API level
                            return getApiLevel(offset, apiLevelField);
                        }
                    }
                }
            } 
            ......

            if (compare < 0) {
                low = middle + 1;
            } else if (compare > 0) {
                high = middle;
            } else {
                assert false; // compare == 0 already handled above
                return -1;
            }
        }

        return -1;
    }
}

可以看出这是一个二分查找，在找到正确的offset之后调用了getApiLevel方法，并把offset传了进去：

public class ApiLookup extends ApiDatabase {

    public static final int HAS_EXTRA_BYTE_FLAG = 1 << 7;
    public static final int API_MASK = ~HAS_EXTRA_BYTE_FLAG;

    private int getApiLevel(int offset, int apiLevelField) {
        int api = Byte.toUnsignedInt(mData[offset]);
        if (apiLevelField == CLASS_HEADER_API) {
            return api & API_MASK;
        }
        ......
    }
}

在这里会直接从mData里面取出对应offset的值，转正数int之后去掉API_MASK标记，然后return。

说明数据都保存在mData里面，看看它是怎么来的：

public class ApiDatabase {

    protected byte[] mData;

    protected void readData(@NonNull LintClient client, @NonNull File binaryFile, @NonNull CacheCreator cacheCreator, int majorBinaryFormatVersion) {
        ......
        byte[] b = Files.toByteArray(binaryFile);
        ......
        mData = b;
        ......
    }    

}

它是ApiDatabase（刚刚的ApiLookup的父类）里的成员变量，在readData方法中初始化。

emmmm，为了提高效率，我们还是借助Debug来分析吧（先给这个readData方法打下断点）。

Debug Android Studio

在开头就已经介绍过，AS其实是IntelliJ IDEA的一个大型插件，所以我们可以用debug IntelliJ IDEA插件的方式来debug AS。

不过，平时debug插件的时候，新的IDEA进程都是在IDEA中启动的，那要怎样才能从IDEA中启动一个可debug的AS呢？

细心的同学会看到过，当IDEA启动debug进程时，在下面的run窗口中会看到这么一串东西：

其实就是启动debug程序的命令，可以看到它也是通过java来启动的，第一行高亮部分，就是开启debug的参数配置，中间还有一堆其他参数，最后面的是入口的类名。我们同样也可以仿照它的做法，给启动AS的命令加上开启debug的参数。

启动AS的命令在哪呢？

在 AS程序目录/bin/studio.sh 脚本文件里（Windows系统的是.bat后缀）。

打开它，拖到最底：

看到了吗，引用的JAVA_BIN指向的是jre/java，也就是AS的启动命令是从JAVA_BIN那里开始的，我们可以在它前面加上 echo ，这样等下运行的时候就会在终端里打印出完整的启动命令了，不过，不建议直接修改这个脚本文件，复制一份出来比较保险，名字就叫debug吧：

加上echo后保存，然后运行这个脚本：

嘿嘿，完整的命令出来了，现在是时候准备debug参数了，回到刚刚IDEA的窗口，在Run Configuration里新增一个 Remote configuration：

好，复制里面那一串参数到刚刚输出的完整命令中：

就放到java的后面，记得前后要有空格隔开。

好啦，按下enter，可debug的Adnroid Studio就启动了~

趁还没启动完成，赶紧回到IDEA窗口中，点那个绿色的小虫子，attach到AS进程。

等待AS初始化完毕，就能看到刚刚在readData方法打的断点已经生效啦：

点开那个cacheCreator，还能看到项目compileSdkVersion对应的那个api-versions.xml的File对象！

翻一下左边的栈帧，发现readData方法是在ApiDetector的beforeCheckRootProject方法里调用的：

也就是说，之前分析的那个ApiVisitor的visitCall方法，它里面使用的ApiDatabase对象（调用getMethodVersion方法获取方法版本）是在这时候初始化的。

看下它初始化的时候都做了些什么：

public class ApiLookup extends ApiDatabase {

    public static final String XML_FILE_PATH = "api-versions.xml"; // relative to the SDK data/ dir

    public static ApiLookup get(@NonNull LintClient client, @Nullable IAndroidTarget target) {
        synchronized (ApiLookup.class) {
            AndroidVersion version = target != null ? target.getVersion() : AndroidVersion.DEFAULT;
            WeakReference<ApiLookup> reference = instances.get(version);
            ApiLookup db = reference != null ? reference.get() : null;
            if (db == null) {
                // Fallbacks: Allow the API database to be read from a custom location
                String env = System.getProperty("LINT_API_DATABASE");
                File file = null;
                if (env != null) {
                    file = new File(env);
                    if (!file.exists()) {
                        file = null;
                    }
                } else {
                    if (target != null && version.getFeatureLevel() >= SDK_DATABASE_MIN_VERSION) {
                        file = new File(target.getFile(IAndroidTarget.DATA), XML_FILE_PATH);
                        if (!file.isFile()) {
                            file = null;
                        }
                    }

                    if (file == null) {
                        target = null; // The API database will no longer be tied to this target
                        file = client.findResource(XML_FILE_PATH);
                    }
                }

                if (file == null) {
                    return null;
                } else {
                    db = get(client, file, target);
                }
                instances.put(version, new WeakReference<>(db));
            }

            return db;
        }
    }    

}

这里有个缓存机制，当然了，第一次进入的时候肯定是null，所以会进入到第一个if里面。

获取到api-versions.xml的File对象之后，会调用另一个get方法：

public class ApiLookup extends ApiDatabase {

    @VisibleForTesting static final boolean DEBUG_FORCE_REGENERATE_BINARY = false;

    private static ApiLookup get(
            @NonNull LintClient client, @NonNull File xmlFile, @Nullable IAndroidTarget target) {

        ......        

        File binaryData = new File(cacheDir, getCacheFileName(xmlFile.getName(), platformVersion));

        if (DEBUG_FORCE_REGENERATE_BINARY) {
            if (!cacheCreator(xmlFile).create(client, binaryData)) {
                return null;
            }
        } else if (!binaryData.exists()
                || binaryData.lastModified() < xmlFile.lastModified()
                || binaryData.length() == 0) {
            if (!cacheCreator(xmlFile).create(client, binaryData)) {
                return null;
            }
        }

        ......

        return new ApiLookup(client, xmlFile, binaryData, target);
    }

}

很明显，第一个if的条件现在写死是false的（看它的注解也能知道是测试时才用的），我们重点看下面的else if，它有三个条件，分别是：

1. binaryData不存在；
2. xmlFile（也就是那个api-versions.xml）的最后修改日期比binaryData要大；
3. binaryData文件为空；

满足其中任何一个条件，就会调用cacheCreator返回对象的create方法：

public class ApiLookup extends ApiDatabase {

    @FunctionalInterface
    interface CacheCreator {
        boolean create(LintClient client, File binaryData);
    }

    private static CacheCreator cacheCreator(File xmlFile) {
        return (client, binaryData) -> {
            long begin = WRITE_STATS ? System.currentTimeMillis() : 0;

            Api<ApiClass> info;

            ......

            info = Api.parseApi(xmlFile);

            ......

            try {
                writeDatabase(binaryData, info, API_LOOKUP_BINARY_FORMAT_VERSION);
                return true;
            } catch (IOException e) {
                client.log(e, "Can't write API cache file");
            }

            return false;
        };
    }
}

这个cacheCreator返回的是接口CacheCreator的对象，可以看到这个接口用了FunctionalInterface修饰，说明它的create方法可以写成lambda形式的，看它的实现，主要做了两件事：

1. 调用parseApi方法获取Api对象；
2. 调用writeDatabase方法并把刚刚获取到的Api对象传了进去；

看下parseApi方法：

class Api<C extends ApiClassBase> {

    public static Api<ApiClass> parseApi(File apiFile) {
        try (InputStream inputStream = new FileInputStream(apiFile)) {
            SAXParserFactory parserFactory = SAXParserFactory.newInstance();
            XmlUtils.configureSaxFactory(parserFactory, false, false);
            SAXParser parser = XmlUtils.createSaxParser(parserFactory);
            ApiParser apiParser = new ApiParser();
            parser.parse(inputStream, apiParser);
            inputStream.close();
            return new Api<>(apiParser.getClasses(), apiParser.getContainers());
        } catch (ParserConfigurationException | SAXException | IOException e) {
            throw new RuntimeException(e);
        }
    }
}

额，好像没什么好说的，就是解析xml（那个api-versions.xml）。

看看writeDatabase方法吧：

。。。。。。。

好长啊，200多行，就不贴出来了，主要逻辑就是把刚刚解析出来的xml数据，写到一个bin文件里（关联索引），感兴趣的同学可以借助debug来充分理解。

好了，回到刚刚的get方法，在写完数据后，最后会new一个ApiLookup对象：

public class ApiLookup extends ApiDatabase {
        private ApiLookup(
                @NonNull LintClient client,
                @NonNull File xmlFile,
                @Nullable File binaryFile,
                @Nullable IAndroidTarget target) {
            this.target = target;

            if (binaryFile != null) {
                readData(client, binaryFile, cacheCreator(xmlFile), API_LOOKUP_BINARY_FORMAT_VERSION);
            }
        }
}

咦？它里面调用了前面分析过的readData方法，这样整个流程就打通了，readData方法里，在读取binaryFile文件后是直接赋值给mData，没有做任何修改的：

public class ApiDatabase {

    protected byte[] mData;

    protected void readData(@NonNull LintClient client, @NonNull File binaryFile, @NonNull CacheCreator cacheCreator, int majorBinaryFormatVersion) {
        ......
        byte[] b = Files.toByteArray(binaryFile);
        ......
        mData = b;
        ......
    }    

}

好啦，剩下的就留给同学们自己去探索啦，你可以尝试：

1. 在ApiLookup.get方法里打断点，手动删除对应路径的bin文件之后，debug看看创建bin文件的整个流程；

2. debug writeDatabase方法，看看bin文件里面的数据是如何存放的；

3. 思考为什么要有这个bin文件？ 像它这种做法，能不能在自己日常开发中用上？

有了Android Studio的源码，其实不止这个Lint检测功能，还有其他比如 自定义控件是如何做到预览的，AS 中我们的 View 的代码执行了？ 这个LayoutEditor的原理，也能通过debug去快速了解了（后面会更新这个问题的回答）。

1.检查 -> Android->Lint->Correctness->Calling new methods on older versions

2.sdk\platforms\android-api\data\api-versions.xml

3.com.android.tools.lint.checks ApiDetector

4.现在我是更改系统源码重新编译出来android.jar，之后将对应的方法标记为removed，但是感觉太麻烦了，又不想用反射，现在陷入了纠结阶段