Google Play 目标 API 等级（targetSdkVersion）重要变更要求

Google Play 目标 API 等级（targetSdkVersion）重要变更要求

Google Play

从 2018 年 8 月 1 日起，所有向 Google Play 首次提交的新应用都必须针对 Android 8.0 (API 等级 26) 开发； 2018 年 11 月 1 日起，所有 Google Play 的现有应用更新同样必须针对 Android 8.0。

现代化您的应用

当您在更新应用目标 API 等级时，请考虑应用平台近期发布的新功能，让您的应用更为现代化并为用户带去更好的体验。

• 请将您的app 从 Google Cloud Messaging (GCM) 迁移至 Firebase Cloud Messaging 最新版本。
• 使用高级窗口管理
  • 支持更大宽屏比率 (大于16:9)，让应用能够利用最新的硬件技术。 确保您的应用调整大小后能填充可用的屏幕空间。万不得已情况下，可以声明最大屏幕宽高比。 更多有关最大屏幕宽高比信息，请阅读声明受限屏幕支持。
  • 添加多窗口支持， 提升应用效率并管理多屏幕适配。
  • 如果最小化应用能够帮助您改善用户体验，您可添加画中画支持。
  • 针对凹口屏幕设备的优化
    • 不要假定状态栏高度，而是使用 WindowInsets 以及 View.OnApplyWindowInsetsListener (观看视频，了解更多)。
    • 不要假定应用是全屏显示的，而是通过调用 View.getLocationInWindow() (注意：不是 View.getLocationOnScreen()) 来确定应用屏幕位置。
    • 在处理 MotionEvent 时，调用 MotionEvent.getX() 和 MotionEvent.getY()；而非 MotionEvent.getRawX() 或 MotionEvent.getRawY()。
• 使用现代摄像头支持
  • 使用 Camera2 API 最大化摄像头利用率。
  • 在 Pixel 2 设备上启用 Pixel Visual Core 加速 HDR+ 处理。

检查并更新您的 SDK 和库

请确保您使用的三方 SDK依赖项支持 API 26：部分 ADK 供应商会在发布说明中写明是否支持；其它供应商则须要进一步调查。如果您使用的 SDK 不支持 API 26，请尽快与 SDK 供应商合作解决该问题。

此外，请注意您的应用或者游戏中的 targetSdkVersion 可能会限制访问私有 Android 平台库，请移步将 NDK 应用链接至平台库页面获取进一步信息。

您还须要验证您正在使用的 Android 支持库可能存在的任何限制。和以往一样，您必须确保应用中的 compileSdkVersion 与 Android 支持库主要版本能够顺利兼容。

我们推荐您选择体积小于或等于支持库主要版本的 targetSdkVersion ，并建议您升级到近期发布的兼容支持库，从而能够使用到最新版本的兼容性特性和错误修正功能。

测试您的应用

在更新完应用的 API 等级和功能后，您须要测试一些核心用例。下文列举的几条建议并没有涵盖所有情况，但希望能给您提供指导作用。我们建议进行以下几个方面的测试：

• 测试应用兼容 API 26， 不产生错误和警告。
• 您的应用应该有相应策略来妥善应对用户拒绝访问权限的情况，并提示用户授予权限。为了达到该效果，您须要：
  • 前往应用的信息页面，然后禁用每个权限。
  • 开启应用，确保没有崩溃。
  • 进行核心用例测试，并确保已预先提示了所有权限请求。。
• 妥善应对 Doze 模式，达到预期效果且不导致错误
  • 在应用运行时，使用 abd 让您的测试设备进入 Doze 模式。
    • 测试任何触发 Firebase Cloud Messaging 消息的用例。
    • 测试任何需要使用闹钟或者任务用例。
    • 消除所有后台服务依赖。
  • 设置您的应用进入待机模式（App Standby）
    • 测试任何触发 Firebase Cloud Messaging 消息的用例。
    • 测试任何需要使用闹钟的用例。
• 处理新拍摄的照片以及视频
  • 检查您的应用是否妥善处理 ACTION_NEW_PICTURE 以及 ACTION_NEW_VIDEO 广播限制 (即移动至 JobScheduler 任务)。
  • 确保任何依赖此类事件的重要用例都能顺利运行。
• 应用间分享文件
  • 请测试所有涉及到应用间分享文件数据的案例 (即使是同一开发者开发的应用)。
  • 请测试其它应用是否能够成功显示内容，而且不引发崩溃。

NDK 应用链接至平台库

从 Android 7.0 开始，系统将阻止应用动态链接非公开 NDK 库，这种库可能会导致您的应用崩溃。此行为变更旨在为跨平台更新和不同设备提供统一的应用体验。即使您的代码可能不会链接私有库，但您的应用中的第三方静态库可能会这么做。因此，所有开发者都应进行相应检查，确保他们的应用不会在运行 Android 7.0 的设备上崩溃。如果您的应用使用原生代码，则只能使用公开 NDK API。

您的应用可通过以下三种方式尝试访问私有平台 API：

• 您的应用直接访问私有平台库。您应更新您的应用以添加该应用的库副本，或使用公开 NDK API。
• 您的应用使用一个可访问私有平台库的第三方库。即使您确定您的应用不会直接访问私有库，您仍应针对此情景测试您的应用。
• 您的应用引用一个其 APK 中未包含的库。例如，如果您尝试使用您自己的 OpenSSL 副本，但忘记将它与应用的 APK 进行捆绑，则可能会出现此情况。正常情况下，此应用可在包含 libcrypto.so 的 Android 平台版本上运行。不过，此应用在不包含此库的新版 Android（例如，Android 6.0 和更高的版本）上会崩溃。为修复此问题，请确保您的 APK 捆绑您的所有非 NDK 库。

应用不应使用 NDK 中未包含的原生库，因为这些库可能会发生更改或在不同 Android 版本之间的可用性不同。例如，从 OpenSSL 切换至 BoringSSL 即属于此类更改。此外，由于不属于 NDK 中的平台库没有兼容性要求，因此不同的设备可能提供不同级别的兼容性。

为降低此限制可能对当前发布的应用的影响，面向 API 级别 23 或更低级别的应用在 Android N 上可暂时访问颇为常用的一组库，例如 libandroid_runtime.so、libcutils.so、libcrypto.so 和 libssl.so。如果您的应用加载其中某个库，logcat 会生成一个警告，并在目标设备上显示一个 Toast 来通知您。如果您看到这些警告，您应更新您的应用以添加该应用自己的库副本，或仅使用公开 NDK API。将来发布的 Android 平台可能会完全限制对私有库的使用，并导致您的应用崩溃。

所有应用在调用既非公开又不可暂时访问的 API 时都会生成一个运行时错误。结果就是 System.loadLibrary 和 dlopen(3) 同时返回 NULL，并可能导致您的应用崩溃。您应检查应用代码以移除对私有平台 API 的使用，并使用预览版设备或模拟器全面测试应用。如果您不确定您的应用是否使用私有库，您可以检查 logcat 以识别运行时错误。

下表描述的是根据应用使用的私有原生库及其目标 API 级别 (android:targetSdkVersion)，应用预期显示的行为。

检查您的应用是否使用私有库

为帮助您识别加载私有库的问题，logcat 可能会生成一个警告或运行时错误。例如，如果您的应用面向 API 级别 23 或更低级别，并在运行 Android 7.0 的设备上尝试访问私有库，您可能会看到一个类似于下面所示的警告：

03-21 17:07:51.502 31234 31234 W linker  : library "libandroid_runtime.so"
("/system/lib/libandroid_runtime.so") needed or dlopened by
"/data/app/com.popular-app.android-2/lib/arm/libapplib.so" is not accessible
for the namespace "classloader-namespace" - the access is temporarily granted
as a workaround for http://b/26394120

这些 logcat 警告通知您哪个库正在尝试访问私有平台 API，但不会导致您的应用崩溃。但是，如果应用面向 API 级别 24 或更高级别，logcat 会生成以下运行时错误，您的应用可能会崩溃：

java.lang.UnsatisfiedLinkError: dlopen failed: library "libcutils.so"
("/system/lib/libcutils.so") needed or dlopened by
"/system/lib/libnativeloader.so" is not accessible for the namespace
"classloader-namespace"
  at java.lang.Runtime.loadLibrary0(Runtime.java:977)
  at java.lang.System.loadLibrary(System.java:1602)

如果您的应用使用动态链接到私有平台 API 的第三方库，您可能也会看到上述 logcat 输出。利用 Android 7.0DK 中的 readelf 工具，您可以通过运行以下命令生成给定 .so 文件的所有动态链接的共享库列表：

aarch64-linux-android-readelf -dW libMyLibrary.so

更新您的应用

通过下面的一些步骤，您可以修复上述类型的错误并确保您的应用不会在将来的更新版平台上崩溃：

• 如果您的应用使用私有平台库，您应更新它，以添加该应用自己的库副本或使用公开 NDK API。
• 如果您的应用使用访问私有符号的第三方库，则联系库作者以更新库。
• 请确保将您的所有非 NDK 库与您的 APK 打包在一起。
• 使用标准 JNI 函数而非来自 libandroid_runtime.so 的 getJavaVM 和 getJNIEnv：

AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h>
AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or
JavaVM::AttachCurrentThread from <jni.h>.

• 使用 __system_property_get 而非来自 libcutils.so 的私有 property_get 符号。为此，请使用 __system_property_get 及以下 include 函数：

#include <sys/system_properties.h>

注：系统属性的可用性和内容未通过 CTS 进行测试。应执行进一步修复以避免同时使用这些属性。

使用来自 libcrypto.so 的 SSL_ctrl 符号的本地版本。例如，您应在您的 .so 文件中静态链接 libcyrpto.a，或从 BoringSSL/OpenSSL 添加一个动态链接的 libcrypto.so 版本，并将其打包到您的 APK 中。

行为变更：以 API 级别 28+ 为目标的应用

Android 9（API 级别 28）向 Android 系统引入了多项变更。 以下行为变更仅影响以 API 28 或更高级别为目标的应用。 将 targetSdkVersion 设为 API 28 或更高级别的应用必须进行修改，以便正确支持这些行为（如果适用）。

如需了解影响在 Android 9 上运行的所有应用的变更，则无论这些应用以哪个 API 级别为目标，都请参阅行为变更：所有应用。

前台服务

针对 Android 9 或更高版本并使用前台服务的应用必须请求 FOREGROUND_SERVICE 权限。 这是普通权限，因此，系统会自动为请求权限的应用授予此权限。

如果针对 Android 9 或更高版本的应用尝试创建一个前台服务且未请求 FOREGROUND_SERVICE，则系统会引发 SecurityException。

隐私权变更

如果您的应用以 Android 9 为目标平台，您应牢记以下行为变更。 对设备序列信息和 DNS 信息进行的这些更新可增强用户隐私保护。

构建序列号弃用
在 Android 9 中，Build.SERIAL 始终设置为 “UNKNOWN” 以保护用户的隐私。

如果您的应用需要访问设备的硬件序列号，您应改为请求 READ_PHONE_STATE 权限，然后调用 getSerial()。

DNS 隐私
以 Android 9 为目标平台的应用应采用私有 DNS API。 具体而言，当系统解析程序正在执行 DNS-over-TLS 时，应用应确保任何内置 DNS 客户端均使用加密的 DNS 查找与系统相同的主机名，或停用它而改用系统解析程序。

框架安全性变更

Android 9 包含可提升您的应用安全性的多个行为变更，但这些变更仅在您的应用以 API 级别 28 或更高级别为目标平台时才会生效：

默认情况下启用网络传输层安全协议 (TLS)
如果您的应用以 Android 9 或更高版本为目标平台，则默认情况下 isCleartextTrafficPermitted() 函数返回 false。 如果您的应用需要为特定域名启用明文，您必须在应用的网络安全性配置中针对这些域名将 cleartextTrafficPermitted 显式设置为 true。

按进程分设基于网络的数据目录
为改善 Android 9 中的应用稳定性和数据完整性，应用无法再让多个进程共用同一 WebView 数据目录。 此类数据目录一般存储 Cookie、HTTP 缓存以及其他与网络浏览有关的持久性和临时性存储。

在大多数情况下，您的应用只应在一个进程中使用 android.webkit 软件包中的类，例如 WebView 和 CookieManager。 例如，您应该将所有使用 WebView 的 Activity 对象移入同一进程。 您可以通过在应用的其他进程中调用 disableWebView()，更严格地执行“仅限一个进程”规则。 该调用可防止 WebView 在这些其他进程中被错误地初始化，即使是从依赖内容库进行的调用也能防止。

如果您的应用必须在多个进程中使用 WebView 的实例，则必须先利用 WebView.setDataDirectorySuffix() 函数为每个进程指定唯一的数据目录后缀，然后再在该进程中使用 WebView 的给定实例。 该函数会将每个进程的网络数据放入其在应用数据目录内自己的目录中。

注：即使您使用 setDataDirectorySuffix()，系统也不会跨应用的进程界限共享 Cookie 以及其他网络数据。 如果应用中的多个进程需要访问同一网络数据，您需要自行在这些进程之间复制数据。 例如，您可以调用 getCookie() 和 setCookie()，在不同进程之间手动传输 Cookie 数据。

以应用为单位的 SELinux 域名
以 Android 9 或更高版本为目标平台的应用无法利用可全球访问的 Unix 权限与其他应用共享数据。 此变更可改善 Android 应用沙盒的完整性， 具体地讲，就是要求应用的私有数据只能由该应用访问。

要与其他应用共享文件，请使用 content provider。

连接变更

连接数据计数和多路径
在以 Android 9 或更高版本为目标平台的应用中，系统计算并非当前默认网络的网络流量，例如，当设备连接 WLAN 时的蜂窝流量，并在 NetworkStatsManager 类中提供函数以查询该流量。

具体而言，getMultipathPreference() 现在将返回一个基于上述网络流量的值。 从 Android 9 开始，此函数针对蜂窝数据返回 true，但当超过一天内累积的特定流量时，它将开始返回 false。 在 Android 9 上运行的应用必须调用此函数并采用此提示。

ConnectivityManager.NetworkCallback 类现在将有关 VPN 的信息发送到应用。 此变更让应用侦听连接事件变得更容易，而无需混用同步和异步调用，也无需使用有限的 API。 此外，它还意味着将设备同时连接至多个 WLAN 网络或多个蜂窝网络时，信息传输可按预期工作。

Apache HTTP 客户端弃用
在 Android 6.0 中，我们取消了对 Apache HTTP 客户端的支持。 从 Android 9 开始，默认情况下该内容库已从 bootclasspath 中移除且不可用于应用。

要继续使用 Apache HTTP 客户端，以 Android 9 及更高版本为目标的应用可以向其 AndroidManifest.xml 添加以下内容：

注：拥有最低 SDK 版本 23 或更低版本的应用需要 android:required="false" 属性，因为在 API 级别低于 24 的设备上，org.apache.http.legacy 库不可用。 （在这些设备上，Apache HTTP 类在 bootclasspath 中提供。）

作为使用运行时 Apache 库的替代，应用可以在其 APK 中绑定自己的 org.apache.http 库版本。 如果进行此操作，您必须将该库重新打包（使用一个类似 Jar Jar 的实用程序）以避免运行时中提供的类存在类兼容性问题。

界面变更

视图焦点
0 面积的视图（即宽度或高度为 0）再也不能被聚焦。

此外，Activity 不再隐式分配触摸模式下的初始焦点。 而是由您显式请求初始焦点（如若需要的话）。

CSS RGBA 十六进制值处理
以 Android 9 或更高版本为目标的应用必须支持草案版 CSS 颜色模块级别 4 的行为，用于处理 4 和 8 个十六进制数字 CSS 颜色。

Chrome 自版本 52 以来便一直支持 CSS 颜色模块级别 4，但 WebView 目前停用此功能，因为现有 Android 应用被发现包含 Android ordering (ARGB) 中的 32 位十六进制颜色，这会导致渲染错误。

例如，对于以 API 级别 27 或更低版本为目标平台的应用，颜色 #80ff8080 目前在 WebView 中被渲染为不透明浅红色 (#ff8080)。 先导部分（Android 会将其解读为 Alpha 部分）目前被忽略。 如果某个应用以 API 级别 28 或更高版本为目标，则 #80ff8080 将被解读为 50% 透明浅绿 (#80ff80)。

文档滚动标签
Android 9 可正确处理文档的根标签是滚动标签的案例。 在之前的版本中，滚动位置在 body 标签上设置，根标签的滚动值为零。 Android 9 支持符合标准的行为，在这种行为中，滚动标签是根标签。

此外，直接访问 document.body.scrollTop、document.body.scrollLeft、document.documentElement.scrollTop 或 document.documentElement.scrollLeft 会因目标 SDK 的不同而具有不同的行为。 要访问视口滚动值，请使用 document.scrollingElement（若有）。

来自已暂停应用的通知
在 Android 9 之前，暂停的应用发出的通知会被取消。 从 Android 9 开始，暂停的应用发出的通知将被隐藏，直至应用继续运行。

对非 SDK 接口的限制

Android 9（API 级别 28）引入了针对非 SDK 接口的使用限制，无论是直接使用还是通过反射或 JNI 间接使用。 无论应用是引用非 SDK 接口还是尝试使用反射或 JNI 获取其句柄，均适用这些限制。 有关此决定的详细信息，请参阅通过减少使用非 SDK 接口提升稳定性。

一般来说，应用应当仅使用 SDK 中正式记录的类。 特别是，这意味着，在您通过反射之类的语义来操作某个类时，不应打算访问 SDK 中未列出的函数或字段。

使用此类函数或字段很可能会破坏您的应用。

区分 SDK 接口和非 SDK 接口

一般来说，SDK 接口是指在 Android 框架软件包索引中记录的接口。 对非 SDK 接口的处理是 API 抽象化的实现细节；其会随时更改，恕不另行通知。

Android 9 引入了针对非 SDK 接口的使用限制，无论是直接使用还是通过反射或 JNI 间接使用。 无论应用是引用非 SDK 接口还是尝试使用反射或 JNI 获取其句柄，均适用这些限制。

测试非 SDK 接口

您可以通过下载 Android 9 对您的应用进行测试。系统将打印日志，如果您的应用访问某些“列入灰名单的”非 SDK 接口，系统还可能显示 toast。 如果您的应用调用“列入黑名单的”非 SDK 接口，系统将引发错误。

注意 toast，它会提醒您注意被建议禁用的接口。 此外，确保检查应用的日志消息，其中包含关于应用所访问的非 SDK 接口的更多详细信息，包括以 Android 运行时所使用的格式列出的声明类、名称和类型。 日志消息还说明了访问方法：直接、通过反射或者通过 JNI。 最后，日志消息显示调用的非 SDK 接口属于灰名单还是黑名单。

您可以使用 adb logcat 访问这些日志消息，消息将显示在正在运行的应用的 PID 下。 例如，日志中的条目看上去可能类似下面这样：

Accessing hidden field Landroid/os/Message;->flags:I (light greylist, JNI)

列入灰名单的非 SDK 接口包含可以在 Android 9 中继续工作，但我们不能保证在未来版本的平台中能够继续访问的函数和字段。 如果由于某种原因，您不能实现列入灰名单的 API 的替代策略，则可以提交错误，以便请求重新考虑此限制。

某些 API 位于“黑名单”中，比列入灰名单的函数更为严格。 列入黑名单的函数会使应用引发如保留非 SDK 接口的结果部分的表中所列的异常。

Android 9 支持非 SDK 接口的 StrictMode（称为 detectNonSdkApiUsage），因此当您的应用调用列入灰名单的应用时，堆叠追踪将显示上下文。

保留非 SDK 接口的结果

下表详细说明了各种访问方式及其相应的结果。

常见问题解答

什么是非 SDK 接口？

它们是不属于官方 Android SDK 的 Java 字段和函数。 它们属于实现详情，如有更改，恕不另行通知。

Android 9 中有什么变化？

我们打算设定对使用非 SDK 接口的限制。 这些限制的形式各不相同（请参阅如何在应用运行时检测非 SDK 接口使用？），但是如果您使用非 SDK 接口，它们的形式可能影响您的应用的行为。

如果我当前使用非 SDK 接口，我应当在哪请求？

请提交功能请求，并提供您的用例的详细信息。

用于限制非 SDK 接口的不同名单有哪些，它们在限制性行为方面的对应含义是什么？

下面是名单类型：

• 白名单：SDK
• 浅灰名单：仍可以访问的非 SDK 函数/字段。
• 深灰名单：
  • 对于目标 SDK 低于 API 级别 28 的应用，允许使用深灰名单接口。
  • 对于目标 SDK 为 API 28 或更高级别的应用：行为与黑名单相同
• 黑名单：受限，无论目标 SDK 如何。 平台将表现为似乎接口并不存在。 例如，无论应用何时尝试使用接口，平台都会引发 NoSuchMethodError/NoSuchFieldException，即使应用想要了解某个特殊类别的字段/函数名单，平台也不会包含接口。

我的应用使用了许多第三方库，这让我很难查找任何正在使用的不公开 API。 有没有编译时工具可以帮助我跟踪违规？

您可以尝试 AOSP 中提供的静态分析工具 veridex。

如何在应用运行时检测非 SDK 接口使用？

将打印一条 Accessing hidden field|method … 形式的 logcat 警告。 此外，将为可调试应用显示 toast 消息，并为遭到拒绝的任何非 SDK 接口打印 logcat 消息。

Google 如何确保通过 Issue Tracker 捕获所有应用的需求？

我们最初通过对应用进行静态分析确定了种子名单，并辅以下列措施：

• 对热门 Play 和非 Play 应用进行手动测试
• 内部报告
• 自动从内部用户收集数据
• 开发者预览版报告
• 其他旨在谨慎地包含更多误报的静态分析

如何启用对非 SDK API 的访问？

可以使用 adb 在开发设备上启用对非 SDK API 的访问。

如果您想要在 adb logcat 输出中查看 API 访问信息，则可以更改 API 强制政策：

  adb shell settings put global hidden_api_policy_pre_p_apps  1
  adb shell settings put global hidden_api_policy_p_apps 1

要将其重置为默认设置，请执行以下操作：

  adb shell settings delete global hidden_api_policy_pre_p_apps
  adb shell settings delete global hidden_api_policy_p_apps

这些命令不要求已取得 root 权限的设备。

给定整数的含义如下所示：

• 0：停用非 SDK API 使用检测。 这还会停用日志记录，并且也会破坏严格模式 API detectNonSdkApiUsage()。 不建议使用此值。
• 1：“只是警告”- 允许访问所有非 SDK API，但会在日志中保留警告。 严格模式 API 将继续工作。
• 2：不允许使用列入深灰名单和黑名单的 API。
• 3：不允许使用列入黑名单的 API，但允许使用列入深灰名单的 API。

关于 API 名单

Android 9 版本构建中的深灰名单包含什么？

深灰名单包含我们在开发期间未看到使用，但是我们可能已经忽视的函数/字段。 列入深灰名单的函数/字段是那些与 SDK 和浅灰名单中的公开接口紧密相关的函数/字段。

灰名单/黑名单位于什么地方？

它们作为平台的一部分构建。 您可以在此处找到预构建条目：

• platform/prebuilts/runtime/appcompat/hiddenapi-light-greylist.txt：浅灰 API 的 AOSP 名单
• platform/prebuilts/runtime/appcompat/hiddenapi-dark-greylist.txt：深灰 API 的 AOSP 名单
  此外，此名单还包含浅灰 API 的 SDK 28 名单。

黑名单和深灰名单在构建时衍生而来。 我们已添加了一个可以在 AOSP 上生成名单的构建规则。 它与 P 中的黑名单不同，但是重叠比较合理。 开发者可以下载 AOSP，然后使用以下命令生成黑名单：

  make hiddenapi-aosp-blacklist

然后，可以在以下位置找到文件：

  out/target/common/obj/PACKAGING/hiddenapi-aosp-blacklist.txt

这些名单的适当大小是多少？

名单大小的近似值如下所示：

• 白名单（也称为 SDK）~= 74,000 个函数和字段
• 浅灰名单 ~= 11,000 个函数和字段
• 深灰名单 ~= 121,000 个函数和字段
• 黑名单 ~= 9,000 个函数和字段

我可以在系统镜像中的什么地方找到黑名单/灰名单？

它们编码在平台 dex 文件的字段和函数访问标志位中。 系统镜像中没有单独的文件包含这些名单。

黑名单/灰名单在采用相同 Android 版本的原始设备制造商设备上是否相同？

相同，原始设备制造商可以向黑名单中添加自己的 API，但无法从原始的/AOSP 黑名单或灰名单中移除条目。 CDD 可以防止此类变化，CTS (Compatibility Test Suite) 测试可以确保 Android 运行时强制执行名单。

相关的应用兼容性问题

原生代码中对非 NDK 接口是否有任何限制？

SDK 涵盖 Java 语言。 对于原生 C/C++ 代码的 NDK，我们在 Android Nougat 中完成了此操作。 请参阅： 在 Android N 中使用不公开 C/C++ 符号限制提升稳定性

你们有没有任何限制 dex2oat 或 dex 文件操作的计划？

我们没有限制访问 dex2oat 二进制文件的有效计划，但是我们不准备让 dex 文件格式保持稳定，或让公开接口超越在 Dalvik 可执行文件格式中公开指定的部分。 我们保留随时修改或消除 dex2oat 以及 dex 格式未指定部分的权利。 另请注意，dex2oat 生成的衍生文件（例如，odex（也称为 oat）、vdex 和 cdex）全都是未指定格式。

如果某个关键的 3p SDK（尤其是代码混淆工具）无法阻止使用非 SDK 接口，但却承诺保持与未来的 Android 版本兼容，该怎么办？Android 会放弃警告吗？

我们没有按 SDK 放弃兼容性要求的计划。 如果 SDK 合作伙伴感到他们无法保持与当前的白名单和灰名单 API 集兼容，他们应当提交错误请求，请求他们需要的非 SDK 函数。

注：对于 Android 9，我们没有计划限制目前正由任何 Android 应用或 SDK 使用的任何非 SDK 接口，但在将来，当我们认为存在适用的 SDK 替代者时，我们会计划开始施加目标 SDK 限制。 请注意，由于使用非 SDK 和非 NDK 接口，并且必须适应，每年其中的许多 SDK 都会遭到破坏。

非 SDK 接口限制适用于包括系统和第三方应用在内的所有应用，还是仅适用于第三方应用？

适用于所有应用，但是我们会豁免使用平台密钥签署的应用，并且我们也有一个针对系统镜像应用的软件包白名单。 请注意，这些豁免仅适用于系统镜像中的应用（或更新的系统镜像应用）。 名单仅用于针对不公开平台 API 而不是 SDK API（即， LOCAL_PRIVATE_PLATFORM_APIS := true）构建的应用。

一些开发者已经发布不公开 API 限制机制和绕过技术。 你们对此作何评论？你们会让限制更加严格吗？

我们已注意到潜在的解决方法。 令人欣喜的是，大多数应用仍在坚持使用公开 API。 在尝试让调用非 SDK 接口变得更困难以确保兼容性的同时，我们也会在这种做法与保持运行时易于调试之间作出平衡。 我们将继续评估底层实现并与开发者合作。