Android N 程序适配要点

首先说明一点Android n 程序适配要点，不是指屏幕适配要点，对于屏幕适配，笔者转载了一篇博客，笔者感觉说的很到位，有需要的点击这里，而是结合android N的性特性，说明一下开发目标平台是android n的app或者将现有android app改为android n平台app的一些注意事项，如果不留意这些事项，你本来好好的程序，在android n上就可能会异常停止（crash）或者存在隐患。正因为这样，笔者特地从网络上整理了如下六个要点，有了这六个要点，妈妈就不担心我的程序突然在android n 上奔溃了。

 

1.Doze(打盹模式)更加强大

 

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

 

在Android_N中对这种模式进行了加强，当设备处于充电状态且屏幕已关闭一定时间后，设备会进入打盹模式并应用第一部分限制：关闭应用网络访问、推迟作业和同步。如果进入打盹模式后设备处于静止状态达到一定时间，系统则会对PowerManager.WakeLock、AlarmManager闹铃、GPS和Wi-Fi扫描应用余下的打盹限制。无论是应用部分还是全部打盹限制，系统都会唤醒设备以提供简短的维护时间窗口，在此窗口期间，应用程序可以访问网络并执行任何被推迟的作业/同步（这就可能会使得一部分程序例如下载程序在屏幕关闭一段时间后，网络中断，未完成的下载任务下载失败，如果你的下载程序还没有保存断点的功能，你只能等下次开启屏幕后再重新下载，同理上传文件也一样）。

 

这种情况倒也好办，要么就是让用户将自己的的应用加入白名单，或则在代码中使用Intent的方式跳转到设置页面，让用户去设置；

 

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

 

 

 

 

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

 

 

 

 

 

 

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

 

 

 

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

 

2.禁止一些广播的行为（如果现有app接受了这些广播，那现在就得改用别的方法实现功能，如果是网络连接广播，可以使用jobschedule来替换，至于其他广播，就得根据实际情况）

 

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

 

 

a) 面向 Android N开发的应用不会收到CONNECTIVITY_ACTION广播，但是对于一个前台程序则不会受到限制例如：CONNECTIVITY_CHANGE。

 

 

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

 

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

 

 

3.权限机制的限制

 

 

 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。

 

 

 

 

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

 

4.JNI中不再允许调用非公有的API

 

 

JNI中不允许调用非公有API，由于命名空间的变化，在Android_N上运行会奔溃，需要切换到对应的公有API，此类问题在大多数的APP中都存在，值得特别注意（很多对底层做了优化的程序在android n 中奔溃就是由于这个原因）.

为帮助诊断问题，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。

 

5.屏幕支持缩放功能（这就会导致屏幕适配方面做得不够好的app在这种情况下，出现错位，显示不全等问题，但是如果你的程序已做了多屏幕适配，那么问题就会没那么明显，如果还影响用户体验那就说明屏幕适配种类不够多或者是屏幕适配不合格，关于屏幕适配，笔者转载了一篇博客，笔者感觉说得很到位，有需要可以点这里）:

 

 

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。

 

 

带来的问题

 

 

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

 

 

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

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

 

 

6.Android N 逐渐将JDK8.0引入（现在才刚引入，需要特殊配置才使用jdk8编译，而且更多的是引入一些新语法，笔者认为短期之内对app影响不大，可能出问题导致app奔溃的地方，也就一个，如下：）

 

 

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