android怎么获取当前app的uuid

import androidtelephonyTelephonyManager; //引入相关包

TelephonyManager tm = (TelephonyManager) thisgetSystemService(TELEPHONY_SERVICE);

tmgetDeviceId();//得到设备唯一ID，（GSM手机的 IMEI 和 CDMA手机的 MEID）

1、首先在搜索引擎查找微信公众号官网，点击进入官网：

2、接下来登陆需要获取AppID的公众号，在登录框输入账号密码，点击登录后登录：

3、 在公众号管理左侧的菜单，点击开发目录线面的基本配置选项：

4、然后就可以看到小程序的开发者ID了。以上就是获取小程序AppID的方法：

获取手机设备的相关信息，如IMEI、IMSI、型号、厂商等。通过plusdevice获取设备信息管理对象。

获取当前运行环境信息、与其它程序进行通讯等。通过plusruntime可获取运行环境管理对象。

直接上demo

注意：

获取IP地址和plusdevicegetInfo都是异步的，所以在使用的时候要注意时机

效果图：

Android和IOS获取imei、imsi、uuid时须知：

imei: (String 类型 )设备的国际移动设备身份码

如果设备不支持或无法获取（如用户未授权）则返回空字符串。 如果设备存在多个身份码，则以“,”字符分割拼接，如“862470039452950,862470039452943”。

平台支持

imsi: (Array[ String ] 类型 )设备的国际移动用户识别码

字符串数组类型，获取设备上插入SIM的国际移动设备身份码。 如果设备支持多卡模式则返回所有SIM身份码。 如果设备不支持或没有插入SIM卡则返回空数组。

平台支持

uuid: (String 类型 )设备标识

设备的唯一标识号。

平台支持

其他的属性和方法，参考html5plus官网：

>

设备ID，简单来说就是一串符号（或者数字），映射现实中硬件设备。

如果这些符号和设备是一一对应的，可称之为“唯一设备ID（Unique Device Identifier）”

不幸的是，对于Android平台而言，没有稳定的API可以让开发者获取到这样的设备ID。

开发者通常会遇到这样的困境：

随着项目的演进， 越来越多的地方需要用到设备ID；

然而随着Android版本的升级，获取设备ID却越来越难了。

加上Android平台碎片化的问题，获取设备ID之路，可以说是步履维艰。

关于设备ID的作用，大概可以分为下面几点：

获取设备标识的API屈指可数，而且都或多或少有一些问题。

常规的API有以下这些：

IMEI本该最理想的设备ID，具备唯一性，恢复出厂设置不会变化（真正的设备相关）。

然而，获取IMEI需要 READ_PHONE_STATE 权限，估计大家也知道这个权限有多麻烦了。

尤其是Android 60以后, 这类权限要动态申请，很多用户可能会选择拒绝授权。

我们看到，有的APP不授权这个权限就无法使用， 这可能会降低用户对APP的好感度。

而且，Android 100 将彻底禁止第三方应用获取设备的IMEI, 即使申请了 READ_PHONE_STATE 权限。

所以，如果是新APP，不建议用IMEI作为设备标识；

如果已经用IMEI作为标识，要赶紧做兼容工作了，尤其是做新设备标识和IMEI的映射。

通过 androidosBuildSERIAL 获得，由厂商提供。

如果厂商比较规范的话，设备序列号+BuildMANUFACTURER应该能唯一标识设备。

但现实是并非所有厂商都按规范来，尤其是早期的设备。

最致命的是，Android 80 以上，androidosBuildSERIAL 总返回 “unknown”；

若要获取序列号，可调用BuildgetSerial() ，但是需要申请 READ_PHONE_STATE 权限。

到了Android 100以上，则和IMEI一样，也被禁止获取了。

总体来说，设备序列号有点鸡肋：食之无味，弃之可惜。

获取MAC地址也是越来越困难了，

Android 60以后通过 WifiManager 获取到的mac将是固定的：02:00:00:00:00:00 ，

再后来连读取 /sys/class/net/wlan0/address 也获取不到了。

如今只剩下面这种方法可以获取（没有开启wifi也可以获取到）：

再往后说不准这种方法也行不通了，且用且珍惜~

Android ID 是获取门槛最低的，不需要任何权限，64bit 的取值范围，唯一性算是很好的了。

但是不足之处也很明显：

1、刷机、root、恢复出厂设置等会使得 Android ID 改变；

2、Android 80之后，Android ID的规则发生了 变化 ：

两个规则导致的结果就是：

第一，如果用户安装APP设备是80以下，后来卸载了，升级到80之后又重装了应用，Android ID不一样；

第二，不同签名的APP，获取到的Android ID不一样。

其中第二点可能对于广告联盟之类的有所影响。

笔者之前写过一篇文章 《Android设备唯一标识的获取和构造》 , 文中提到设备ID的两个概念：唯一性和稳定性。

唯一性：两台不同的设备获取到的设备ID不相同；

稳定性：同一台设备在不同的时间, 获取到设备ID相同。

分析唯一性，我们可以从ID的分配来入手：

左边第一栏是bit数量，第二栏是对应的取值范围，再后面是元素个数以及对应的冲突概率。

例如，假如有50000个32bit的随机数，则这些随机数中，至少有两个相同数字的概率为25%；

换一种说法，就是假如有四组数，每组都有50000个随机数，则大约其中一组会有重复的数字。

32bit有43亿的取值范围，怎么50000个随机数就有这么高的出现重复的概率？

如果对此感到困惑，可以了解一下 生日悖论 。

Android ID是长度为16的十六进制字符串，其实就是64bit，我们来分析一下其重复的概率：

假如APP累计激活量达到50亿的APP，则每两个这样的APP就大约有一个会有重复的Android ID。

不过这里的“重复”不是大量的重复，而是“至少有两个相同”，也就是，如果设备激活量有50亿（很多APP达不到-_-），那么有可能会有少量的重复的Android ID。

总体而言, Android ID的唯一性还是不错的。

JDK的randomUUID，大致可以认为是128bit的随机数（其中有6bit是固定的），即使到达200亿的数量，有重复的概率也仅仅是10的负18次方，微乎其微。

稳定性有两个层面：

无论是统计需求，还是业务需求，都要求设备ID是唯一的，稳定的。

如果设备ID有重复，则活跃统计，用户画像，定向推送等统统都不准确了；

其中，影响最深是定向推送，送错快递还有可能追回，推送错了就不好说了，如果推送内容又比较重要，后果不堪设想。

如果设备ID不稳定（ID变化），会影响到活跃统计（会认为是新用户），对用户画像也有较大影响（之前的ID关联的行为数据无法跟踪了）。

为此，有必要设计一套方案，提供相对定稳定的，唯一的设备ID。

首先要明确两个前提条件：

前面分析的设备ID中，在可用的前提下，出现重复的概率较小；

如果一定的频率去观察，比如说每天，总体而言，观察到和昨天不一样的概率也是较小的。

如何在本来就较小的概率的前提下，继续降低概率呢？

一种方案是组合设备ID(直接拼接，或者拼接后计算摘要)。

举个例子，假如出现重复的概率和发生变化的的概率都是千分之一，

则对于两台不同设备，两个设备ID同时重复的概率是百万分之一，两个设备ID至少有一个发生变化约为千分之二。

也就是，拼接ID的效果是大大提高唯一性，但是一定程度上降低稳定性（只要其中一个要素变化，拼接的ID就变了）。

但事实上，如今能拿到的设备ID，最突出的矛盾是不稳定，所以，我们不能为了提高唯一性而牺牲稳定性。

要提高稳定性，可以引入容错方案。

容错方案有很多，比如网络传输，用checksum去校验报文，如果出错了则重发；

再如磁盘阵列，数据写入两个磁盘，只有当两个磁盘同时出错时才会丢失数据，从而大大降低丢失数据的概率。

但是对于设备ID，以上两种方案都不合适，因为上面的方案需要通过checksum来确认原信息是否被修改，设备ID没有这样的条件。

所以，可以引入类似虚拟货币用到的"拜占庭容错"方案。

简单地说，就是要采集三个设备ID到云端，如果有两个（包括两个以上）的设备ID和之前的记录相同，则认为是同一台设备。

同样假设出现重复的概率和发生变化的的概率都是千分之一，则：

同一台设备的两次采集，认不出是同一台设备的条件为“至少两个设备ID都和上次不一样”，概率约为百万分之三。

两台不同的设备，认为是同一台的条件是为“三个设备ID中，至少有两个设备ID和另一台设备相同”，概率同样约为百万分之三。

所以，用此方案，唯一性和稳定性都能得到提高。

基本思想是：服务端有一张设备 ID 的表，核心的属性（Column）有：

id | did_1 | did_2 | did_3

客户请求时，上传三个设备 ID，服务端检索:

如果检索到记录，其中至少两个did和上传的相同，则返回 id;

否则，插入上传的三个设备 ID，并将新插入记录的 id 返回。

通常情况下，服务端表的主键为自增序列（为了确保插入的有序性），

所以我们不能直接返回表的主键，否则容易被他人推测其他的设备 ID，以及知晓用户数量。

因此，在主键 ID 之外，我们需要另外一个唯一 ID。

有两种思路：

然后就是，需要三个设备ID……

那么，如果在没有 READ_PHONE_STATE 权限的情况下，以及Android 100之后，如何处理？

首先，设备序列号还是要采集的，毕竟还有部分旧版本的设备可以获取到，能区分一点是一点；

然后，采集一些设备相关的信息，机型，硬件信息等（相同的机型，可能有多种配置，所以同时也采集一下硬件信息）。

最终匹配规则如下：

如果没有匹配的设备，则认为是新设备；

此时，生成新的udid返回，同时插入新设备的相关信息（设备ID，硬件信息）。

关于硬件信息，需满足一个要求：在设备重启、恢复出厂设置等 *** 作之后，不会变化。

常规信息有CPU核心数，RAM/ROM大小（以Gb为单位采集，而不是精确到比特，否则容易变化），屏幕分辨率和dpi等，结合机型，保守估计有上千甚至上万种可能性，相对Android ID 的 2^64 当然相差很远了，但是仍可作为辅助的参考信息。

试想在设备序列号获取不到，Android ID 和 MAC 地址其中一个发生变化时，检索到的都是只有Android ID 或者 MAC 其中一个匹配的记录，茫茫机海，说不准就有一两台的Android ID 或 MAC是相同的。

这时候选哪一个呢？ 再加上设备信息，或许就区分开了。

常规的设备信息容易遭到篡改，所以，在常规信息之外，我们可以挖掘一些冷门的设备特征，比如 NetworkInterface 和 传感器 的相关信息。

当常规信息被篡改时，如果冷门的设备信息还没变，仍可识别出是同一台设备。

至于如何挖掘，那就各显神通了，通常做手机硬件或者ROM的朋友可能会知道更多的API。

为了方便检索，我们可以用 MurmurHash 将信息压缩到64bit(Long的长度）。

再者，在获取到udid之后，可以定时（比如每隔两天）就上传udid和设备信息给云端，云端比较一下存储的信息和上传的信息，不相同则更新，这样可以提高udid的稳定性。

比方说，用户在设备是Android 70 的时候卸载了APP，在Android 80之后安装回来，这时候Android ID 是变化了的，但是凭着MAC和设备信息我们可以认出这台设备，同时更新其 Android ID;

如果哪一天轮到MAC获取不到了，这时候我们仍可以根据 Android ID和设备信息识别出这台设备。

本文介绍了设备ID的用途，现状，并分析了现有设备ID的特性，最后提出了一套设备ID的构造方案。

按照这几年的趋势，各种设备ID的API或许还会越收越紧，仅从客户端去构造可靠的设备ID是比较困难的，而基于信息采集和云端综合计算则相对容易。

具体实现，笔者编写了一个Demo，已发布的到github，谨供参考。

项目地址： >

以上就是关于android怎么获取当前app的uuid全部的内容，包括:android怎么获取当前app的uuid、怎么获取开发小程序的app id、H5获取手机设备信息、app版本信息、ip地址等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！