Android版本兼容性
Android系统自2008年首次发布以来,经历了多次重大升级,每个版本都有独特的代号和关键特性。
主要版本
| 版本号(API 级别) | 内部代号 | 发布日期 | 关键特性 | 开发适配重点 |
|---|---|---|---|---|
| Android 16(API 35) | Baklava(果仁蜜饼) | 2025-06-10 | 系统级 AI 通知摘要、临时权限、隐私沙箱升级;动态资源调度;折叠屏 / 平板适配强化 | 隐私权限适配、大屏布局优化 |
| Android 15(API 34) | Vanilla Ice Cream(香草冰淇淋) | 2024-10-15 | 部分屏幕共享、卫星消息通信;预测后退手势;敏感通知保护;低光拍摄优化 | 通知权限管控、新手势适配 |
| Android 14(API 34) | Upside Down Cake(倒置蛋糕) | 2023-10-04 | 分区存储强制适配;隐私权限精细化;屏幕兼容性增强;应用启动性能优化 | 分区存储合规、权限弹窗适配 |
| Android 13(API 33) | Tiramisu(提拉米苏) | 2022-08-15 | 应用语言独立设置;通知权限细分;照片选择器隐私增强;Material You 扩展 | 多语言适配、通知渠道精细化 |
| Android 12L(API 32) | Snow Cone v2(刨冰 v2) | 2022-03-07 | 大屏设备(平板 / 折叠屏)UI 优化;任务栏增强;分屏交互升级 | 折叠屏 / 平板布局适配 |
| Android 12(API 31) | Snow Cone(刨冰) | 2021-10-04 | Material You 动态主题;隐私指示器;流畅度提升;折叠屏基础适配 | 主题适配、隐私指示器兼容 |
| Android 11(API 30) | Red Velvet Cake(红丝绒蛋糕) | 2020-09-08 | 对话气泡、通知历史;无线调试;一次性权限;后台位置限制;原生屏幕录制 | 权限申请逻辑、后台定位合规 |
| Android 10(API 29) | Quince Tart(榅桲果塔) | 2019-09-03 | 取消公开甜点代号;强制分区存储;系统深色模式;手势导航;5G / 折叠屏支持 | 分区存储适配、深色模式开发 |
| Android 9.0(API 28) | Pie(馅饼) | 2018-08-06 | 手势导航;自适应电池;AI 亮度;应用操作建议;刘海屏适配 | 刘海屏兼容、手势导航替代物理键 |
| Android 8.1(API 27) | Oreo(奥利奥) | 2017-12-05 | 神经网络 API;壁纸颜色提取;后台执行限制强化 | 后台任务适配、耗电优化 |
| Android 8.0(API 26) | Oreo(奥利奥) | 2017-08-21 | 画中画;通知渠道;Project Treble 模块化;自动填充框架 | 通知渠道配置、画中画功能适配 |
| Android 7.1(API 25) | Nougat(牛轧糖) | 2016-10-04 | 应用快捷方式;夜间模式;图片键盘;指纹 API 增强 | 快捷方式开发、指纹识别兼容 |
| Android 7.0(API 24) | Nougat(牛轧糖) | 2016-08-22 | 分屏多任务;快速设置面板;Doze 低功耗;JIT 编译增强 | 分屏适配、低功耗策略兼容 |
| Android 6.0(API 23) | Marshmallow(棉花糖) | 2015-10-05 | 运行时权限;指纹识别;Doze 省电模式;应用待机分组 | 运行时权限重构、指纹 API 接入 |
| Android 5.1(API 22) | Lollipop(棒棒糖) | 2015-03-09 | 双卡双待支持;高清语音;设备保护增强 | 双卡适配、通话功能兼容 |
| Android 5.0(API 21) | Lollipop(棒棒糖) | 2014-11-03 | Material Design;ART 虚拟机;64 位支持;电池省电模式 | MD 设计适配、64 位编译兼容 |
| Android 4.4W(API 20) | KitKat(奇巧巧克力) | 2013-12-05 | 穿戴设备适配;蓝牙低功耗(BLE);沉浸式通知 | 穿戴设备交互适配 |
| Android 4.4(API 19) | KitKat(奇巧巧克力) | 2013-10-31 | 沉浸模式;ART 预览;低内存优化;存储访问框架 | 沉浸栏适配、低内存设备兼容 |
| Android 4.3(API 18) | Jelly Bean(果冻豆) | 2013-07-24 | OpenGL ES 3.0;蓝牙 4.0;用户配置文件 | 图形渲染优化、蓝牙适配 |
| Android 4.2(API 17) | Jelly Bean(果冻豆) | 2012-11-13 | 多用户支持;Daydream;无线显示;键盘手势 | 多用户权限管控、投屏适配 |
| Android 4.1(API 16) | Jelly Bean(果冻豆) | 2012-07-09 | Project Butter 流畅度提升;Google Now;通知快捷操作 | 流畅度优化、通知交互适配 |
| Android 4.0.3(API 15) | Ice Cream Sandwich(冰淇淋三明治) | 2011-12-16 | 漏洞修复;相机优化;NFC 增强 | 基础兼容性适配 |
| Android 4.0(API 14) | Ice Cream Sandwich(冰淇淋三明治) | 2011-10-19 | 统一手机 / 平板 UI;面部解锁;虚拟按键;原生截图 | UI 统一适配、虚拟按键兼容 |
| Android 3.2(API 13) | Honeycomb(蜂巢) | 2011-07-15 | 屏幕尺寸适配 API;变焦手势;应用安装位置选择 | 平板屏幕适配、安装路径兼容 |
| Android 3.1(API 12) | Honeycomb(蜂巢) | 2011-05-10 | USB 配件支持;多任务改进;拖拽操作增强 | 外设适配、多任务交互优化 |
| Android 3.0(API 11) | Honeycomb(蜂巢) | 2011-02-22 | 专为平板设计;全息 UI;多任务栏;系统栏 | 平板专属 UI 开发、多任务适配 |
| Android 2.3.3(API 10) | Gingerbread(姜饼) | 2011-02-09 | 性能优化;蓝牙修复;NFC API 完善 | 低版本兼容性适配 |
| Android 2.3(API 9) | Gingerbread(姜饼) | 2010-12-06 | 原生支持 NFC;前置摄像头支持;一键热点;改进键盘与电源管理 | NFC 功能适配、低功耗优化 |
| Android 2.2(API 8) | Froyo(冻酸奶) | 2010-05-20 | 应用安装到 SD 卡;WiFi 热点;JIT 编译;Flash 支持 | 应用存储路径适配、性能优化 |
| Android 1.6(API 4) | Donut(甜甜圈) | 2009-09-15 | 屏幕分辨率适配;手势输入;语音搜索增强;相机 / 视频优化 | 多分辨率适配、语音功能兼容 |
| Android 1.5(API 3) | Cupcake(杯子蛋糕) | 2009-04-27 | 虚拟键盘;视频录制;相册应用;Widget 桌面组件 | 基础 UI 组件适配、Widget 开发 |
| Android 1.1(API 2) | Petit Four(花色小蛋糕) | 2009-02-09 | Bug 修复; 电话免提优化; 邮件附件预览 | 基础功能兼容性适配 |
| Android 1.0(API 1) | 无 | 2008-09-23 | 首个正式版; 基础通话 / 短信; 浏览器; 地图等核心应用 | 初代系统适配(极少场景需兼容) |
从Android P(Pie)开始,Google放弃了使用甜品名称的传统命名方式,改为直接使用数字命名,同时加深了logo的颜色。这种变化反映了Android系统正逐步走向成熟,更加注重用户体验和技术革新。
版本分布情况
2025年10月1日
- minSdkVersion:优先设为 API 31(Android 12),覆盖约 84% 用户;若需兼顾下沉市场,可降至 API 23(Android 6.0),覆盖约 98% 用户。
- targetSdkVersion:建议设为 API 35(Android 15),以支持最新系统特性与合规要求。
2023年11月
继Android版本发展历程之后,我们来看看当前市场上的版本分布情况。截至2023年11月, Android 13以22.4%的市场份额领先 ,紧随其后的是Android 11(21.6%)和Android 12(15.8%)。值得注意的是,尽管Android生态系统持续发展,但 碎片化问题仍然存在 :从Android 4.4到Android 13,用户设备覆盖了13个不同的版本号。
这种广泛的版本分布对开发者提出了挑战,需要采取有效的跨版本兼容策略,以确保应用程序能够在各种Android环境中正常运行。
版本众多的挑战
Android平台因其开放性和多样性,在市场上催生了海量的设备型号与系统版本。
每一版本的迭代都伴随着新功能的引入和API的更新,这为开发者提供了广阔的创新空间与丰富的资源支持。
这种快速的演进同样带来了显著的多版本兼容问题,使得确保应用在各异Android系统中的稳定运行成为一项艰巨任务。
这种挑战首先体现在不同版本间的功能差异上。
新版本的Android系统往往会引入新的特性和API,而旧版本则可能不支持这些新功能。
这就要求开发者在设计和开发应用时,必须充分考虑到不同版本间的差异,以确保应用的兼容性和用户体验的一致性。
例如,某些新特性在最新版本中得到了优化和支持,但在旧版本中却可能存在缺陷或根本无法使用,这就需要开发者进行细致的版本适配工作。
设备型号的多样性也是导致兼容性问题复杂化的重要因素。
由于Android平台的开放性,众多厂商都推出了基于Android系统的设备,这些设备在硬件配置、屏幕尺寸、分辨率等方面存在显著差异。
这种硬件上的多样性要求开发者在开发过程中必须考虑到各种设备的适配问题,以确保应用能够在不同设备上正常运行并呈现出良好的用户界面。
不同版本的Android系统在安全性、权限管理等方面也存在差异。随着Android版本的更新,系统对于安全性和隐私保护的重视程度不断提升,这导致新版本的系统在权限管理、数据加密等方面可能采取了更为严格的措施。
这就要求开发者在开发应用时,必须遵守各个版本的安全规范,确保应用的数据安全和用户隐私的保障。
面对这些挑战,Android开发者需要采取一系列措施来应对多版本兼容性问题。
首先,开发者需要密切关注Android系统的更新动态,及时了解新版本引入的新特性和API变化,以便在应用中进行相应的适配和调整。
其次,开发者需要充分利用Android官方提供的兼容性测试工具和资源,对应用进行全面的兼容性测试,发现并解决潜在的兼容性问题。
最后,开发者还需要与用户保持密切的沟通,及时了解并反馈用户在使用过程中遇到的问题,以便对应用进行持续改进和优化。
Android版本众多带来的挑战不容忽视。
作为Android开发者,必须充分认识到多版本兼容性问题的重要性,并采取切实有效的措施来应对这些挑战,以确保应用能够在不同版本的Android系统中稳定运行并提供优质的用户体验。
版本更新的应对策略
随着Android系统的持续演进,开发者面临着不断变化的API和功能环境。新版本的推出往往伴随着新的特性和性能优化,但同时也可能意味着部分旧有API的废弃或调整。这种动态变化对开发者提出了严峻的挑战,要求他们不仅需时刻关注系统的更新动态,更要确保应用能够在不同版本间维持稳定的兼容性。
为了有效应对这些挑战,开发者应采取一系列策略。首要之务是定期查阅Android官方文档,了解新版本的API变更和废弃情况。这包括新功能的引入、性能提升的方法,以及可能影响到现有应用运行的修改。通过及时掌握这些信息,开发者可以在新版本发布前就对应用进行相应的调整和优化,从而确保用户能够在新系统上获得无缝的体验。
除了对官方文档的持续关注外,开发者还需要建立一套完善的版本管理机制。这意味着在开发过程中应明确标识和跟踪应用的各个版本,以便在必要时能够快速定位和解决兼容性问题。此外,通过自动化测试工具进行定期的兼容性测试也是至关重要的。这些测试可以覆盖不同版本的Android系统和设备,从而帮助开发者发现并解决可能存在的兼容性问题。
在应用更新方面,开发者应遵循敏捷开发的原则,及时响应系统的更新并发布新版本的应用。这不仅可以确保用户能够充分利用新系统的特性,还有助于维护应用的稳定性和安全性。同时,通过用户反馈和数据分析,开发者可以持续优化应用在不同版本系统上的表现,进一步提升用户体验。
面对Android系统的碎片化问题,即市场上存在大量不同版本和定制化的Android系统,开发者需要格外注意兼容性的处理。这包括但不限于对不同屏幕尺寸和分辨率的适配、对不同系统特性的支持,以及对不同品牌设备可能存在的定制API的兼容。通过综合运用上述策略,开发者可以最大限度地减少因版本更新带来的兼容性问题,从而确保应用能够在广泛的Android设备上稳定运行。
设置版本参数
在Android开发中,确保应用能够在不同版本的Android系统上稳定运行是至关重要的。
为了实现这一目标,开发者需要在项目配置中明确设置minSdkVersion和targetSdkVersion两个关键参数。
这两个参数对于控制应用的兼容性和性能具有决定性的影响。
使用minSdkVersion和targetSdkVersion
在build.gradle文件中,设置minSdkVersion和targetSdkVersion非常重要:
minSdkVersion:指定应用能支持的最低Android版本。targetSdkVersion:指定应用的目标版本,通常设为最新版本,以利用新功能并遵循最新的行为规范。
示例:
android {
compileSdkVersion 33
defaultConfig {
applicationId "com.example.app"
minSdkVersion 21 // 支持Android 5.0及以上
targetSdkVersion 33 // 针对最新版本
versionCode 1
versionName "1.0"
}
}
minSdkVersion
在Android应用开发中,minSdkVersion是一个至关重要的构建参数,它定义了应用支持的 最低Android API级别 。通过合理设置minSdkVersion,开发者可以在保证应用兼容性的同时,充分利用新版本系统的特性和性能提升。
minSdkVersion的主要作用包括:
- 指定最低兼容版本 :设置应用能够运行的最低Android版本,确保应用在较旧设备上也能正常工作。
- 影响应用分发范围 :Google Play商店会根据minSdkVersion过滤不符合要求的设备,提高应用的安装成功率。
- 简化开发流程 :允许开发者专注于支持的版本范围内的功能和API,减少不必要的兼容性处理。
设置minSdkVersion时,开发者需要权衡多个因素:
- 市场占有率 :考虑目标用户群体的设备分布情况
- 功能需求 :评估应用所需的新API和特性
- 性能优化 :利用新版本系统提供的性能改进
然而,过高的minSdkVersion可能导致应用失去部分潜在用户。因此,在设置时应谨慎考虑应用的核心功能和目标受众。
minSdkVersion对应用兼容性有显著影响:
- 限制安装范围 :较低的minSdkVersion使应用能在更多设备上安装,但可能需要额外的兼容性处理。
- 影响应用行为 :Android系统会根据minSdkVersion调整应用的行为,特别是在涉及新API的情况下。
- 触发兼容性模式 :当设备API级别低于minSdkVersion时,系统可能阻止应用安装或启动。
为了平衡兼容性和创新,开发者通常采用以下策略:
- 将minSdkVersion设置为相对较低的版本,确保广泛兼容性。
- 使用条件语句和资源限定符,根据不同API级别提供定制化的体验。
- 利用AndroidX等兼容性库,简化跨版本开发过程。
通过合理设置minSdkVersion,开发者可以在保证应用兼容性的前提下,充分利用新版本Android系统的优势,为用户提供最佳的体验。
targetSdkVersion
在Android应用开发中,targetSdkVersion是一个关键的构建参数,它决定了应用的行为和兼容性策略。这个参数告诉Android系统应用所针对的目标API级别,从而影响系统如何处理应用的兼容性。
targetSdkVersion的主要作用包括:
- 控制应用行为 :系统根据targetSdkVersion决定是否启用兼容性行为。
- 影响API使用 :高targetSdkVersion允许使用新API,但实际运行时行为受限。
- 触发新特性 :更新targetSdkVersion可激活新系统特性和行为。
选择合适的targetSdkVersion需要权衡多个因素:
- 功能需求 :评估应用是否依赖新版本的特定API或特性。
- 用户群体 :考虑目标用户设备的版本分布。
- 开发周期 :评估更新带来的测试和调试工作量。
targetSdkVersion对应用行为有显著影响:
- API行为差异 :以AlarmManager为例,set()方法在不同targetSdkVersion下表现不同。
- 权限管理变化 :如Android 6.0引入的运行时权限机制。
- 性能优化差异 :新版本系统可能提供性能改进,但需targetSdkVersion匹配才能生效。
为了平衡兼容性和创新,开发者通常采用以下策略:
- 将targetSdkVersion设置为相对较高的版本,以利用新特性并保持兼容性。
- 使用条件语句和资源限定符,根据不同API级别提供定制化的体验。
- 利用AndroidX等兼容性库,简化跨版本开发过程。
通过合理设置targetSdkVersion,开发者可以在保证应用兼容性的前提下,充分利用新版本Android系统的优势,为用户提供最佳的体验。
compileSdkVersion
在Android应用开发中,compileSdkVersion是一个关键的构建参数,它决定了应用的编译环境和可用API集。这个参数指定了Gradle用来编译应用的Android API级别,直接影响了开发者可以访问的API集合。
compileSdkVersion的主要作用包括:
- 确定可用API集 :指定应用可以使用的最高API级别。
- 影响编译环境 :控制编译过程中的语法检查和类型安全。
- 促进新特性预览 :允许开发者提前了解和测试新版本API。
设置compileSdkVersion时,开发者通常会选择最新的API级别,以便:
- 访问最新的API和特性
- 获取最新的编译优化
- 准备未来版本的迁移
然而,compileSdkVersion的选择需要权衡多个因素:
- 兼容性 :过高可能导致与低版本系统不兼容
- 功能性 :过低可能无法使用新特性
- 安全性 :新版本可能包含安全修复
compileSdkVersion与其他SDK版本参数的关系密切:
| 参数 | 含义 | 关系 |
|---|---|---|
| minSdkVersion | 应用支持的最低API级别 | 通常低于或等于compileSdkVersion |
| targetSdkVersion | 控制应用运行时行为的API级别 | 影响compileSdkVersion的实际效果 |
为了最大化应用潜力,开发者通常遵循以下原则:
minSdkVersion <= targetSdkVersion = compileSdkVersion
这种配置既能保证应用的广泛兼容性,又能充分利用新版本系统的特性和性能优势。通过合理设置compileSdkVersion,开发者可以在保证兼容性的同时,为应用注入最新的功能和性能优化。
使用兼容性库
在Android应用开发中,兼容性一直是开发者面临的重要挑战。为了应对不同版本系统间的差异,Google推出了一系列兼容性库,其中最具代表性的是AndroidX和之前的Support Library。这些库为开发者提供了强大的工具,使应用能够在各种Android版本上保持一致的功能和用户体验。
AndroidX是一个现代化的、模块化的库集合,旨在帮助开发者编写能够跨多个Android版本运行的应用。它不仅是对原有Support Library的升级,更是Android开发生态系统的基石。AndroidX的核心特点包括:
- 统一的命名空间 :所有的类和接口都放在androidx.*包下,这不仅提高了代码的可读性,也有助于区分系统自带的API和扩展库的功能。
- 模块化设计 :AndroidX采用了模块化的设计理念,将不同的功能划分为多个独立的子库。这种设计允许开发者根据项目需求选择性地引入所需的模块,从而减小程序的体积和依赖关系的复杂性。
- 持续更新和支持 :与Support Library相比,AndroidX得到了更频繁的更新和更长久的支持。这意味着开发者可以期待更多的新功能和性能改进,同时也能获得及时的安全补丁和bug修复。
迁移到AndroidX的过程虽然可能有些繁琐,但却是值得的。以下是一些迁移的关键步骤:
- 更新Android Studio :确保使用最新版本的Android Studio,它提供了强大的迁移工具。
- 启用AndroidX支持 :在gradle.properties文件中添加以下配置:
android.useAndroidX=true
android.enableJetifier=true
- 使用Android Studio的迁移工具 :通过Refactor > Migrate to AndroidX菜单项启动迁移过程。这个工具会自动更新项目依赖、修改代码中的包名引用,并处理大部分的迁移工作。
- 清理和修复 :迁移完成后,仔细检查并修复可能出现的问题。重点关注编译错误、警告和潜在的运行时错误。
- 更新混淆规则 :如果项目使用ProGuard或其他混淆工具,需要更新混淆规则以适应AndroidX的类名变化。
通过使用AndroidX,开发者可以显著提高应用的跨版本兼容性,同时也能享受到最新的Android特性和性能优化。虽然迁移过程可能需要一些时间和精力,但从长远来看,这将为应用的质量和可持续性奠定坚实的基础。
版本检查与条件执行
在Android应用开发中,版本检查与条件执行是一种常用的跨版本兼容性策略。这种方法允许开发者根据设备的Android版本动态调整应用的行为,确保在不同版本的系统上都能提供一致的用户体验。
Android系统提供了一个名为 Build.VERSION.SDK_INT 的全局变量,它返回当前设备的API级别。这个变量是进行版本检查的核心依据。开发者可以使用这个变量来判断当前设备的Android版本,并据此执行不同的代码路径。
以下是一个典型的版本检查示例:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
// 执行Android 5.0及以上版本的逻辑
} else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
// 执行Android 4.4及以上版本的逻辑
} else {
// 执行更低版本的逻辑
}
在这个例子中,我们使用了 Build.VERSION_CODES 类中的常量来表示不同的Android版本号。这种方法的好处在于代码更具可读性,而且便于维护。
在进行版本检查时,开发者需要注意以下几点:
- 从高版本到低版本 :按照从高版本到低版本的顺序进行检查,这样可以确保应用在新版本系统中能充分利用新特性,同时保持向下兼容。
- 避免过于频繁的检查 :过多的版本检查可能会降低代码的可读性和可维护性。建议只在关键的地方进行检查,如初始化或调用特定API时。
- 使用AndroidX等兼容性库 :对于一些常见的API差异,可以考虑使用AndroidX库来简化版本检查的逻辑。这些库通常已经处理了不同版本之间的差异,可以减少代码的复杂度。
- 考虑使用switch-case结构 :对于需要处理多个版本的情况,可以考虑使用switch-case结构来代替多重if-else,这样可以使代码更加清晰。
switch (Build.VERSION.SDK_INT) {
case Build.VERSION_CODES.LOLLIPOP:
// 执行Android 5.0特有的逻辑
break;
case Build.VERSION_CODES.KITKAT:
// 执行Android 4.4特有的逻辑
break;
default:
// 执行通用逻辑
break;
}
通过合理运用版本检查与条件执行策略,开发者可以在保证应用兼容性的同时,充分利用新版本Android系统提供的特性和性能优化。这种方法不仅能够提高应用的稳定性和性能,还能为用户提供更好的体验。
资源限定符
在Android应用开发中,资源限定符是一种强大的工具,用于实现跨版本的界面和功能适配。通过在资源目录中使用特定的限定符,开发者可以根据设备的硬件特征和系统版本提供定制化的资源。例如,使用layout-sw600dp目录可以为平板设备提供专门的布局,而values-v21目录则可用于放置针对Android 5.0及以上版本的资源。
这种方法不仅简化了适配过程,还能确保应用在不同设备和系统版本上呈现最佳用户体验。资源限定符支持多种组合,如屏幕尺寸、密度、方向和语言等,为开发者提供了灵活的适配策略。
多设备测试
在Android应用开发中,多设备测试是确保应用兼容性和质量的关键环节。为了有效覆盖不同Android版本的设备,开发者可以采用以下策略:
- 使用Android Studio的AVD Manager :创建和管理虚拟设备,模拟各种Android版本和硬件配置。
- 利用Google Cloud Test Lab :进行大规模远程测试,涵盖广泛的真实设备和系统版本。
- 采用MonkeyRunner工具 :进行自动化测试,特别适合多设备并行测试场景。
- 重点关注Top100-300热门机型 :确保应用在主流设备上表现良好。
通过综合运用这些工具和策略,开发者可以高效地完成多设备测试,提高应用的兼容性和用户体验。
兼容性报告
在Android应用开发中,兼容性问题是不可避免的挑战。Google Play控制台的兼容性报告为此提供了强大支持。通过分析报告中的设备崩溃率和应用停止率,开发者可以快速定位问题设备型号和Android版本。结合用户反馈和日志,这些数据有助于诊断和修复导致兼容性问题的根本原因。定期审查兼容性报告不仅有助于提高应用质量,还能为未来的版本规划提供有价值的数据支持,确保应用在多样化的Android生态系统中保持良好表现。
渐进式发布
在Android应用开发中,渐进式发布是一种有效控制版本更新风险的策略。通过Google Play的分阶段发布功能,开发者可以 逐步扩大新版本的覆盖范围 ,从少量用户开始收集反馈和监控性能,然后根据实际情况决定是否继续推广或回滚。
这种方法允许开发者在不影响大部分用户的情况下,快速识别和修复潜在问题,从而提高应用质量和用户满意度。例如,可以从5%的用户群开始部署新版本,观察关键指标后再决定是否扩大推送范围。
ADT
2015年6,google不再支持Eclipse ADT插件