获取Android机型设备信息时,竟然也会遇到适配差异问题.docVIP

获取Android机型设备信息时，竟然也会遇到适配差异问题 文/腾讯优测 吴宇焕 作为一名Android开发者，当你需要将产品在某品牌的某机型上进行兼容性适配的时候，最基础的适配方法就是通过代码层面区分适配机型来为程序进行针对性的改变程序执行流向。 1、Build类包含的信息 Android Build类可以从系统属性中提取设备硬件和版本信息，主要功能： 属性 说明 Build.BOARD 主板 Build.BOOTLOADER 系统启动程序版本号 Build.BRAND 系统定制商 Build.CPU_ABI cpu指令集 目前已经被SUPPORTED_ABIS属性取代 Build.CPU_ABI2 cpu指令集2 目前已经被SUPPORTED_ABIS属性取代 Build.DEVICE 设备名称 Build.DISPLAY 表示向用户展示的标志字符串 Build.getRadioVersion() 无线电固件版本 Build.FINGERPRINT 一个设备信息字符串（品牌+名字+设备+android版本+增量....） Build.HARDWARE 硬件名称 Build.HOST HOST Build.ID 修订版本列表 Build.MANUFACTURER 硬件制造商 Build.MODEL 手机型号 Build.SERIAL 硬件序列号 Build.PRODUCT 产品名称 主要读取的是手机系统\system\build.prop（Galaxy Nexus为例） 2、Build工作原理 （1）Build类：记录一系列静态属性 厂商/品牌/机型/主板型号/CPU指令集 Build类的记录的设备信息主要是调用SystemProperties类的get()方法，SystemProperties的实现主要由JNI接口实现。 android.os.SystemProperties此类未开放(未提供给SDK API)，能够在frameworks和android自带的APP里使用(比如Settings app里)，不能被其他app直接使用，只能通过Build等类来使用。 （2）SystemProperties：系统属性 相当于windows的注册表，由key和value组成，且都是核心系统的一个基本机制。 Android 的系统属性包括两部分：文件保存的持久属性和每次开机导入的cache属性。前者主要保存在下面几个文件中（目录下），后者则通过API方式使用。 3、部分已知适配问题 由于Android系统的开放性，各大OEM厂商会以Android为基础为手机开发自己的ROM，上面的程序片段通过判断厂商和机型的方式来进行代码层面的适配，理论上这里不会有问题发生，但实际上获取厂商信息和机型信息的时候会出现你想像不到情况发生： 情况一：厂商信息获取不唯一 摩托罗拉的厂商信息不仅是motorola还有mot和FIH； 索爱的厂商信息不仅是Sony还有Sony Ericsson； HTC的厂商信息不仅是HTC还有HUN； OPPO的厂商信息不仅是OPPO还有alps； 酷派的厂商信息不仅是CoolPad还有YuLong; 情况二：机型信息获取比较奇葩 红米model值为数字，model值为“2013022”的奇葩字符串。 情况三：厂商信息或机型信息获取为unknown 联想A60获取厂商信息为unknown；造成这种问题的原因是厂商随意改动framework层导致的。 适配建议 根据以上情况希望可以为Android开发者同学在适配工作中提供一定的借鉴和帮助。 我们给出的第一种解决方案是“规避已知问题” 例如，厂商信息不唯一时，我们就搜罗该厂商信息的所有可能，从而进行准确的判断，如下： 当获取机型信息为unknown时，我们还可以通过手机设备的其他信息来判断手机具体机型，如下： 第二种解决方案，也是最理想的解决方案“设备数据匹配” 大家都知道，从android.os.build类中，我们可以获取到很多设备的信息，既然一个机型的设备是一样的，我们可以统计所有机型的设备信息得到一个数据库，当机型获取为unknown时，通过已知信息匹配，得到达到一定匹配率的机型（90%或者更高），就可以认为匹配成功。 腾讯优测是优质的云测试平台，多年来致力于解决适配问题，选择优测也是明智的选择。将上述功能封装成一个构件，可以为开发者提供更多的便利。