摘要:双卡数据库适配流程根据系统数据内容来做适配开发,找到区分双卡的标识字段和字段对应的值。主要涉及的数据库表有两个短信彩信电话。需要更新中的数据中的字段值来标识卡槽。文腾讯优测李艳超
摘要:android双卡数据库适配是常见的适配难题,腾讯优测是app自动化适配测试平台,提供APP兼容性适配测试,远程真机租用等多维度的测试服务,为大家奉上“优分享”-腾讯内部的移动研发测试干货精选~
关键词:数据库适配,双卡适配,移动研发,android适配
许多APP都希望获取用户通讯录联系人,利用通讯录关系链信息来丰富产品功能。在读取系统联系人数据库的ContentProvider时,对于双卡双待手机,电话和短信数据都需要标识来自哪张卡。
Android 5.0开始加入Dual Sim支持,Android 官方方案和mtk的方案十分类似,感兴趣的小伙伴可以直接移步mtk方案实现方式。
根据系统ContentProvider数据内容来做适配开发,找到区分双卡的标识字段和字段对应的值。为了以下阐述内容清晰,这里约定:主卡—0卡,副卡—1卡。
主要涉及的数据库表有两个:短信彩信、电话。
如果手机安装了安全软件有可能”污染“数据库数据,清空数据库中的数据可以保证以下操作的准确性。
2.使用系统短信程序和拨号程序分别使用1卡、2卡发送短信,拨打电话保证使用的是系统短信和拨号程序,第三方APP会接管系统程序,开始操作前需卸载第三方APP。
3.读取数据库值,找到区分卡槽的值对于可以root的手机,可以直接找到对应的数据库文件,导出后使用SQLite查看器来查询数据库中的值。
短信、彩信数据库位置:
/data/data/com.android.providers.telephony/mmssms.db
电话数据库位置:
data/data/data/com.android.providers.contacts/contacts2.db
注意:对应的.db-wal、.db-shm文件也需要导出,SQLite引入了日志预写模式(WAL),如果不导出这两个文件,数据更新不及时。
双卡数据库适配常见类型都有哪些? 1.新增标识字段常见于:三星、moto等
举例:手机的短信数据库
通过上图,我们可以知道短信数据库表中:
标识双卡的字段名:sim_id,字段的值:卡0—-0 || 卡1—-1
这种情况相对简单,在做短信、电话相关的APP只需要:
(1)确定对应的卡槽
(2)需要数据库操作时,增加一列对于双卡标识字段的操作
常见于mtk系列芯片的手机
现象:
按照1中的方法找到了区分卡槽的字段和值,发现当用户换卡时,标识字段对应的值会随着变化,每换一张新卡,对应的simId值+1。
问题原因:
如下图所显示,这类手机新建了一张表,用来记录SIM卡的信息。对应的uri为:Uri uri = Uri.parse(“content://telephony/siminfo”);
解释:
slot字段值为0:主卡
slot字段值为1:副卡
slot字段值为-1:此卡没有安装在卡槽
如下图,sms表和siminfo表的映射关系。sms表中的simId字段存储的是siminfo表中对应的_id,siminfo中对应的0,1是卡槽的标识。
注意:siminfo表是系统维护的,第三方APP只需读取,不需要进行“写”操作。
解决办法:
(1)确立映射关系
在一定的触发时机(应用启动,监听iteminfo数据库信息变化),触发iteminfo表的查询,将查询结果建立成映射关系。
0—-4
1—-3
(2)需要操作时根据卡槽获得映射值写入db
mtk在双卡双待方面的积累是很深厚长久的,在功能机时代就有非常广泛的应用。那么为什么还要如此麻烦的新建一张表来做这个映射呢?为什么不使用方案1 简单的处理呢?
场景:
使用1中数据库新增字段的方法,对于WCDMA联通定制机(同时G卡制式),如果用户将两张卡对调位置,将会发生什么情况?
在方案1中,所有的信息直接和sms表中的双卡标识字段绑定,如果换卡的话将无法判断信息来自那个SIM卡,在上述的场景发生时,用户所有的信息和SIM卡发生混乱。
在方案2中,因为sms和siminfo存在映射关系,siminfo表中的icc_id可以唯一标识一张SIM卡,不会发生方案1中出现的换卡可能造成的信息错乱问题。
思考总结:
方案2的存在是合理的,因为方案1同时存在缺陷。
常见于:酷派系列手机
特殊点:root没有成功,无法查看data/data目录下内容
电话数据库适配:
使用查询数据库的工具
清空db后操作:使用0、1卡分别向5520拨打电话,使用0卡向10010拨打电话。通过记录的查询结果可知,电话标识字段为moduletype,字段对应的值为0—–1 || 1——2
短信数据库适配:
清空db后向5520发送4条短信,见下图:
当使用查询工具查询结果时,会出现下图的情况,其中sim_id通常在方案1中作为双卡标识的字段,但是在这款手机上值均为-1。(可以注意到iteminfo字段中的值时累加的1、2、3、4)
查询iteminfo数据库表的结果:Uri.parse(“content://mms-sms/itemInfo”);
数据库表关联关系:适配方法:
(1)每次在sms表插入一条数据,iteminfo会对应的增加一条记录,这个是由系统provider自动完成的。
(2)需要更新iteminfo中的数据中的network_type字段值来标识卡槽。
总结:
不仅系统联系人需要数据库适配,当APP开发过程中使用到系统数据库的时候,可能也会遇到类似的适配问题。这时,也可以使用类似的方式处理。
文/腾讯优测 李艳超
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/17556.html
阅读 1653·2021-11-23 09:51
阅读 2676·2021-11-22 09:34
阅读 1315·2021-10-14 09:43
阅读 3660·2021-09-08 09:36
阅读 3205·2019-08-30 12:57
阅读 2025·2019-08-30 12:44
阅读 2515·2019-08-29 17:15
阅读 3013·2019-08-29 16:08