这一次谷歌很强硬,App 再不支持,两个月后将拒绝上架

标签: dev | 发表时间:2019-06-08 00:00 | 作者:
出处:http://itindex.net/relian


一. 序

事情是这样的,前几天收到 Google Play 的通知邮件,这才想起来有几款在 Google Play 上架的 App,还没有支持 64 位 CPU 架构。

早在今年一月份,Google 就发布通知,在今年 8 月 1 日开始,上架的 App,除了提供 32 位的版本之外,还需要提供 64 位的版本。

这眼看着离强制升级窗口,只剩下最后两个月的时间,很多第三放来源的 so 支持库,如果没有提供 64 位的版本,还需要同步催促合作方更新。

那今天就来聊聊 Android APK 升级 64 位 CUP 架构的细节,看看你的应用是否需要支持 64 位 CPU 架构,如果要支持,需要做什么?

二. Android CPU 架构细节

2.1 这是强制规范

早在 2015 年 Google 发布 Android 5.0 版本时,就加入了 64 位处理器的支持,当时就提出了以 19 年 8 月为最后的更新支持期限,并在今年又重申了这个强制要求。

只要你的 App 存在国际版,需要上架 Google Play,这个规定都必须准守。

2.2 那些 APK 需要支持 64 位?

那假如你有一个国际化的 App 需要维护,在今年 8 月 1 日之后,更新 Google Play 时,就必须提供 64 位的版本。

那这里说的 64 位版本支持,到底是什么?

如果你的应用,完全是使用 Java 或者 Kotlin 编写代码,不包含任何原生(Native)的支持,那么就表示这个应用已经支持 64 位。

但是应用内使用了任何原生(Native)的支持(so 库),就需要针对这些 so 文件,针对不同的 CPU 架构提供不同的版本的 so 支持。

需要注意的是,有些时候,在我们自身的代码中,确实没有用到原生的支持,但是在 App 中使用的一些第三方库中却包含了。

此时最稳妥的方式,就是针对最终打包生成的 APK 文件进行分析,来判断是否需要提供 64 位架构的支持。

那 CPU 架构是什么?什么又是 ABIs?

在 Android 中,虽然 ARM 的 CPU 架构是主流,但是目前至少支持几类 CPU 架构,ARM 下的 ARMv5/ARMv7/ARMv8,x86 下的 x86/x86_64,以及很不常见的 MIPS 类架构。这里的每一种 CPU 类型对应了一种 API(Application Binary Interface),例如 armeabi-v7a 中的 "armeabi"  指的就是 ARM 这种类型的 ABI,后面的 “v7a” 指的是 ARMv7。

通常我们可以简单的理解:

这三个概念是相通的,通常在技术讨论中,说的是一个东西。

2.3 为什么是强制的?

谷歌之所以会有强制更新的要求,很大一方面原因是因为作为开发者,更新补全 ABIs 的动力并不足。

主要原因来自以下几个方面:

1. APK 体积增大

针对不同 CPU 架构提供对应的 so 库,当然是效率最高的做法。但是这种做法,最直接的影响,就是 APK 文件的增大,有些时候补全这些 so 支持,会导致整个 APK 体积有几 MB 到几十 MB 的增幅。

APK 体积优化,很多公司都将其算做是一个 API 指标,加入一个新特性,导致 APK 体积的增大,在很多时候都是不允许的,为此换技术方案都是常有的事。

从增长的角度来看,越小的 APK,用户下载的意愿就更大,转化率就越高。

但是随着现在流量越来越便宜,近期 iOS 已经将 蜂窝数据下载限制从 150MB 放宽至 200MB,针对安装包的体积优化标准,也可以适当的放宽了。

2. 本身有一定的兼容性

应用市场中,很多 APP 其实都只有 armeabi 或者 armeabi-v7a 的支持,而市面上的设备,支持的并不是只有这两种 CPU 架构。

但是这并没有影响在这些设备上运行这些 App,这就是 CPU 架构的兼容性。

不同架构,并不意味着之间一定是不兼容的,在不同版本下,其实提供了两种 ABI 支持,分别是

  • 主要 ABI:与系统本身使用的原生代码一样,最优方案。

  • 辅助 ABI:支持的另一个 ABI 方案,兼容方案。

这种兼容策略就不在这里展开说了,最简单的就是 64 位的 arm64-v8a 在支持本身的 CPU 架构之外,还兼容支持 armeabi-v7a、armeabi;x86_64 同时也兼容支持 X86 和 armeabi。

你看,虽然添加 64 位的支持,可以有效的使用硬件的优势,提升性能,但大部分时候,采用兼容方案,是一种更简单的方式。

3. 没有对应架构的 so 文件

这个原因就比较尴尬了,我们 App 中使用到的原生代码,其实有两种。

一种是我们自己编写的,源码在手,想提供对应的支持,修改配置重新编译一下就解决了。

另一种来自第三方提供的,这种时候我们没有源码,无法做到重新编译,只能和第三方沟通,看能不能提供一个对应 CPU 架构的 so 库。这种情况就非常的不可控了。

例如比较常见的一个 WebView 的替换方案,腾讯 X5 内核,本身就不提供 X86 的库。

官方给的建议是使用 armeabi 或者 armeabi-v7a。

在前文有提到,ABIs 本身是有一些兼容规则的,但是这种兼容规则,是有条件的。

举个例子:64 位的 arm64-v8a 是可以向下兼容的,但是这有个前提,那就是如果你的项目中,有 armeabi-v7a 和 arm64-v8a 两个目录,就需要保证这两个目录下支持的 so 库文件保持一致。

在左边的情况下,如果 arm64-v8a 的手机用到 b.so 时,就会去 arm64-v8a 目录下找,当然是找不到 b.so 文件的,就会直接抛异常,而不会再去 armeabi-v7a 目录下继续寻找。

如果需要提供多套 ABIs 的支持,就需要保证所有 ABI 目录下,对应的 so 文件保持一致。

而在一些特殊的情况下,我们无法提供对应平台的 so 库,例如腾讯 X5 内核这种情况,就需要做个取舍了。

在没有 Google Play 的强制策略下,同时又因为各方考虑,大多数时候我们可能会舍弃其他 ABIs 的支持。但是现在既然强制执行了,腾讯 X5 内核就可能升级以提供 64 位的 so 库,毕竟一边是无法上架,另外一遍是一个 WebView 的内核,谁都知道怎么取舍。

三、支持 64 位架构

3.1 是否包含 64 位库?

介绍了 Android 下 CPU 架构的一些细节,接下来就要开始正题了,如何升级并支持 64 位架构。

从前文中应该了解到,支持对应的 ABIs,反映在项目中,就是存在对应 ABIs 架构的目录,并且目录中有完备的 so 库支持。

Google 并不要求我们支持所有的 64 位架构,但是对于已经支持的每种原生 32 位架构,就必须包含对应的 64 位架构。

例如:

  • 对于 ARM 架构,有 armeabi-v7a(32位) 就必须 arm64-v8a(64位)。

  • 对于 x86 架构,有 x86(32位) 就必须有 x86_64(64位)

这就要求我们有对应的目录,并且目录中包含对应的 so 文件。APK 中提供了完备的 ABIs 支持,运行的之后,会选取对应的最优支持进行加载和使用。

需要注意的是,有时候我们将 32 位的 so 复制到 64 位中,运行不会出现异常,但是这依然存在隐患。最好的办法是根据不同的架构,编译对应的 so 文件,原则上,我们的目标是确保应用可以在仅支持 64  位架构的环境中正常运行。

3.2 判断是否支持 64 位架构

前面也提到,我们的项目中,可能会引入一些第三方库,导致在不明确的情况下,引入了一些预期之外的 ABIs 库。

通常我们的做法是在 Gradle 中增加 abiFilters 过滤,来确保不会在打包输出的 APK 中存在预期之外的 ABIs 目录和 so 库。

  ndk {   
    //设置支持的SO库架构
    abiFilters 'armeabi-v7a' 
}

那么我们拿最终打包输出的 APK 文件去分析,是最稳妥的办法。

分析的方法有两种:

1. AS 的 APK 分析器

在 Android Studio 中,从菜单依次选择  Build → Analyze APK…

选择需要分析的 APK 文件,查看其 lib 目录,是否存在预期的 ABIs 目录以及完备的 so 文件。

2. 使用 zipinfo 命令进行分析

得到待分析的 APK 文件,就可以通过 zipinfo + grep 命令,输出其内包含的 so 文件。

  > zipinfo -1 YOUR_APK_FILE.apk | grep \.so$   
    lib/armeabi-v7a/libmain.so
    lib/armeabi-v7a/libmono.so
    lib/armeabi-v7a/libunity.so
    lib/arm64-v8a/libmain.so
    lib/arm64-v8a/libmono.so
    lib/arm64-v8a/libunity.so

依然是去看对应目录和 so 文件是否完备。

3.3 在 64 位设备上测试应用

支持 64 位架构是为了让我们利用 CPU 的特性,以提升性能,但是稳定依然是我们首先要保证的,所以在升级之后,就需要进行测试。

要测试 App,最简单的方式是使用 adb 命令安装该应用,可以配合 --abi参数,用以指示要将那些 so 库,安装到设备上,这样我们在这个设备上安装的 App,就会仅包含我们制定的库。

  # 成功安装 APK :   
> adb install --abi armeabi-v7a YOUR_APK_FILE.apk
Success

# 如果 APK 中不包含 64 位 so 文件:
> adb install --abi arm64-v8a YOUR_APK_FILE.apk
adb: failed to install YOUR_APK_FILE.apk: Failure [INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries, res=-113]

# 如果你的设备(手机)不支持 64 位架构
> adb install --abi arm64-v8a YOUR_APK_FILE.apk
ABI arm64-v8a not supported on this device

去年上市的手机,大部分都是 64 位架构的,找一款来测试即可。

3.4 分包处理

如果我们的应用只需要在国内分发,当前的策略对我们并不影响,保持原样就好了。但是如果存在国际版,需要上架 Google Play 就一定要重视此次升级。

在 Google Play 上传 APK,是可以根据 CPU 架构上传不同的 APK 的,也就是我们可以针对 32 位上传一个 APK,再上传一个 64 位的 APK。

此时就需要用到 Gradle 的打包技巧了,分别输出几个仅包含对应平台的 APK,以此完成 Google Play 的要求,分别上传 32 位的支持 APK 和 64 位的支持 APK,这样能够 APK 文件不至于增大很多。

  android {   
    ... 
    splits {
        abi {
            enable true
            reset()
            include 'x86', 'x86_64', 'armeabi-v7a', 'arm64-v8a' //select ABIs to build APKs for
            universalApk true //generate an additional APK that contains all the ABIs
        }
    }
    // map for the version code
    project.ext.versionCodes = ['armeabi': 1, 'armeabi-v7a': 2, 'arm64-v8a': 3, 'mips': 5, 'mips64': 6, 'x86': 8, 'x86_64': 9]

    android.applicationVariants.all { variant ->
        // assign different version code for each output
        variant.outputs.each { output ->
            output.versionCodeOverride =
                    project.ext.versionCodes.get(output.getFilter(com.android.build.OutputFile.ABI), 0) * 1000000 + android.defaultConfig.versionCode
        }
    }
 }

这里利用 Gradle 的 splite 配置,有兴趣可以直接查阅文档,就不展开讲了。

四. 小结时刻

在本文中,我们借此次 Google Play 的强制支持 64 位架构的事情,讲解了 Android 下 so 库的一些兼容问题。

如果你在 Google Play 上有应用需要更新,别忘了提前准备需要的 so 库,大多数原生支持的第三方库,在此之前其实都已经提供了对应的 64 位架构。我们只需要在最终日期之前,仔细的进行增加 so 文件,以达到适配的效果。

更新完成之后,别忘了测试,本文就到这里,你有什么更新的见解,欢迎在留言区讨论。

本文对你有帮助吗? 留言、转发、点好看是最大的支持,谢谢!

reference:https://developer.android.com/distribute/best-practices/develop/64-bit

联机圆桌」推荐我的知识星球,一年 50 个优质问题,上桌联机学习。

公众号后台回复成长『 成长』,将会得到我准备的学习资料,也能回复『 加群』,一起学习进步;你还能回复『 提问』,向我发起提问。


相关 [谷歌 app] 推荐:

谷歌Play商店在华被开发者绕过成次要App渠道

- - 行业资讯
  据国外媒体报道,谷歌安卓操作系统的官方APP商店现已改名叫“谷歌Play商店”,而一个移动平台的好坏很大程度取决于APP的规模,但这又需要APP开发者的合作和自律.   但是,目前中国的情况则不太乐观,不管是初创公司还是行业巨头,正在削弱谷歌Play商店的影响力. 实际上,本文所调查的全部中国APP开发者都在自己的网站上提供了下载链接,只有很少的开发者在主页上提供了Play商店的下载链接.

谷歌推出全新Android开发框架Sky让App更流畅

- - 月光博客
  据arstechnica 报道,谷歌推出全新Android开发框架Sky,主要目的包括提高运行速度和响应速度,在大部分设备上,应用流畅的标准都是实现60FPS的帧率,Sky希望实现高达120FPS的帧率,用户界面将保持流畅的响应速度.   目前为止,除游戏之外的Android应用通常使用Java语言来开发编写,其运行效率和速度并不理想,而谷歌内部的一个团队正在探索全新的应用开发方式.

这一次谷歌很强硬,App 再不支持,两个月后将拒绝上架

- - IT瘾-dev
事情是这样的,前几天收到 Google Play 的通知邮件,这才想起来有几款在 Google Play 上架的 App,还没有支持 64 位 CPU 架构. 早在今年一月份,Google 就发布通知,在今年 8 月 1 日开始,上架的 App,除了提供 32 位的版本之外,还需要提供 64 位的版本.

App 和 iCloud

- 笑炊 - 爱范儿 · Beats of Bits
iCloud 的技术细节还在 NDA 的保护下. 但是大家的好奇心不能等到 NDA 失效再满足. 本文基于对 iCloud 的猜测写成,靠谱与否,等待时间检验. 打开浏览器,嗯,今天用 Safari , Chrome , IE 或者 Firefox. 输入 Twiter.com ,啊,不对,是 Twitter.com.

App Internet 革命

- Cary - Mr. Jamie 看網路與創投
Apple 公布最新一季的財報,3 個月賣出了破紀錄的 3,500 萬台 iDevices (iPhone, iPad & iPods). Google 公布最新數字,全球有 1.9 億支 Android 已經被啟用. 大家很興奮「智慧型手機」、「行動裝置」革命終於來到,我卻隱隱感覺到另一件更重大的事情正在發生,我們所熟知的「網路」,即將經歷另一次大幅度的轉變.

浅析App Engine

- - 搜索研发部官方博客
在国内外,云计算正在大步的走向商业化的道路,也得到了越来越多公司的重视. 其中平台即服务(Platform-as-a-Service  PaaS)已经称为业界探讨云计算的热点方式之一,采用PaaS模式来构建应用运行平台App Engine是一种重要的实现方式. 本文主要是对App Engine的背景、特点、需求等进行分析整理,并据此对业界主要的App Engine进行了调研分析.

Mobile App 将死?!

- - Tech2IPO
日前,Mozilla 产品副总监 Jay Sullivan 称移动应用不久即将成为历史,未来将是移动 Web 应用的天下. 光盘好歹还能当杯垫,可怜 Mobile App,难道就这样一下跌落进历史的垃圾堆. Mozilla 的产品副总监杰 • 沙利文 (Jay Sullivan, 上图) 日前表示,移动终端应用(Mobile App)没有未来,真正有前途的是移动 Web 应用(Mobile Web App).

APP已死?

- - 商业不靠谱
APP目前面临的几大窘境将促使搜索引擎由Search向Service、Getting 转变以适应用户在APP时代养成的简洁、高效等习惯. 《未来移动终端应用 C/S Vs B/S 架构》 许永硕——物联网智库. 参照PC软件的发展历程,B/S架构或许是破解APP难题的出路,目前,微信开放平台、手机QQ等在尝试扮演Browser(http://open.weixin.qq.com).

欺诈 app 追杀 — 给 App Store 的信

- Webto - Wangling
感谢 @apple4us 的建议. 我深知如果等着别人相助,此事大概会不了了之,届时只徒留一篇愤概文章. 所谓“追杀”,敌未死,我未停,正如给“动车追尾”事件的受害人追讨公道,公道未到,追讨不止. 于是,我刚给 App Store 发了信,如下:. 每人干掉一个坏蛋…,坏蛋没那么多;每一百个人、每一千个人、甚至每一万个人干掉一个坏蛋,世界都会美好许多.

Web App和Native App 谁将是未来

- - 互联网旁观者
未来是Web App的天下,还是Native App的天下. 作为设计师,我们是应该努力把客户端的体验提升到最优,还是在网页应用层面上做更多的设计. 那么,我们首先应该立体的认识一下Web App和Native App. Web 无需安装,对设备碎片化的适应能力优于App,它只需要通过XHTML、CSS和JavaScript就可以在任意移动浏览器中执行.