让您的应用兼容 Android Oreo

不知不觉Android Oreo已经发布几个月时间了，你的应用开始使用最新平台了吗？在应用迁移过程中是否遇到了一些棘手问题？你的Android应用兼容Oreo如何呢？



我们应该都知道，每一次重大升级，在兼容性这一块总会出现或多或少的问题，今天就来一起探讨应用的兼容性。

不知道大家是否还记得，从Android 7.0更新后兼容性测试数据结果得知，Top1000主流应用中不兼容应用数量达到166个，导致总体兼容率仅为83%，相比之前Android 6.0 的更新所导致的应用不兼容问题更加突出。



对于本次Android 8.0升级之后的兼容性，各大应用厂商也非常关注。从本次Google 开发者大会上也能看出谷歌的用心，专门做了一个《让您的应用兼容 Android Oreo》的主题分享，这里也简单整理出来分享给大家，希望对大家将应用迁移到Android 8.0 时有一些帮助。



作为开发者，我们的应用应该保持与最新的Android版本兼容性，主要从两个方面来分享：Android 应用兼容的一些最佳实践经验和Android Oreo 中的一些改变地方。



在3月中旬发布第一个Android Oreo 预览版本的时候，发现中国的应用只有60%兼容，后来投入了很大的资源，也做了很多工作。



在8月25日正式发布后，中国Top1000主流应用中有993个兼容，目前在中国应用兼容比率达到96%。



1.非公开的API

有一些经验就是不要在开发中使用一些非公开的API，因为那些非公开的API在后期更新中可能随时会去改变函数签名或函数列表，甚至可能会被删除掉或改变它的行为。

如果有强烈愿望想要使用可以告知谷歌，会尽量搜集并提供一些公开的API提供给开发者，比如在Android Oreo 中开放了InMemoryDexClassLoader直接从内存里面加载dex，不要直接调用DexClassLoader，否则会对产生的文件造成一定影响。

2.dex / so文件

不要直接操作或篡改dex / so文件，最好使用Android Studio 或其他编译工具直接生成的dex / so文件。在apk方面也添加了更多的检查，动态连接器再向用户申请权限的时候，如可写权限和可执行权限，如果修改了so文件就可能会出错。

3.升级第三方SDK

在很多应用中有一些比较常见的第三方SDK，其中一些加固和热修复框架用了很多dex操作和私有API，这会导致当新的Android版本出现的时候，使用了这些SDK的应用会崩溃。

所以需要经常去看这些SDK是否更新，基本都会和这些SDK提供商有紧密的合作，当升级后就会尽量更新到最新版本。

4.Janus漏洞

从Android 5.0版本以后，如果应用仅仅采用SDK安卓的jarsigner签名机制，就会有一个Janus漏洞，该漏洞会利用ART来执行一个附加在APK之前的一个恶意dex文件。

目前已在12月发布的版本中修复，用户可以更新补丁，建议开发者使用V1+V2签名机制。

5.隐私

为了用户的安全性和隐私性，Settings.secure.ANDROID_ID将根据签名密钥和用户个人资料，每次为每个应用返回不同的值，也就是说一个应用不可能会知道其他应用的ANDROID_ID，对一些广告应用查询ID后可以被用户重置。

查询net.hostname系统属性会返回空值，如果需要访问用户账号的话，GET_ACCOUNTS权限不再充分，需要使用AccountChooserActivity来弹出一个选择框来让用户进行选择。

6.警报

对于警报方面，设计了一个新的浮动层，在所有应用之上，但是会在系统和关键窗口之下。如果在Android Oreo 中继续使用SYSTEM_OVERLAY，会自动替换为APPLICATION_OVERLAY。在Android Oreo 中设置使用TYPE_APPLICATION_OVERLAY更加直观，用户也可以更加方便来进行管理行为和设置。

7.通知

在Android Oreo 中对于所有通知都必须使用通知渠道。

8.多应用窗口显示

多窗口显示也是Android Oreo 中的一个新特性，可以用一个FLAG_ACTIVITY_LAUNCH_ADJACENT来告诉系统需要使用多窗口。当然需要注意的是，只有在活跃的屏幕里面的Activity才会认为是Activity Task，而不要假设暂停的Activity。多窗口模式的切换与转屏事件是相同的，标准UI模块在这方面应该没什么问题，如果不能支持多窗口可以通过android:resizeableActivity="fasle" 来设置。

9.特长屏幕支持

Android Oreo 也支持特长屏幕，目前很多厂商都在发布特长屏幕的手机，对于很多应用来说对屏幕纵横比有一个错误的假设，否则会有上下黑色边框，或UI模块和触摸点没有对齐，或一些角落UI会被遮挡等。

如果场景不适合特长屏幕，需要应用通过以下方式设置最大纵横比：API 25或以下使用android:max_aspect meta data，API 26或以上使用android:MaxAspectRatio。



接下来着重介绍一下后台检查和位置限制，首先并不是为了给开发者添麻烦，而是为了安卓用户获得更好的系统健康和电池性能的体验，并且开发者可以开发出用户需要的功能。总而言之，一共有三个方面：

1.后台没办法再启动服务了，前台启动服务仍然是没有问题的；

2.不支持在manifest中注册的隐式广播；

对于这两个主要是Target SDK为Android Oreo 才会受影响，但是不幸的是用户现在就可以对应用启用此限制。

3.后台应用会得到更严格的限制来获取位置。是所有运行在Android Oreo 上的应用都会受到影响，需要立刻解决这方面的问题。



1.服务

最重要的原则就是用户可见。如果应用正在进行耗费资源的工作时，用户是应该知晓的，从后台启动服务会失败，会抛出一个IllegalStateException给启动该Service的调用者。

开发者在调用startService时需要判定是否位于前台，注意IntentService也是一种后台服务，可以使用新加的一个类JobIntentService，可以在很多个地方使用来替换IntentService。大多数服务没有长时间的交互，可以使用JobScheduler或者Firebase Cloud来工作，使得系统更有效的来调度工作。



2.广播

不能通过在manifest中声明接收器来接收更多的隐式广播，隐式广播是指没有明确的目标组件。如不能通过ACTION_PACKAGE_REPLACED来监视广播，但是可以使用ACTION_MY_PACKAGE_REPLACED来监视显示广播。在很多使用广播的情况下，可以使用JobScheduler来代替。



3.位置信息限制

定位非常消耗电池，当有很多应用来定位的时候，电池会消耗的很快，会导致用户体验变差，甚至有些功能会失效，因此加入了一些后台定位的限制。如果应用在前台，其位置收集策略是不变的，如果用在后台就会受到一些限制。

具体说来就是每小时只能接收到几次位置信息，而且位置信息是基于整个设备的，只要在Android Oreo 上运行都会受到限制。使用批处理会造成一定时间的延迟，但是可以获得更多的数据位置信息点，也是一个不错的选择。

Android Oreo 里面做了一些优化，GPS很精确但是非常耗电，WIFI会好一点儿但还是比较耗电，优化的是当设备保持连接在相同的静态WIFI接入点就表示用户没有从原来的位置移动太多，系统就不会进行新的位置计算。

另外还可以更好的检测在不同的WIFI之间切换，如在家和工作的时候使用安卓设备，只有在切换WIFI的时候才会更新位置，平时待在家和待在工作地方的时间段里就不会更新位置信息。

同样的策略对地理围栏也做了类似的修改，目前关于地理围栏的信息会从几十秒增加到2分钟左右，其功耗只有十分之一。

在Android Oreo 里面不可以使用PengdingIntent.getService()来获取后台更新，虽然可以继续使用，但其只在前台工作。而应该使用PengdingIntent.getBroadcast()，同时在manifest中定义一个接收器，定义为显示广播。



4.位置信息策略

如果需要在后台密集的收集位置信息应该怎么办？这里有一些办法，可以定义一些地理围栏功能，在地理围栏发生变化时可以获得确切位置，可以通过这些位置信息来知道将来如何使用Firebase Cloud来进行更新。然后使用批处理来收集更多的数据点一起返回，虽然每小时只会接收几次信息，但是可以获取更多的数据，对于很多程序来说足够了，只是不能提供实时性的位置数据。可以使用setInterval来设置更新时间，使用setMaxWaitTime来设置批处理的最大时间间隔，使用setFastestInterval来设置被动获取位置信息。



以上就是本次主题分享的大致内容，除了以上这些在开发和迁移中，还会遇见一些其他兼容性问题，会在下一篇分享中整理出来。如果你在迁移应用到Android Oreo 中也遇见了一些问题，也欢迎留言一起来探讨。

此文章版权为微信公众号分享达人秀（ShareExpert）——鑫鱻所有，若需转载请联系作者授权，特此声明！





我的博客即将搬运同步至腾讯云+社区，邀请大家一同入驻：https://cloud.tencent.com/developer/support-plan