Android7.0版本影响开发的改进分析

本文总结分析了android7.0版本影响开发的改进。分享给大家供大家参考，具体如下：

低电耗模式

会对闹铃、gps 和 wi-fi 扫描 产生限制.
可参考optimizing for doze and app standby
使用gcm来发送和接受消息

后台优化

android n 删除了三项隐式广播,隐式广播会在后台频繁启动已注册侦听这些广播的应用。 删除这些广播可以显著提升设备性能和用户体验.

侦听网络变化的主线程广播改为: connectivity_change。
对所有应用都无法 发送和接受 action_new_picture 或 action_new_video .

可以使用jobscheduler api ,更多参考后台优化

系统权限更改

为了提高私有文件的安全性，面向 android 7.0或更高版本的app私有目录被限制访问(0700)。此设置可防止私有文件的元数据泄漏，如它们的大小或是否存在（状态）。此权限策略的更改有多重副作用：

私有文件的文件权限不应再由所有者放宽，为使用mode_world_readable和mode_world_writeable而进行的此类尝试将触发securityexception，会导致app崩溃的。

注：迄今为止，这种限制还不能完全执行。app仍可能使用原生api或file api来修改它们的私有目录权限。但是google强烈反对放宽私有目录的权限。

传递软件包网域外的 file://uri可能给接收器留下无法访问的路径。因此传递file://uri会触发 fileuriexposedexception。分享私有文件内容的推荐方法是使用fileprovider。

downloadmanager不再按文件名分享私人存储的文件。老的app在访问column_local_filename时可能出现无法访问的路径。针对android 7.0或更高版本开发的应用在尝试访问column_local_filename时会触发 securityexception。通过使用downloadmanager.request.setdestinationinexternalfilesdir())或downloadmanager.request.setdestinationinexternalpublicdir())将下载位置设置为公共位置的老app仍可以访问column_local_filename中的路径，但是google还是强烈反对使用这种方法。访问由downloadmanager公开的文件的首选方式是使用contentresolver.openfiledescriptor())。

应用间共享文件

对于针对android 7.0的应用，android framework执行的strictmode api禁止向你的app外公开file://uri。如果一个包含文件uri的intent发送到你的应用之外，app会发生fileuriexposedexception异常。

若要在应用间共享文件，您应发送一项content://uri，并授予uri临时访问权限。进行此授权的最简单方式是使用fileprovider类。如需有关权限和共享文件的更多信息，请参阅共享文件。

解决 android n 上 安装apk时报错：android.os.fileuriexposedexception:

在androidmanifest.xml中添加如下代码

<provider
  android:name="android.support.v4.content.fileprovider"
  android:authorities="app的包名.fileprovider"
  android:granturipermissions="true"
  android:exported="false">
  <meta-data
    android:name="android.support.file_provider_paths"
    android:resource="@xml/file_paths" />
</provider> 

注意：

authorities：app的包名.fileprovider
granturipermissions：必须是true，表示授予 uri 临时访问权限
exported：必须是false
resource：中的@xml/file_paths是我们接下来要添加的文件

在res目录下新建一个xml文件夹，并且新建一个file_paths的xml文件（如下图）

输入以下内容

<?xml version="1.0" encoding="utf-8"?>
<paths>
  <external-path path="android/data/app的包名/" name="files_root" />
  <external-path path="." name="external_storage_root" />
</paths>

path：需要临时授权访问的路径（.代表所有路径）
name：就是你给这个访问路径起个名字

最后修改代码:

intent intent = new intent(intent.action_view);
//判断是否是androidn以及更高的版本
if (build.version.sdk_int >= build.version_codes.n) {
  intent.setflags(intent.flag_grant_read_uri_permission);
  uri contenturi = fileprovider.geturiforfile(context, buildconfig.application_id + ".fileprovider", apkfile);
  intent.setdataandtype(contenturi, "application/vnd.android.package-archive");
} else {
  intent.setdataandtype(uri.fromfile(apkfile), "application/vnd.android.package-archive");
  intent.setflags(intent.flag_activity_new_task);
}
startactivity(intent);
//以前我们直接 uri.fromfile(apkfile)构建出一个uri,现在我们使用fileprovider.geturiforfile(context, buildconfig.application_id + ".fileprovider", apkfile); //buildconfig.application_id直接是应用的包名

屏幕缩放

android 7.0支持用户设置显示尺寸，以放大或缩小屏幕上的所有元素，从而提升设备对视力不佳用户的可访问性。用户无法将屏幕缩放至低于最小屏幕宽度sw320dp，该宽度是nexus 4的宽度，也是常规中等大小手机的宽度。

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

1. 如果是面向api leve 23或更低版本系统的应用，系统会自动终止其所有后台进程。也就是说如果用户切换后离开你的app，打开“settings”更改display size设置，则系统会像处理内存不足的情况一样终止该应用。如果应用具有任何前台进程，则系统会如处理运行时变更中所述将配置变更通知给这些进程，就像对待设备屏幕方向变更一样，具体大家可以再看看这个超链接。

2. 如果是针对android 7.0的app，则其所有进程（前台和后台）都会收到有关配置变更的通知，如处理运行时变更中所讲的那样。 大多数app并不需要进行任何更改即可支持此功能，不过前提是这些应用遵循android最佳实践。具体要检查的事项：

① 在屏幕宽度为 sw320dp 的设备上测试你的app，并确保其正常运行。

② 当设备config发生变更时，更新任何与密度相关的缓存信息，例如缓存位图或从网络加载的资源。当应用从暂停状态恢复运行时，检查config的变化。
注：如果你要缓存与配置相关的数据，则最好也包括相关元数据，例如该数据对应的屏幕尺寸或像素密度。保存这些元数据便于你在config变更后决定是否需要刷新缓存数据。

③ 避免用像素单位指定尺寸，因为像素不会随屏幕密度缩放。应改为使用dp等单位。

用户可以在设置-显示-显示大小修改屏幕宽度，也可以在设置-开发人员选项-最小宽度随意设置指定宽度，开发人员特别需要注意适配

ndk平台库

android n 做了一些命名空间更改,阻止加载非公开api,会出现一些常见错误

如,unsatisfiedlinkerror

典型修复方法：

1. 使用标准 jni 函数来替代使用 libandroid_runtime.so 中的 getjavavm 和 getjnienv
2. 使用公开 alternative __system_property_get 来替代使用 libcutils.so 中的 property_get 符号
3. 使用应用本地版本来替代使用 libcrypto.so 中的 ssl_ctrl 符号

注解保留

android 7.0在注解可见性被忽略时修复错误。这种问题将启用本不应被允许的运行时访问注解。 这些注解包括：

visibility_build：仅应编译时可见。
visibility_system：运行时应可见，但仅限基本系统。 如果你的app依赖这种行为，请在注解中添加一项运行时必须可用的保留政策。你可通过使用@retention(retentionpolicy.runtime) 这样做。

其他重要说明

1. 如果一个针对较低api级别开发的app在android 7.0上运行，那么在用户更改显示尺寸时，系统将终止此app进程。app必须能够正常处理此情景。否则，当用户从最近使用记录中恢复运行app时，app将会出现崩溃现象。您应测试应用以确保不会发生此行为。要进行此测试，您可以通过ddms手动终止应用，可以造成相同的崩溃现象。在屏幕密度发生更改时，系统不会自动终止针对android 7.0及更高版本开发的app；不过这些app仍可能对配置变更做出不良响应。

2. android 7.0上的应用应能够正常处理配置变更，并且在后续启动时不会出现崩溃现象。你可以通过更改字体大小 (setting > display > font size) 并随后从最近使用记录中恢复运行应用，来验证app行为。

3. 由于之前的android版本中的一项错误，系统没有对主线程上的一个tcp socket的写入操作严格检查。android 7.0修复了这个系统错误。之前有这种行为的app将会引发android.os.networkonmainthreadexception。一般情况下，不建议在主线程上执行网络操作，因为这些操作通常都有可能导致anr和卡顿，这个应该是中所周知的，大家一般不会犯。

4. debug.startmethodtracing()方法族现在默认在你的共享的存储空间上的软件包特定目录中存储输出，而非 sd卡*。这意味着应用不再需要请求write_external_storage权限就可以使用这些api。

5. 许多平台api现在开始检查在binder事务间发送的大负载，系统现在会将transactiontoolargeexceptions再次作为runtimeexceptions引发，而不再只是默默记录或不抛出这个错误。一个常见例子是在activity.onsaveinstancestate())上存储过多数据，导致activitythread.stopinfo在你的app面向 android 7.0时引发runtimeexception。

6. 如果应用向view post runnable任务，并且view未附加到窗口，系统会用view为runnable任务排队；在 view附加到窗口之前，runnable任务不会执行。 此行为会修复以下错误：

① 如果一个app是从并非预期window ui线程的其他线程发布到view，则runnable可能会因此运行错误。

② 如果runnable任务是从并非looper thread的其他线程发布，则应用可能会曝光runnable任务。

7. 如果android 7.0上有delete_packages权限的应用尝试删除一个软件包，但另一项应用已经安装了这个软件包，则系统可能要求用户确认。在这种情况下，应用在调用packageinstaller.uninstall()) 时的返回状态应为status_pending_user_action。

更多关于android相关内容感兴趣的读者可查看本站专题：《android开发入门与进阶教程》、《android调试技巧与常见问题解决方法汇总》、《android基本组件用法总结》、《android视图view技巧总结》、《android布局layout技巧总结》及《android控件用法总结》

希望本文所述对大家android程序设计有所帮助。