Android 7.0 除了提供诸多新特质和功能外文爱，还对系统和 API 行动作念出了各式变更。本文重心先容您应该了解并在开发应用时加以有计划的一些主要变更。
若是您之前发布过 Android 应用，请提防您的应用可能会受到这些平台变化的影响。
电板和内存Android 7.0 包括旨在延长斥地电板续航本事和减少 RAM 使用的系统行动变更。这些变更可能会影响您的应用打听系统资源，以及您的应用通过特定隐式 intent 与其他应用交互的口头。
低电耗模式Android 6.0（API 级别 23）引入了低电耗模式，当用户斥地未插接电源、处于静止景色且屏幕关闭时，该模式会推迟 CPU 和网罗步履，从而延长电板寿命。Android 7.0 则通过在斥地未插接电源且屏幕关闭景色下、但不一定要处于静止景色（举例用户出门时把手合手式斥地装在口袋里）时应用部分 CPU 和网罗欺压，进一步增强了低电耗模式。
图 1. 低电耗模式怎样应用第一级系统步履欺压以延长电板寿命的图示。
当斥地处于充电景色且屏幕已关闭一定本事后，斥地会干与低电耗模式并应用第一部分欺压：关闭应用网罗打听、推迟功课和同步。若是斥地在干与低电耗模式后处于静止景色达到一定本事，系统会对 PowerManager.WakeLock、AlarmManager 闹钟、GPS 和 WLAN 扫描应用其余的低电耗模式欺压。不管是应用部分或全部低电耗模式欺压，系统都会叫醒斥地以提供不详的顾惜窗口。在此本事，应用不错打听网罗并践诺任何延长的功课/同步。
图 2. 低电耗模式如安在斥地处于静止景色达到一定本事后应用第二级系统步履欺压的图示。
请提防，激活屏幕或插接斥地电源时，系统将退出低电耗模式并移除这些处理欺压。此项新增的行动不会影响关系使您的应用适合 Android 6.0（API 级别 23）中所推出的旧版块低电耗模式的提议和最好本质，如 对低电耗模式和应用待机模式进行针对性优化中所盘考。您仍应解雇这些提议（举例使用 Firebase Cloud Messaging (FCM) 发送和摄取音书），同期起原计算更新以适合特殊的低电耗模式行动。
Project Svelte：后台优化Android 7.0 移除了三项隐式播送，以匡助优化内存使用和电量耗尽。此项变更很有必要，因为隐式播送会在后台时常启动已注册侦听这些播送的应用。删除这些播送不错显耀提高斥地性能和用户体验。
迁移斥地会资格时常的连合变更，举例在 WLAN 和迁移数据之间切换时。面前，不错通过在应用清单中注册一个摄取器来侦听隐式 CONNECTIVITY_ACTION 播送，让应用大概监控这些变更。由于好多应用都会注册摄取此播送，因此单次网罗切换可能会导致统统应用被叫醒并同期处理此播送。
一样，在之前的 Android 版块中，应用不错注册摄取来自其他应用（如相机）的隐式 ACTION_NEW_PICTURE 和 ACTION_NEW_VIDEO 播送。当用户使用相机应用拍摄照有顷，这些应用即会被叫醒以处理播送。
为缓解这些问题，Android 7.0 应用了以下优化次第：
若是以 Android 7.0（API 级别 24）及更高版块为主义平台的应用在清单中声明其播送摄取器，则这些应用不会收到 CONNECTIVITY_ACTION 播送。若是应用使用 Context.registerReceiver() 注册 BroadcastReceiver 且该 context 仍有用，则它们仍会收到 CONNECTIVITY_ACTION 播送。 系统不再发送 ACTION_NEW_PICTURE 或 ACTION_NEW_VIDEO 播送。此项优化会影响统统应用，而不单是是面向 Android 7.0 的应用。若是您的应用使用了其中任何 intent，您应尽快移除对它们的依赖关系，以便正确以 Android 7.0 斥地为主义平台。 Android 框架提供了多种贬责有计算来缓解对这些隐式播送的需求。举例，JobScheduler API 提供了一个谨慎可靠的机制来安排餍足指定条目（举例连入无尽流量网罗）时所践诺的网罗操作。您以致不错使用 JobScheduler 来反应付 content provider 的蜕变。
如需瞩目了解 Android 7.0（API 级别 24）中的后台优化以及怎样颐养您的应用，请参阅后台优化。
权限蜕变Android 7.0 作念了一些权限蜕变，这些蜕变可能会影响您的应用。
系统权限蜕变为了提高独到文献的安全性，以 Android 7.0 或更高版块为主义平台的应用对独到目次的打听权限受到欺压 (0700)。此缔造可谨防独到文献的元数据线路，举例其大小或是否存在。此权限蜕变具有多种反作用：
独到文献的文献权限不应再由统统者放宽，为使用 MODE_WORLD_READABLE 和/或 MODE_WORLD_WRITEABLE 而进行的此类尝试将触发 SecurityException。提防：迄今为止，这种欺压尚不成十足践诺。 应用仍可能使用原生 API 或 File API 来修改它们的独到目次权限。然而，咱们强横反对放宽独到目次的权限。
传递软件包网域外的 file:// URI 可能会导致摄取器出现无法打听的旅途。因此，尝试传递 file:// URI 会触发 FileUriExposedException。分享独到文献本色的保举方法是使用 FileProvider。 DownloadManager 不再按文献名分享私东说念主存储的文献。旧版应用在打听 COLUMN_LOCAL_FILENAME 时可能出现无法打听的旅途。以 Android 7.0 或更高版块为主义平台的应用在尝试打听 COLUMN_LOCAL_FILENAME 时会触发 SecurityException。通过使用 DownloadManager.Request.setDestinationInExternalFilesDir() 或 DownloadManager.Request.setDestinationInExternalPublicDir() 将下载位置缔造为各人位置的旧版应用仍不错打听 COLUMN_LOCAL_FILENAME 中的旅途，然而咱们强横反对使用这种方法。打听由 DownloadManager 公开的文献的首选口头是使用 ContentResolver.openFileDescriptor()。 在应用间分享文献关于面向 Android 7.0 的应用，Android 框架践诺的 StrictMode API 计谋不容在您的应用外部公开 file:// URI。若是一项包含文献 URI 的 intent 离开您的应用，则应用会失败并出现 FileUriExposedException 相配。
如需在应用间分享文献，您应发送 content:// URI，并授予 URI 临时打听权限。授予此权限的最肤浅方法是使用 FileProvider 类。如需瞩目了解权限和分享文献，请参阅分享文献。
无繁重功能雠校Android 7.0 包含一些蜕变，旨在提高平台关于弱视或受损用户的易用性。这些蜕变一般并不要求蜕变您的应用代码，不外您应仔细查验并使用您的应用测试这些功能，以评估它们对用户体验的潜在影响。
屏幕缩放Android 7.0 允许用户缔造清醒大小，以放大或削弱屏幕上的统统元素，从而改善弱视用户的斥地无繁重功能。用户无法将屏幕缩放至低于最小屏幕宽度 sw320dp，该宽度是 Nexus 4 的宽度，亦然惯例中等大小手机的宽度。
图 3. 右侧屏幕清醒的是一台运行 Android 7.0 系统映像的斥地增大清醒尺寸后的恶果。
当斥地密度发生蜕变时，系统会以如下口头陈述正在运行的应用：
若是是面向 API 级别 23 或更低版块系统的应用，系统会自动阻隔其统统后台进度。这意味着，若是用户切换离开此类应用，转而掀开缔造屏幕并蜕变清醒大小缔造，则系统会像处理内存不及的情况一样阻隔该应用。若是应用具有任何前台进度，则系统会如处理运行时蜕变中所述将建立蜕变陈述给这些进度，就像斥地的屏幕标的发生变化一样。 若是应用以 Android 7.0 为主义平台，则其统统进度（前台和后台）都会收到关系建立变更的陈述，如处理运行时蜕变中所述。大多量应用并不需要进行任何蜕变即可补助此功能，不外前提是这些应用解雇 Android 最好本质。具体要查验的事项：
在屏幕宽度为 sw320dp 的斥地上测试您的应用，并确保其充分运行。 当斥地建立发生变更时，更新任何与密度联系的缓存信息，举例缓存位图或从网罗加载的资源。当应用从暂停景色规复运行时，查验建立变更。提防：若是您要缓存与建立联系的数据，则最好也包括联系元数据，举例该数据对应的屏幕尺寸或像素密度。保存这些元数据便于您在建立变更后决定是否需要刷新缓存数据。
幸免用像素单元指定尺寸，因为像素不会随屏幕密度缩放。应改为使用与密度无关像素 (dp) 单元指定尺寸。 缔造向导中的视觉缔造Android 7.0 在“接待”屏幕上包含“视觉缔造”，用户不错在新斥地上缔造以下无繁重缔造：放大手势、字体大小、清醒大小和 TalkBack。此项变更让您不错更容易发现与不同屏幕缔造关系的很是。如需评估此功能的影响，您应在启用这些缔造的景色下测试应用。您不错在缔造 > 无繁重下找到这些缔造。
在线爱 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 7.0（API 级别 24）上可暂时打听颇为常用的一组库，举例 libandroid_runtime.so、libcutils.so、libcrypto.so 和 libssl.so。若是您的应用加载其中某个库，logcat 会生成一个告诫，并在主义斥地上清醒一个 Toast 来陈述您。若是您看到这些告诫，您应更新您的应用以添加该应用我方的库副本，或仅使用公开 NDK API。将来发布的 Android 平台可能会十足欺压对独到库的使用，并导致您的应用崩溃。
统统应用在调用既不公开也无法暂时打听的 API 时都会生成运行时很是。驱散即是 System.loadLibrary 和 dlopen(3) 都复返 NULL，何况可能会导致您的应用崩溃。您应查验应用代码以移除对独到平台 API 的使用，并使用搭载 Android 7.0（API 级别 24）的斥地或模拟器全面测试应用。若是您不确定您的应用是否使用独到库，您不错查验 logcat 以识别运行时很是。
下表描绘的是根据应用使用的独到原生库偏执主义 API 级别 (android:targetSdkVersion)，应用预期清醒的行动。
库 主义 API 级别 通过动态连络器进走运行时打听 Android 7.0（API 级别 24）行动 将来的 Android 平台行动 公开 NDK 任何 无繁重 运行平淡 运行平淡 独到（暂时可打听的独到库） 23 或更低 暂时可打听 符合预期，但您会收到一个 logcat 告诫。 运行时很是 独到（暂时可打听的独到库） 24 或更高 受限 运行时很是 运行时很是 独到（其他） 不限 受限 运行时很是 运行时很是 查验您的应用是否使用独到库为匡助您识别加载独到库的问题，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
这些 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 中。 Android for WorkAndroid 7.0 包含针对以 Android for Work 为主义平台的应用所作念的蜕变，包括对文凭安设、密码重置、次要用户经管和斥地绚丽符打听权限的蜕变。若是您是要针对 Android for Work 环境开发应用，则应仔细查验这些变更并相应地修改您的应用。
您必须先安设交付文凭安设表率，然后 DPC 智商对其进行缔造。关于面向 Android 7.0（API 级别 24）的建立文献和斥地统统者应用，您应在斥地计谋欺压器 (DPC) 调用 DevicePolicyManager.setCertInstallerPackage() 之前安设授权文凭安设表率。若是尚未安设该安设表率，系统会抛出 IllegalArgumentException。 针对斥地经管员的重置密码欺压面前也适用于个东说念主贵府统统者。斥地经管员无法再使用 DevicePolicyManager.resetPassword() 来废除或蜕变仍是缔造的密码。斥地经管员仍然不错缔造密码，但只可在斥地莫得密码、PIN 码或图案时这样作念。 即使缔造了欺压，斥地统统者和建立文献统统者仍不错经管账号。而且，即使具有 DISALLOW_MODIFY_ACCOUNTS 用户欺压，斥地统统者和个东说念主贵府统统者仍可调用 Account Management API。 斥地统统者不错更缺欠地经管二级用户。当斥地在斥地统统者模式下运行时，系统会自动缔造 DISALLOW_ADD_USER 欺压。这样不错谨防用户创建非托管二级用户。此外，CreateUser() 和 createAndInitializeUser() 方法已废除，革命创制的是新的 DevicePolicyManager.createAndManageUser() 方法。 斥地统统者不错打听斥地绚丽符。斥地统统者不错使用 DevicePolicyManager.getWifiMacAddress() 打听斥地的 Wi-Fi MAC 地址。若是斥地上从未启用 Wi-Fi，则此方法会复返 null 值。 责任模式缔造欺压责任应用打听。当责任模式关闭时，系统启动器通过使责任应用清醒为灰色来指点它们不可用。启用责任模式会再次规复平淡行动。 从“缔造”界面安设包含客户端文凭链和对应私钥的 PKCS #12 文献时，系统不再将该文凭链中的 CA 文凭安设到受信任的证据存储空间。当应用稍后尝试检索客户端文凭链时，这不会影响 KeyChain.getCertificateChain() 的驱散。若是需要，使用 .crt 或 .cer 文献扩张名的 DER 编码口头通过 Settings UI 单独将 CA 文凭安设到受信任的证据存储空间。 从 Android 7.0 起原，可针对每个用户经管指纹登记和存储空间。若是建立文献统统者的斥地计谋客户端 (DPC) 面向搭载 Android 7.0（API 级别 24）的斥地上的 API 级别 23（或更初级别），则用户仍不错在该斥地上缔造指纹，但责任应用不成打听斥地指纹。当 DPC 以 API 级别 24 及更高版块为主义平台时，用户不错通过顺次前去 Settings > Security > Work profile security 挑升为责任贵府缔造指纹。 DevicePolicyManager.getStorageEncryptionStatus() 会复返新的加密景色 ENCRYPTION_STATUS_ACTIVE_PER_USER，以标明加密处于步履景色，且加密密钥与用户关联。仅当 DPC 面向 API 级别 24 和更高等别时才会复返新的景色。 关于面向更早的 API 级别的应用，即使加密密钥是用户或建立文献特有的，系统也会复返 ENCRYPTION_STATUS_ACTIVE。 在 Android 7.0 中，若是斥地通过单独的责任挑战安设了托管建立文献，则蓝本平凡会影响通盘斥地的多个方法将会改变其行动口头。这些方法将仅应用于责任贵府，而不是影响通盘斥地。（此类方法的完好列表位于 DevicePolicyManager.getParentProfileInstance() 文档中。）举例，DevicePolicyManager.lockNow() 只锁定责任贵府，而不是锁定通盘斥地。关于其中每个方法，您都不错通过对 DevicePolicyManager 的父实例调用该方法来取得旧行动；您不错调用 DevicePolicyManager.getParentProfileInstance() 取得此父项。举例，若是您调用父实例的 lockNow() 方法，则通盘斥地将被锁定。 注解保留Android 7.0 教诲了一个注解可见性被忽略的很是。 这种问题会导致应用可在运行时打听蓝本不允许打听的注解。这些注解包括：
VISIBILITY_BUILD：仅应编译时可见。 VISIBILITY_SYSTEM：运行时应可见，但仅对底层系统可见。若是您的应用依赖此行动，请在运行时必须可用的注解中添加保留计谋。您不错使用 @Retention(RetentionPolicy.RUNTIME) 践诺此操作。
TLS/SSL 默许建立变更Android 7.0 对应用用于 HTTPS 和其他 TLS/SSL 流量的默许 TLS/SSL 建立作念出了以下蜕变：
RC4 加密套件现已停用。 CHACHA20-POLY1305 加密套件现已启用。默许停用 RC4 可能会导致就业器未协商出新式加密套件时，HTTPS 或 TLS/SSL 连合断开。首选的教诲方法是雠校就业器的建立，以启用更强更当代的加密套件和合同。理念念情况下，应启用 TLSv1.2 和 AES-GCM 以及 Forward Secrecy 加密套件（ECDHE），且最好使用后者。
另一种方法是修改应用以使用自界说 SSLSocketFactory 与就业器通讯。出厂时应经心想象以创建 SSLSocket 实例，除默许加密套件外，此实例还应启用就业器所需的部分加密套件。
提防：这些蜕变不适用于 WebView。
以 Android 7.0 为主义平台的应用这些行动变更仅适用于以 Android 7.0（API 级别 24）或更高版块为主义平台的应用。针对 Android 7.0 进行编译或将 targetSdkVersion 设为 Android 7.0 或更高版块的应用必须进行修改，以便安妥地补助这些行动（若是适用）。
序列化变更Android 7.0（API 级别 24）教诲了狡计默许 serialVersionUID 时与表率不符的 bug。
收场 Serializable 且未指定显式 serialVersionUID 字段的类可能会看到其默许 serialVersionUID 发生变化，这会导致在尝试反序列化在较低版块上序列化或由以较低版块为主义平台的应用序列化的类实例时抛出相配。很是音书将如下所示：
local class incompatible: stream classdesc serialVersionUID = 1234， local class serialVersionUID = 4567
若要贬责这些问题，需要向任何受影响的类添加一个 serialVersionUID 字段，该字段值为很是音书中的 stream classdesc serialVersionUID（举例，在本例中为 1234）。此更革新职了编写序列化代码的统统最好本质提议，何况适用于统统版块的 Android。
教诲的具体 bug 与静态开动化表率方法（即 <clinit>）的存在关系。根据表率，类中是否存在静态开动化表率方法将影响为该类狡计的默许 serialVersionUID。 在教诲 bug 之前，若是类莫得静态开动化表率，则狡计还会查验超类是否有静态开动化表率。
需要证明的是，此变更不会影响以 API 级别 23 或更初级别为主义平台的应用、具有 serialVersionUID 字段的类或具有静态开动化表率方法的类。
其他首要证明 若是某个应用在 Android 7.0 上运行，但其主义 API 级别较低，何况用户蜕变清醒大小，则系统会阻隔该应用进度。应用必须大概妥善处理此情景。不然，当用户从最近用过的应用列表中规复运行应用时，应用将会出现崩溃气候。您应测试您的应用，以确保不会发生此行动。 为此，您不错通过 DDMS 手动阻隔应用，变成疏浚的崩溃。
密度发生蜕变时文爱，系统不会自动阻隔以 Android 7.0（API 级别 24）及更高版块为主义平台的应用，但这些应用仍可能对建立蜕变作念出不良反应。
Android 7.0 上的应用应该大概妥善处理建立蜕变，何况在后续启动时不会崩溃。您不错通过蜕变字体大小 (Setting > Display > Font size) 并随后从最近使用纪录中规复运行应用，来考据应用行动。 由于之前的 Android 版块中的一项很是，系统未能将对干线程上的一个 TCP 套接字的写入操作举报为违抗严格模式。Android 7.0 教诲了此 bug。阐述出此行动的应用面前会抛出 android.os.NetworkOnMainThreadException。一般情况下，咱们不提议在干线程上践诺网罗操作，因为这些操作平凡都有可能导致 ANR 和卡顿的高延长。 Debug.startMethodTracing() 方法族面前默许在您的分享存储空间上的软件包特定目次中存储输出，而非 SD 卡根目次。这意味着应用不再需要肯求 WRITE_EXTERNAL_STORAGE 权限即可使用这些 API。 好多平台 API 面前起原查验在 Binder 事务间发送的大负载，系统面前会将 TransactionTooLargeExceptions 再次手脚 RuntimeExceptions 激励，而不再只是沉默纪录或遏制它们。一个常见例子是在 Activity.onSaveInstanceState() 中存储过多量据，导致 ActivityThread.StopInfo 在您的应用以 Android 7.0 为主义平台时抛出 RuntimeException。 若是应用向 View 发布 Runnable 任务，何况 View 未附加到窗口，系统会用 View 为 Runnable 任务列队；在 View 附加到窗口之前，Runnable 任务不会践诺。此行动会教诲以下很是： 若是某个应用从预期窗口的界面线程除外的线程发布到 View，则 Runnable 可能会因此在很是的线程上运行。 若是 Runnable 任务是从并非环道路程的其他线程发布，则应用可能会曝光 Runnable 任务。 若是 Android 7.0 上一项有 DELETE_PACKAGES 权限的应用尝试删除一个软件包，但另一项应用仍是安设了这个软件包，则系统需要用户进行阐发。在这种情况下，应用在调用 PackageInstaller.uninstall() 时预测的复返景色应为 STATUS_PENDING_USER_ACTION。 名为 Crypto 的 JCA 提供表率已弃用，因为它仅有的 SHA1PRNG 算法为弱加密。应用无法再使用 SHA1PRNG（以不安全的口头）派生密钥，因为此提供表率不再可用。如需了解细目，请参阅博文 Android N 中已弃用“Crypto”安全提供表率。