Android N——7.0版本脱坑指南

 金诚   2018-01-13 09:24   72 人阅读  0 条评论

1.安装时解析错误

我们的App通常会有检查更新的功能。用户在收到提示更新并且下载完后,会自动打开安装页面让用户来去安装。这时就会出现安装错误的问题,这类的问题的可能性比较多。比如较低版本的App想要覆盖已有的较高版本App会提示安装未完成,或是签名不一致导致的。不过7.0上常见的有以下两种情况。

1.应用间共享文件

targetSdkVersion大于等于的24的App中,但是我们没有去适配7.0。那么在调用安装页面,或修改用户头像操作时,就会失败。那么就需要你去适配7.0或是将targetSdkVersion改为24以下(不推荐)。适配的方法这里就不细讲,大家可以看鸿洋大神的 Android 7.0 行为变更 通过FileProvider在应用间共享文件吧 这篇文章。

2.APK signature scheme v2

Android 7.0 引入一项新的应用签名方案 APK Signature Scheme v2,它能提供更快的应用安装时间和更多针对未授权 APK 文件更改的保护。在默认情况下,android Studio 2.2 和 Android Plugin for Gradle 2.2 会使用 APK Signature Scheme v2 和传统签名方案来签署您的应用。详细看安卓官方说明

简单地说就是任何方式的篡改APK 文件,在利用了V2签名的apk上会失效。

我所用的Android Studio目前是2.3.3 在 Gradle 2.2.3时。打包页面是这样

这里写图片描述

可以看到默认是V1 和V2选中的。

1)只勾选v1签名就是传统方案签署,但是在7.0上不会使用V2安全的验证方式。
2)只勾选V2签名7.0以下会显示未安装,7.0上则会使用了V2安全的验证方式。
3)同时勾选V1和V2则所有版本都没问题。

这里问题就来了,默认全部勾选,按道理所有版本是没有问题的。那么我们为什么还是安装错误?其实是因为我们项目采用了美团的快速生成渠道包方案。这种方案不适用于V2的签名方案。(因为实现思路就是给已有的apk文件中添加空的渠道文件)

解决办法:

1.如果你的渠道较少,可以用gradle方式的多渠道打包。渠道多的话就不适用了。

2.毕竟V2不是强制的,那么我们要用传统方案签署,可以打开模块级build.gradle 文件,然后将行v2SigningEnabled false 添加到您的版本签名配置中:

 

或者将Gradle 升级为2.3以上。那么打包页面是这样

我们可以不勾选V2选项。

3.前两种方法是比较快速的可以解决问题,但是一旦这种安全措施被强制(毕竟我们可以感受到安卓在安全方面的努力,比如权限控制、应用间共享文件),我们怎么办。其实美团早早发现了这个问题,具体看这篇 新一代开源Android渠道包生成工具Walle。里面有深度的原理讲解,满满的干货。

2.PopupWindow位置不正确

7.0系统的手机上,PopupWindow弹出位置不正确。有两种可能:

1.我们使用了update方法,同时设置了GravityGravity.NO_GRAVITY没事)。因为在update方法中有调用computeGravity方法去获取Gravity。(7.0以下没有获取Gravity进行更新判断)

Android 7.0computeGravity方法源码

Android 7.1computeGravity方法

很显然在7.0上我们设置的Gravity被覆盖了。解决就很简单了,不使用update方法。如果你真的要使用可以参考这篇文章的方法。

2.PopupWindow高度为MATCH_PARENT,在显示的时候调用showAsLocation方法时,PopupWindow并没有在指定控件的下方显示。如果使用showAsDropDown,会全屏显示。

解决方法:

1.最简单的解决方法就是指定 PopupWindow 的高度为 WRAP_CONTENT, 调用 showAsDropDown方法。

2.或者弹出时做一下判断处理(代码来自PopupWindowCompat

3.后台优化

小伙伴们都知道在Android中有一些隐式广播,使用这些隐式广播可以做一些特定的功能,如,当手机网络变成WiFi时自动下载更新包等。 但,这些隐式广播会在后台频繁启动已注册侦听这些广播的应用,从而带来很大的电量消耗,为缓解这一问题来提升设备性能和用户体验,在Android 7.0中删除了三项隐式广播,以帮助优化内存使用和电量消耗。

Android 7.0 应用了以下优化措施:

  • 在 Android 7.0上 应用不会收到 CONNECTIVITY_ACTION 广播,即使你在manifest清单文件中设置了请求接受这些事件的通知。 但,在前台运行的应用如果使用BroadcastReceiver 请求接收通知,则仍可以在主线程中侦听 CONNECTIVITY_CHANGE。
  • 在 Android 7.0上应用无法发送或接收 ACTION_NEW_PICTUREACTION_NEW_VIDEO 类型的广播。

应对策略:Android 框架提供多个解决方案来缓解对这些隐式广播的需求。 例如,JobScheduler API
提供了一个稳健可靠的机制来安排满足指定条件(例如连入无线流量网络)时所执行的网络操作。 您甚至可以使用 JobScheduler API 来适应内容提供程序变化。

另外,大家如果想了解更多关于后台的优化可查阅后台优化

移动设备会经历频繁的连接变更,例如在 Wi-Fi 和移动数据之间切换时。 目前,可以通过在应用清单中注册一个接收器来侦听隐式 CONNECTIVITY_ACTION 广播,
让应用能够监控这些变更。 由于很多应用会注册接收此广播,因此单次网络切换即会导致所有应用被唤醒并同时处理此广播。

以上内容来自这里

4.Doze模式更加强大

该模式是在Android6.0中引入的,当用户设备未插电源、处于静止状态屏幕关闭时,该模式会推迟CPU和网络活动,从而增加电池寿命。

在Android_N中对这种模式进行了加强,当设备处于充电状态且屏幕已关闭一定时间后,设备会进入打盹模式并应用第一部分限制:关闭应用网络访问、推迟作业和同步。如果进入打盹模式后设备处于静止状态达到一定时间,系统则会对 PowerManager.WakeLock、AlarmManager 闹铃、GPS 和 Wi-Fi 扫描应用余下的打盹限制。无论是应用部分还是全部打盹限制,系统都会唤醒设备以提供简短的维护时间窗口,在此窗口期间,应用程序可以访问网络并执行任何被推迟的作业/同步。

这种情况倒也好办,要么就是让用户将自己的的应用加入白名单,

或则在代码中使用Intent的方式跳转到设置页面,让用户去设置;

Google推荐我们使用Schedule的方式来管理我们的任务,我们可以设置让这些任务在特定的时候才去执行,比如将任务设置运行在充电或则无限制的时候运行,如下就是加入一个网络无限制的任务:

Google在API 23中为我们加入了一个新的Action,我们可以通过调用这个Action跳转到指定页面指导用户设置白名单:

在Doze模式中还有一种Standby的模式,这个模式相对更严格,如果对于及时通信的软件在未加入白名单的情况下,处于该模式不能收到及时的提示,必须从该模式恢复才能收到,因此需要特别注意,我们可以从google的官方文档当中查到进入该模式的ADB指令:

将第二条指令中的true改为false即可恢复,这个便于开发和测试。

5.禁止一些广播的行为

在之前的Android系统中,我们开启一个监听事件的广播后,程序在事件触发的时候就会触发我们的广播,而且不值一个程序会收到通知,所以在Android_N中对CONNECTIVITY_ACTION、ACTION_NEW_PICTURE和ACTION_NEW_VIDEO三个广播进行了处理。

a) 面向 Android N 开发的应用不会收到 CONNECTIVITY_ACTION 广播,即使它们已有清单条目来请求接受这些事件的通知。在前台运行的应用如果使用 BroadcastReceiver 请求接收通知,则仍可以在主线程中侦听 CONNECTIVITY_CHANGE。

b) 应用无法发送或接收 ACTION_NEW_PICTURE 或 ACTION_NEW_VIDEO 广播。此项优化会影响所有应用,而不仅仅是面向 Android N 的应用。

未来的 Android 版本还可能会弃用其他隐式广播以及未绑定的后台服务。有鉴于此,您应避免依赖在清单文件中声明的接收器来侦听隐式广播或删除此依赖关系,以及避免或删除对后台服务的依赖关系。

6.权限机制的更改

Android N 做了一些权限更改,包括用户帐户权限和向外部存储设备写入信息的新权限,这些更改可能会影响您的应用。下面概要列出了预览版中已发生更改的权限。
GET_ACCOUNTS(已弃用)
GET_ACCOUNTS 权限现已弃用。对于面向 Android N 的应用,系统将忽略此权限。

下面我们就来着重的谈一谈关于这个权限修改,从Android6.0开始Google引入了权限动态申请的机制,在之前的版本中,我们申请权限都是一次性在应用的Manifest文件中将我们程序所需要的权限,在用户安装App的时候一起向用户申请,这样会造成要么用户没有仔细看就直接同意安装了,为后期带来安全隐患,要么用户不同意应用程序无法安装,但是对于一个app来说,可能有的权限不是我们必须的,因此Google在Android6.0中就引入了动态申请权限的机制。

该机制面向于6.0以上的版本,并且在6.0中将targetVersion指定为23,否者效果和之前的版本一样。

我们就拿<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />这个向外部存储卡进行写操作的权限来举例。

当我们需要向外部存储卡进行写操作的时候,我们需要遵循如下的步骤:

a).查询是否具有该权限:

这里面需要注意的是,为了向下兼容,ContextCompat和ActivityCompat的导入的是support.v4包下的

hasPerMission就是查询的返回值,如果返回true就表示我们已经具有了权限,可以直接进行操作,如果是false的话,我们就需要向用户动态的申请写的权限了,如下:

这个函数类似于我们常用的startActivityForResult的方法,它会触发一个回调,其中REQUEST_WRITE_CODE就是我们自定义的请求码。

b).处理请求的回调


当请求权限时就会在用户的屏幕上弹出如上的界面,用户点击拒绝或者同意都会触发我们上面的回调函数,如果同意就返回true,否者就会返回false。

这种情况下,当用户点击同意后,下次再次访问就不需要再次申请了,如果用户点击拒绝,当用户下次再次请求的时候该弹出框还会再次出现,这里我需要额外补充的是,在我们开发模式的时候,如果我们之前选择了同意某项权限后,当我们没有卸载程序而是直接又一次编译程序,此时系统认为我们具有了权限;另一点值得注意的就是这些权限用户是可以动态取消的,所以一个健壮的程序应当做好判断。

上面的方法是在6.0引入的,这种方式虽然可以达到我们往外部写存储卡的目的,但是也带来了这种权限申请机制与当初的动态申请权限的初衷有一定的出入,所以在Android_N中我们改用另一种更好的方式,这种方式将我们的权限范围设定的更加的准确。

使用 StorageManager 类获取适当的 StorageVolume实例。然后,通过调用该实例的 StorageVolume.createAccessIntent() 方法创建一个 Intent。使用此 Intent 访问外部存储目录。 若要获取所有可用卷的列表,包括可移动介质卷,请使用 StorageManager.getVolumesList()。

该种方式将请求权限用向特定的目录发一个Intent的形式,然后触发我们的onActivityResult()的方法,

注意:有一点需要特别注意的就是,StorageVolume 这个类是在Android_N的sdk版本中引入的,所以如果你的编译版本不是Android_N的话,就不要用这个方法了,否者编译都通过不了。

下面我们就将请求外部存储卡上的DIRECTORY_PICTURES目录作为例子:

如果用户授予访问权限,则系统会调用onActivityResult()的重写方法,且结果代码为Activity.Result_OK,Intent包含URL。使用提供的URL访问目录信息,与使用存储访问框架返回的URL类似。

如果用户不同意,则结果码为Activity.Result_CANCELED,Intent的数据为空。

以上是对回调的处理,getActivity().getContentResolver().takePersistableUriPermission是存储我们请求的URl地址,将其保存下来,下次我们再次请求就不会再弹出让用户确认的界面了,返回结果就直接是RESULT_OK。

上面这张表是对是否需要请求权限的小统计数据。

7.JNI中不允许调用非公有API

JNI中不允许调用非公有API,由于命名空间的变化,在Android_N上运行会奔溃,需要切换到对应的公有API.

应用不应依赖或使用不属于 NDK 的原生库,因为这些库可能会发生更改或从一个 Android 版本迁移至另一版本。例如,从 OpenSSL 切换至 BoringSSL 即属于此类更改。此外,不同的设备可能提供不同级别的兼容性,因为不属于 NDK 中的平台库没有兼容性要求。如果您必须在较旧设备上访问非 NDK 库,则请依据 Android API 级别进行加载。

为帮助诊断问题,Google为我们给出了错误代码的示例:

Java 错误示例:

NDK 错误示例:

Google提供的一些典型的修复办法:

a).可以使用标准 JNI 函数来替代使用 libandroid_runtime.so 中的 getJavaVM 和 getJNIEnv:

b).可以使用公开备选项 __system_property_get 来替代使用 libcutils.so 中的 property_get 符号。如需这样做,请使用 __system_property_get 及以下 include 函数:

c).应使用应用本地版本来替代使用 libcrypto.so 中的 SSL_ctrl 符号。例如,您应在 .so 文件中静态链接 libcyrpto.a,或者在应用中包含您自己的来自 BoringSSL 或 OpenSSL 的动态 libcrypto.so。

8.屏幕支持缩放功能:

Android_N支持用户设置显示尺寸,可以放大或缩小屏幕上的所有元素,但是用户无法将屏幕宽度缩放至低于sw320dp。

当设备密度发生更改时,系统会以如下方式通知正在运行的应用:

如果是面向 API 级别 23 或更低版本系统的应用,则系统会自动终止其所有后台进程。这意味着如果用户切换离开此类应用,转而打开 Settings 屏幕并更改 Display size 设置,则系统会像处理内存不足的情况一样终止该应用。如果应用具有任何前台进程,则系统会如处理运行时变更中所述将配置变更通知给这些进程,就像对待设备屏幕方向变更一样。

如果是面向 Android N 的应用,则其所有进程(前台和后台)都会收到有关配置变更的通知,如处理运行时变更中所述。

大多数应用并不需要进行任何更改即可支持此功能,不过前提是这些应用遵循 Android 最佳实践。具体要检查的事项:

在屏幕宽度为 sw320dp 的设备上测试您的应用,并确保其充分运行。

当设备配置发生变更时,更新任何与密度相关的缓存信息,例如缓存位图或从网络加载的资源。当应用从暂停状态恢复运行时,检查配置变更。

注:如果您要缓存与配置相关的数据,则最好也包括相关元数据,例如该数据对应的屏幕尺寸或像素密度。保存这些元数据便于您在配置变更后决定是否需要刷新缓存数据。

避免用像素单位指定尺寸,因为像素不会随屏幕密度缩放。应改为使用与密度无关像素 (dp) 单位指定尺寸。

多屏模式:

Google在Android_N中支持了多屏模式,我们可以在Manifest文件中配置Activity的android:resizeableActivity=["true" | "false"]来让其是否支持,默认是支持的。

特别注意的一点是:一个根Activity的设置属性将会被应用到所有在这个Task栈中的Activity(一个任务栈的根Activity一般是这个任务栈栈底的Activity,即该任务栈第一个启动的Activity)。即当根Activity的android:resizeableActivity属性为true,则在这个Task栈中的所有其他Activity都将是支持多屏模式的。

带来的问题

a).应用如要支持多窗口,也有一些需要注意的地方,最主要的是分辨率的适配。在多窗口模式下,应用的显示比例不一定是手机屏幕的比例。这里可能会影响到一些代码,比如应用一启动就全局存储一下屏幕的宽高,在N下可能就有问题了,需要开发者做相应的修改。

b).在多屏模式以下特性无法使用:应用无法隐藏状态栏如果他不是全屏模式下。

c).系统忽略android:screenOrientation属性(无法根据屏幕方向来旋转App的界面)。

9.Android N 逐渐将JDK8.0引入

A)ArrayList实现中的私有属性array被移除,反射使用该属性的需要注意下

B)随机数种子调用可能出错,Crypt安全提供商在OpenJdk中不提供,而它在大家调用SecureRandom.serSeed()设置随机种子时会用到,OpenJDK中需要通过SecretKeySpec去直接加载原始密钥或者使用真正的密钥导出函数。

本文地址:http://www.yangchaofan.cn/archives/2500
版权声明:本文为原创文章,版权归 金诚 所有,欢迎分享本文,转载请保留出处!

说点什么

avatar
  Subscribe  
提醒