你要知道的N个Android适配问题
作者简介：
李忠丞 沈阳大学学士，腾讯优测产品支撑组组长；2011年加入腾讯，专注移动终端开发，先后参与过腾讯微博研发以及手机QQ浏览器、Qzone、魅拍等产品的机型适配工作。
一、我们服务过的海量优秀产品
二、个性化十足的Launcher
快捷方式虽然看起来只是一个很小的功能点，但是他涉及到的机型适配问题很多。
快捷方式创建代码：
ntent addShortCut = new Intent("com.android.launcher.action.INSTALL_SHORTCUT");
addShortCut.putExtra(Intent.EXTRA_SHORTCUT_NAME, title)；
// 不允许重复创建
addShortCut.putExtra("duplicate", false);
addShortCut.putExtra(Intent.EXTRA_SHORTCUT_ICON_RESOURCE, icon);
addShortCut.putExtra(Intent.EXTRA_SHORTCUT_INTENT, intent);
sendBroadcast(addShortCut);1 无法创建快捷方式
越来越多的手机厂商取消了快捷方式的概念，导致我们无法通过代码创建一个我们需要的快捷方式，根据我们所掌握的数据显示，这样的手机约占 13%。
2 重复创建快捷方式
通常情况下，我们是不希望自己的快捷方式被重复创建：
使用 addShortCut.putExtra(“duplicate”, false);方法就能达到目的，但是市面上的手机至少有 8%的手机即使设置了 DUPLICATE 为 FALSE 还是可以重复创建快捷方式的。
代表手机品牌为：华为 中兴 HTC
Android Launcher 源码：
2.1 重复创建快捷方式的解决方案 V1.X
我们最早使用的解决快捷方式重复创建的方法是：在创建快捷方式前先执行删除操作，这种方式其实很聪明，因为即使是在快捷方式不存在的情况下执行删除操作也不会有任何异常，这样看来问题解决地太轻松了，但是遗憾的是删除快捷方式同样存在适配问题，我们掌握的数据显示大约 21%的手机无法正常删除快捷方式。
另外一种方法是：自行保存快捷方式的创建记录，通过一个字段来记录快捷方式是否已经创建过了，以此来决定是否创建新的快捷方式，这种做法也是因为出现快捷方式无法删除情况后对解决方案进行了一个小的升级，虽然可以解决问题，但是如果程序被清除了数据，那么一切都乱了，还是无法彻底的规避重复的问题。
2.2 重复创建快捷方式的解决方案 V2.X
遇到难解的问题还是看看源码吧，Android 的 Launcher 源码在创建快捷方式的时候不仅会判断 duplicate 的值，还会在数据库中查询一下将要被创建的快捷方式是否已经存在，我们也照做就 OK 了。
我们注意到，查询数据库的时候访问地址URI 是一个很重要的因素，问题是数据库的URI比较多，Android 标准的URI 就有3 个：
2.2 版本以前的URI 是：content://com.android.launcher.settings/favorites?notify=true
2.2~4.3 版本的URI 是：content://com.android.launcher2.settings/favorites?notify=true
4.4 版本以上的目前都是：content://com.android.launcher3.settings/favorites？notify=true
不仅仅Android 自己的Launcher 数据库地址众多，厂商自己定义的地址就更加丰富多彩，如OPPO R827T 的访问URI 为：content://com.oppo.launcher.settings /favorites?notify=true
HTC Z715e 的访问地址为：
content://com.htc.launcher.settings/favorites?notify=true
远远不止这些，还有不计其数的第三方Launcher 应用，很多开发者也会修改数据库访问地址，目前仅我们掌握的不同访问地址就有多达40 种左右。
通过权限查询URI：
通过数据库的读写权限来查询对应的URI 相信大家也不陌生，感觉上像是找到了终极的解决方案，且看下去…
问题一：如果使用完整的权限进行查询—权限众多，我们目前掌握的超过 50 种。
问题二：如果使用不完整的权限进行查询（READ_SETTINGS）对应关系复杂，大约有 32%的手机会对应两个以上的 URI。
例如：
GT-I8262D：
authority:com.sec.android.app.launcher.settings
ReadPermission:com.android.launcher.permission.READ_SETTINGS
authority:com.sec.android.app.launcher.settings.id
ReadPermission:com.android.launcher.permission.READ_SETTINGSLenovo A278t：
authority:com.aspire.mm.Settings ReadPermission:com.aspire.mm.permission.READ_SETTINGS
authority:com.huaqin.launcherEx.settings
ReadPermission:com.huaqin.launcherEx.permission.READ_SETTINGS
authority:com.huaqin.thememgr.Settings
ReadPermission:com.huaqin.thememgr.permission.READ_SETTINGS
三、多姿多彩的 Camera
1 Intent 调用手机内相机程序
如果我们设置了照片的存储路径，那么很可能会遇到一下三种问题：
问题一：onActivityResult 方法中的data 返回为空（数据表明，93%的机型的data 将会是Null，所以如果我们指定了路径，就不要使用data 来获取照片，起码在使用前要做空判断）
问题二：照片无法存储
如果自定义存储路径是/mnt/sdcard/lowry/，而手机SD 卡下在拍照前没有名为lowry 的文件夹，那么部分手机拍照后图片不会保存，导致我们无法获得照片，大多数手机的相机遇到文件夹不存在的情况都会自己创建出不存在的文件夹，而个别手机却不会创建，其代表机型为：三星I8258、华为H30-T00、红米等。解决的方法就是在指定存储路径前先判断路径中的文件夹是否都存在，不存在先创建再调用相机。
问题三：照片可以存储，但是名字不对
file:///mnt/sdcard/123 1.jpg，由于Uri 的fromFile 方法会将路径中的空格用“%20”取代。其实对于大多数的手机这都不算事，手机在解析存储路径的时候都会将“%20”替换为空格，这样实际上最终的照片名字还是我们当初指定的名字：123 1.jpg，遗憾的是个别手机（如酷派7260）系统自带的相机没有将“%20”读成空格，拍照后的照片的名字是123%201.jpg，我们用路径“file:///mnt/sdcard/123 1.jpg”能找到照片才怪！！
总结：
（1）使用 onActivityResult 中的 intent(data)前要做空判断。
（2）指定拍照路径时，先检查路径中的文件夹是否都存在，不存在时先创建文件夹再调用相机拍照。
（3）指定拍照存储路径时，照片的命名中不要包含空格等特殊符号。
2 通过 Camera 的 open 方法调用手机摄像头
2.1 连续自动对焦 crash
原因：第一次对焦未结束，应用层又发起的第二次对焦，引起对焦失败。
解决方案一：传入 AutoFocusCallback
解决方案二：延时操作
解决方案三：异常捕获
2.2 摄像头个数判断错误
现象：当我们使用 Camera.getNumberOfCameras()方法检测摄像头数量时返回的结果不准确，如果我们尝试打开一个不存在的摄像头肯定会抛出异常，这也提醒我们在开启 Camera 摄像头时需要加异常保护。
代表机型：联想 278t 酷派 8022
2.3 闪光灯的判断
我们常用的判断手机是否有闪光灯的方法应该有以下两种：
判断是否支持闪光灯方法一：使用getSupportedFlashModes 方法
判断是否支持闪光灯方法二：通过PackageManager 判断
方法一有 3.7%的机器结果错误，无法准确地判断出手机是否有闪光灯，主要的品牌包含：酷派、天语、联想、三星等。
方法二有 9.7%的机器结果错误，主要品牌包含：VIVO、金立、酷派、天语、朵唯、三星等。我们建议在判断手机是否有闪光灯的时候将这两种方法联合使用，出现错误的概率将大大降低。
2.4 常亮状态与其他状态间的切换
前提条件是我们设置闪光灯为常亮（Parameters.FLASH_MODE_TORCH），并且闪光灯成功常亮，此时我们在设置闪光灯模式为 Parameters.FLASH_MODE_AUTO 后闪光灯依然常亮，这样的机型约占热门机型的12% ，遇到这种情况我们需要先设置闪光灯模式为Parameters.FLASH_MODE_OFF 关闭闪光灯后再设置其他模式。
2.5 释放 Camera 后闪光灯依旧闪亮
既然开了，我们就要负责关，说实话，以前这个问题根本不在我的考虑范内，因为我们在使用 Camera 的时候都会在Activity 被销毁或者暂停时释放 Camera，这个时候无论闪光灯是什么状态，都会随着 Camera 的释放而关闭，直到我遇见了 OPPO R815T，我的世界观发生了变化，这货如果设置了闪光灯常亮，即使释放了 Camera 闪光灯依旧稳稳地亮着，而且由于Camera 被释放掉了，你再也没办法关闭闪光灯了，关闭 App、卸载 App，你还是扣电池关机吧…..所以，如果你的程序中有设置闪光灯为常亮状态的操作，建议在释放 Camera 前先将闪光灯设置为关闭（Parameters.FLASH_MODE_OFF）状态。
2.6 CameraInfo 的另类情况
官方文档中有关于调整相机预览角度的例子
在这个例子中CameraInfo 非常重要，最终的角度计算就是根据CameraInfo 中orientation 值得到的，所以如果这个值不准确的话那么我们的角度就有可能出现错误。
VIVO V1 手机第一次我们获取CameraInfo 的orientation 值是90，而当执行了mCamera =Camera.open();之后再获取CameraInfo 的orientation 值就是0，而且以后获取的都是0 ，除非重启手机。
无论是这款手机上的哪个应用，只要执行了一次Camera.open()之后，其他所有程序中获取CameraInfo 的orientation 都是是0。
机自带的相机却能很好的使用反编译系统相机后果然发现系统相机并没有像官方给出的例子来进行角度的矫正。
解决方案：
- 按照此手机系统相机的做；
- 对该手机CameraInfo 的orientation 值写死为90。
四、不止是2 的双卡
双卡的问题解决的基本思路：
1.推断：手机内置的系统APP 都可以正常使用这些功能，因此肯定存在厂商自定义API 来实现这些功能；
2.反编译：Framework、系统APP、系统数据库；
3.定位：TelephoneManager 扩展、SMSManager 扩展、电话服务扩展、短信服务扩展、数据
库字段扩展。
五、UI适配
说到UI 适配其实很是让人头疼，下面的图片是某个产品为了进行UI 适配所做的工作，可以看出相当繁琐。
除了分辨率的适配，有时候布局文件中的某个标签还会引起一些问题，我们先看下面一段布局代码：
正确结果：
错误结果：
这就是因为Android3.0 一下版本在FrameLayout 中使用layout_marginTo 标签必须要设置gravity 才能生效。
那么如果解决这个问题呢：
在设置android:layout_marginTop 的组件中再设置一下android:layout_gravity=”top”
六、还有更奇葩的
1 厂商的抽象方法
如果你需要实现InputConnection 接口，那么你一定要注意下面这个很奇葩的异常：
反编译了下此款手机的framework，发现厂商在InputConnection 接口中增加了一个抽象方法performYLPrivateCommand
2 距离传感器
2.1 不同手机event.values[0]值简直是千变万化
简单说几个有代表性的：
- 一部分手机比较正常，靠近时为0 远离时为1（0，1），么么哒~；
- 有点小个性的手机数值将变大，比如（0，100），（3，5），（3，100）等等；
- 213 手机的数值就比较莫名其妙，（1.001，5.003），你是表明精确度高呗？？
2.2 数值与远近关系不统一
既然我们是通过数值来判断当前是否出于近耳状态，那么是不是应该这个数值的大小是有说道的，靠近时的数值小一点，远离时的数值大一些，起码我见过的99%的手机是这样子的，但是就有几款神经病手机（100W）偏偏是靠近时的数值比远离时的数值大，这是个坑，开发者要注意~~！！
2.3 getMaximumRange 方法返回值不对
有一句API：
SensorManager.getDefaultSensor(Sensor.TYPE_PROXIMITY).getMaximumRange()文档解释这个应该获取的是传感器数值变化的最大范围，比如如果靠近时的值是0，远离时的值是1，那么getMaximumRange()的值应该是1 才不会影响我们的判断，我这里仅仅是从API 角度和我们日常的使用习惯来说的，如果不是这样的规律，就会对我们的编程造成麻烦。
酷派5890 手机：变化的数值为（3，5），getMaximumRange()的值为10；
华为Y320-T00 手机，变化的数值为（0，10），getMaximumRange()的值为20；
中兴U930HD 手机，变化的数值为（3，100），getMaximumRange()的值为1023；
腾讯Bugly简介
Bugly是腾讯内部产品质量监控平台的外发版本，其主要功能是App发布以后，对用户侧发生的Crash以及卡顿现象进行监控并上报，让开发同学可以第一时间了解到App的质量情况，及时机型修改。目前腾讯内部所有的产品，均在使用其进行线上产品的崩溃监控。
转载于:https://my.oschina.net/bugly/blog/536086