十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
最近在做一个OA考勤项目,里面有个需求是一个账号只允许绑定一台设备, 这就需要将设备唯一标识码与账号绑定在一起,咋一听 这还不So Easy啊,直接获取deviceID 不就好了。。。
成都创新互联公司成立十多年来,这条路我们正越走越好,积累了技术与客户资源,形成了良好的口碑。为客户提供成都网站设计、网站建设、网站策划、网页设计、主机域名、网络营销、VI设计、网站改版、漏洞修补等服务。网站是否美观、功能强大、用户体验好、性价比高、打开快等等,这些对于网站建设都非常重要,成都创新互联公司通过对建站技术性的掌握、对创意设计的研究为客户提供一站式互联网解决方案,携手广大客户,共同发展进步。
咋一操作也挺好。 可到了大面积的群体用户测试环节发现了几个问题。
简言之就是如果你的手机需要考虑Android9以上的设备,你就没办法通过获取系统提供的API完全的获取到设备唯一标识码,根据Android文档 唯一标识符最佳做法 你也许可以这样....
呃.... 这个特殊运营商许可 和这个 READ_PRIVILEGED_PHONE_STATE 好像都不是我们一般的安卓应用能获取的到的。
想要能Android9以上又能不受到刷机,格式化的影响。 就只能 使用移动安全联盟(MSA)提出的补充设备标识
是由 移动安全联盟 提出的,包含以下三个标识:
缺点就是:并不是所有的品牌商都兼容了, 而且需要导入他们对应的包 。 这部分可参考 Android 10获取设备标识方案探究 这篇文章
特点: 如果格式化或者刷机,这个设备ID会更改(这个也是合理的)。
完善:可以在第一次生成后放入到内部存储和外部存储,下次进入先从内部存储获取,如果没有在去外部存储比较(App卸载,内部存储就没了)。 如果在没有就生成一个
获取Android唯一标识的具体操作步骤:
DEVICE_ID
假设确实需要用到真实设备的标识,可能就需要用到DEVICE_ID。在以前,Android设备是手机,这个DEVICE_ID可以同
通过TelephonyManager.getDeviceId()获取,它根据不同的手机设备返回IMEI,MEID或者ESN码,但它在使用的过程中
会遇到很多问题:
非手机设备: 如果只带有Wifi的设备或者音乐播放器没有通话的硬件功能的话就没有这个DEVICE_ID
权限: 获取DEVICE_ID需要READ_PHONE_STATE权限,如果只为了获取它,没有用到其它的通话功能,那这个权限有点大才小用
bug:在少数的一些手机设备上,该实现有漏洞,会返回垃圾,如:zeros或者asterisks的产品。
2. MAC ADDRESS
也可以通过手机的Wifi或者蓝牙设备获取MAC ADDRESS作为DEVICE ID,但是并不建议这么做,因为并不是所有的设备都有Wifi,并且,如果Wifi没有打开,那硬件设备无法返回MAC ADDRESS.
3. Serial Number
在Android 2.3可以通过android.os.Build.SERIAL获取,非手机设备可以通过该接口获取。
4. ANDROID_ID
ANDROID_ID是设备第一次启动时产生和存储的64bit的一个数,当设备被wipe后该数重置
ANDROID_ID似乎是获取Device ID的一个好选择,但它也有缺陷:
它在Android =2.1 or Android =2.3的版本是可靠、稳定的,但在2.2的版本并不是100%可靠的
在主流厂商生产的设备上,有一个很经常的bug,就是每个设备都会产生相同的ANDROID_ID:9774d56d682e549c
5. Installtion ID : UUID
最近,因公司产品及客户需要,领导让我研究免存储设备ID,以及给出一个设备ID最佳的方案(可与存储相结合)。在研究过浏览器的fingerprient2js后,颇有心得,并且看网上似乎木有完美的解决方案,于是写了这篇文章,仅供需要的开发者参考。(该算法暂未进行验证,这里先给出一个jar包,后期我会在SDK中加入调查接口,分两个jar包(测试版和正式版),希望开发者能支持测试版,稳定后使用正式版。)
在产品中,首先肯定要尽量避免权限,其次考虑卸载APP后ID不一致的问题,再就是尽量结合存储,降低卸载或重装app时,设备ID改变的概率。最后,设计出合理方案,对造成不利的因素进行列举。
A.android_id:
什么是android_id呢?当设备在第一次启动时,系统会随机产生一个64位的数字,然后以16进制的形式保存在设备上,且API提供了获取这一参数的方法:
这就是android_id,当设备重新初始化或者刷机的时候,会被重置。
除此以外,android_id还有其他的bug,比如:
1.不同的设备可能会产生相同的android_id。
2.有的厂商设备无法获取android_id,会返回null。
3.对于CDMA的设备,ANDROID_ID和TelephonyManager.getDeviceId() 的值相同。
4.不同的android系统版本稳定性不同。
B.硬件序列号(SERIAL)
API给的解释是:
A hardware serial number, if available.(一个硬件的序列码,如果有效的话)
so,虽然我没有用几百台手机测试,也能知道这个值有时候是无效的,说的这么隐晦。
C.指纹
fingerprint:设备的唯一标识。由设备的多个信息拼接合成。
也是在JavaScript才接触到这个单词”fingerprint“,这个词也很生动,意思是能大概的标识一个设备,像指纹一样,但不排除重复的可能性。
理论上讲用这个属性是可以标识一个设备的,但是其实并不是,两台一摸一样的新手机,这个值相同的可能性是很多的。为了更加进一步的精确,后面还会介绍几个属性,并把几个属性结合在一起,生成一个接近100%的UUID。
D.android系统提供了获取android系统版本号,生产厂商,固件版本推出时间的API.
E.android系统提供了当前android设备是12或24小时制显示时间的API,
F.android系统提供了当前android设备的修订版本列表,显示屏,主板等等参数。
G.可以允许用户根据需求用自定义字符串去为FP做贡献,比如IP地址等
方案:
在不需要用户权限的前提下,网上最完美的方案是将android_id和硬件序列号,如果其中任意一种失效就使用另外一种。受FingerPrint2js的启发,我看了Android获取系统硬件相关的API,将所有不经常变化且能代表一定用户群体的属性都取出来进行MD5运算,包含但不限于依据中所述的信息。准确性还需进一步验证,但理论上要比FingerPrint2js准确性高,也在网上给出的比较好的方案基础上进一步缩小了FP可能重复的概率。
1.第一次进入APP时,获取系统相关配置信息生成FP,存入SP。
2.每次访问,先从SP取,没有再通过相关配置信息生成FP,存入SP。
3.封装成jar,只给用户暴露出获取ID的接口、传递自定义信息构建FP的接口以及第一次安装时间戳的接口(或设置标签调用的接口)
单纯对于FP而言,有两个主要问题需要解决,一是FP重复的问题,相同配置的新设备重复可能性极大,增多给FP贡献的因素的数量,可以有效降低重复率。二是FP改变的问题,贡献FP的生成因素的其中一个如果改变,FP就会改变。所以如果FP的贡献因素数量过多,导致FP改变的概率也就变大,所以说客户要在两者之间做一个很好的平衡。
对比:
为android FP做贡献的各配置参数:(示例以6.0的华为荣耀8为例)
1.Android_ID:Settings.System.getString(context.getContentResolver(), Settings.System.ANDROID_ID) //低版本稳定,高版本不稳定 示例:295a4fbf716094ee
2.Build.SERIAL 设备序列号(有的设备无法获取) 示例:WTK7N16923005607
3.Build.FINGERPRINT 设备指纹(同样的新设备该值应该是一样的) 示例:honor/FRD-AL00/HWFRD:6.0/HUAWEIFRD-AL00/C00B171:user/release-keys
4.Build.TIME 固件推出日期 示例:1477442228000
5.Build.VERSION.INCREMENTAL 源码控制版本号 示例: C00B171
6.Build.getRadioVersion() 获取无线电固件版本 示例:21.210.03.00.031,21.210.03.00.031
7.Build.HARDWARE 硬件名称 示例:hi3650
8.Build.VERSION.SECURITY_PATCH 用户可见安全补丁level(这里我得到的是日期,可能是补丁修复的时间)示例:2016-10-01
9.当前设备是12/24时制:Settings.System.getString(context.getContentResolver(), Settings.System.TIME_12_24) 示例:null(有的手机可以获取)
10.Build.VERSION.SDK_INT SDK版本号 (一般讲是与系统版本号一一对应的) 示例:23
11.Build.SUPPORTED_32_BIT_ABIS 支持32位ABIs的列表(数值)示例:[armeabi-v7a,armeabi]
12.Build.SUPPORTED_64_BIT_ABIS 支持64位ABIs的列表(数值)示例:[arm64-v8a]
13.Build.BOOTLOADER 系统启动程序版本号 示例:unknown
14.Build.VERSION.RELEASE 用户可见版本 示例: 6.0
16.Build.BOARD 主板 示例:FRD-AL00
17.Build.BRAND 系统定制商 示例:honor
21.Build.HOST 示例:huawei-RH2288H-V2-12L
23.Build.MANUFACTURER 产品/硬件的制造商 示例:HUAWEI
25.Build.PRODUCT 产品的名称 示例:FRD-AL00
26.Build.TAGS 描述Build的标签(Comma-separated tags describing the build, like "unsigned,debug".) 示例:release-keys
28.Build.USER 描述Build的USER 示例:jslave
31.Build.VERSION.BASE_OS 基带版本 The base OS build the product is based on. 示例:空值
32.自定义字符串或自定义数组