明明就是iOS系统的，结果微信要安装苹果定制版的居然提示这个，求助怎么回事，有谁知道的求告知

您好！很高兴能为您解答， 拒绝 iOS 应用获取设备的 UDID的原因

UDID本来是为了方便一个应用来统计用户行为的，但是因为是一个唯一ID，而且直接看不到跟用户隐私的关系，所以是开放出来的。但是，当有大量的App在市场中，而UDID对于每个App都是一样的时候，用户的隐私其实受到了一定程度的侵犯。假设有很多App联合在一起，因为UDID是统一的，那么他们就可以拼凑出用户的隐私出来。所以从这个角度苹果去掉了UDID的支持，而每个应用可以自行生成自己的UUID，所以，单一app的统计仍旧不会发生问题。所以主要的原因是隐私问题。

、必须使用UDID时建议的UUID替代方案

-(NSString) uuid {

CFUUIDRef puuid = CFUUIDCreate( nil );

CFStringRef uuidString = CFUUIDCreateString( nil, puuid );

NSString result = (NSString )CFStringCreateCopy( NULL, uuidString);

CFRelease(puuid);

CFRelease(uuidString);

return [result autorelease];

}

苹果公司建议采用上述代码为应用生成唯一标识字符串。开发者可以在应用第一次启动时调用一次，然后将该串存储起来，以便以后替代UDID来使用。显而易见，这种方法问题很多。如果用户删除该应用再次安装时，又会生成新的字符串，所以不能保证唯一识别该设备；如果你从一台旧设备中备份文件到新设备中，两台设备就拥有相同的CFUUID；如果你从临时文件中备份 *** 作系统，就会出现一个设备里存在不同CFUUID的情况。

2、使用开源方案OpenUDID

贡献者在readme文档中说：

OpenUDID is a drop-in replacement for the deprecated [UIDevice uniqueIdentifier] aka UDID on iOS, and otherwise is an industry-friendly equivalent for iOS and Android

The agenda for this community driven project is to: – Provide a reliable proxy and replacement for a universal unique device identifier That is, persistent and sufficiently unique, on a per device basis – NOT use an obvious other sensitive unique identifier (like the MAC address) to avoid further deprecation and to protect device-level privacy concerns – Enable the same OpenUDID to be accessed by any app on the same device – Supply open-source code to generate and access the OpenUDID, for iOS and Android – Incorporate, from the beginning, a system that will enable user opt-out to match Apple’s initial intent

愿景很好，也确实没有用到MAC地址，同时能保证同一台设备上的不同应用使用同一个OpenUDID。但是仔细分析，还是能发现问题。

unsigned char result[16];

const char cStr = [[[NSProcessInfo processInfo] globallyUniqueString] UTF8String];

CC_MD5( cStr, strlen(cStr), result );

_openUDID = [NSStringstringWithFormat:

@"%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%08x",

result[0], result[1], result[2], result[3],

result[4], result[5], result[6], result[7],

result[8], result[9], result[10], result[11],

result[12], result[13], result[14], result[15],

arc4random() % 4294967295];

这里使用了NSProcessInfo类。

当设备上第一个使用OpenUDID解决方案的应用第一次调用时，确实会生成一个唯一的识别码。同时，为了与官方的UDID位数相同，还在MD5值后面追加了8位随机码。然后，该方案使用到了NSUserDefaults类（应用设置）。应用将获取到的唯一识别码保存到应用的UserDefaults中，如果程序以后需要使用唯一识别码，就从UserDefaults中获取，这样就保证可以拿到同一个识别码。但是，如果用户删除了应用，UserDefaults同样会被清空，为了避免重新生成唯一识别码，该方案还使用到了UIPasteboard类（设备剪切板）。应用在将唯一识别码保存到UserDefaults的同时，也会将其保存到以特殊的key标识的UIPasteboard中。代码如：

1

2

UIPasteboard slotPB = [UIPasteboardpasteboardWithName:availableSlotPBid create:YES];

[slotPB setData:[NSKeyedArchiver archivedDataWithRootObject:dict] forPasteboardType:kOpenUDIDDomain];

其中availableSlotPBid是一个字符串key，前缀是“orgOpenUDIDslot”，点后面加上数字。这个数字默认是从0到99（当然你可以修改源代码使它更大或者更小）。

如果设备上安装了第二个使用OpenUDID解决方案的应用，当应用调用生成OpenUDID的方法时，将会从UIPasteboard中获取唯一识别码（遍历key从0到99的UIPasteboard），这里取到的就是之前第一个应用保存到UIPasteboard中的。也就是说，只要用户设备上有一个使用了OpenUDID的应用存在时，其他后续安装的应用如果获取OpenUDID，都将会获得第一个应用生成的那个。

看起来似乎很好，很复杂。但是仔细想想，还是有问题，如果把使用了OpenUDID方案的应用全部都删除，再重新获取OpenUDID，此时的OpenUDID就跟以前的不一样了（本人测了一下，确实如此）。可见，这种方法还是不保险。

3、开源方案SecureUDID

稍微看了下SecureUDID源码，发现其与OpenUDID其实差不多，只是初始获取的唯一识别码稍有不同。同时，从作者的Readme文档中可见，这个方案同样存在很多问题。如原文：

Is this a true UDID replacement

SecureUDID has two properties that you should know about before you use it First, as indicated above, the identifier is not derived from hardware attributes Second, the persistence of an identifier cannot be guaranteed in all situations This means that, while unlikely, it is technically possible for two distinct devices to report the same identifier, and for the same device to report different identifiers Consider this carefully in your application Here is a list of situations where this identifier will not exhibit the uniqueness/persistence of a traditional UDID

The user has opted-out of the SecureUDID system, in which case you will receive a well-formed string of zeroes

Device A is backed up and then restored to Device B, which is an identical model This is common when someone breaks their phone, for example, and is likely desirable: you will receive Device A’s SecureUDID

The SecureUDID data is removed, via user intervention, UIPasteboard data purge, or by a malicious application

The SecureUDID backing store becomes corrupt

All SecureUDID applications are uninstalled from a device, followed by a UIPasteboard data purge

我发现，其实前面的OpenUDID也基本存在以上问题，只是作者没写出来。看来还是SecureUDID的贡献者比较厚道。

4、与WIFI MAC地址相关

网上同样有一些与WIFI MAC地址相关的替代方案，主要分三种：第一种直接使用“MAC Address”；第二种，使用“MD5(MAC Address)”；第三种，“MD5(MAC Address+CFBundleIdentifier)”。github上有个开源项目（UIDevice-with-UniqueIdentifier-for-iOS-5）实现了这几种方法。

使用这种方法也存在问题：1、市面上有部分机器（虽然数量极少，但是本人在使用过程中确实发现过这种情况）无法获得MAC地址，有人说这部分机器是联通阉割无WIFI版的，具体不得而知了。2、MAC地址跟UDID一样，存在隐私问题。苹果现在禁用UDID，不能保证以后不会禁用MAC地址。

5、部分大公司私有的解决方案，但是他们怎么会告诉你呢？

所以，如果你想以一种万无一失的方法追踪某台设备，现在还没有比UDID更合适的选择。但是，苹果现在不让用了，苦逼的开发者们，该怎么办呢？

> 本文节选自霍格沃兹测试学院内部教材

本章节主要讲解 iOS 自动化真机配置以及在 iOS 真机执行自动化时常见问题与解决方法。

真机使用的Capability  

与模拟器不同，真机测试需要如下的 Capability

方式一：设置 App 路径，启动 App（自动安装 App）

                        

    {  "app": "/Users/seveniruby/Library/Developer/Xcode/DerivedData/UICatalog-ftyzdbgapjmxxobezrnrxsshpdqh/Build/Products/Debug-iphoneos/UICatalogapp",  "automationName": "XCUITest",  "platformName": "ios",  "xcodeOrgId": "xxxxxx",  "xcodeSigningId": "iPhone Developer",  "udid": "9df22446af15919c494c85b4c1c8b00eaa3a5bd0"}

方式二：根据 App 包名启动 App

                           

    {  "platformName": "ios",  "bundleId": "comexampleapple-samplecodeUICatalog",  "automationName": "XCUITest",  "deviceName": "iPhone",  "udid": "auto",  "xcodeOrgId": "xxxxx",  "xcodeSigningId": "iPhone Developer"}

  app: Xcode 选择真机编译后的 app 位置

  bundleId: 每个 App 的标识，相当于 Android App 的 appPackage

  xcodeOrgId: Team ID，获取方法详见`>

什么软体可以改变安卓手机来电接听方式？

这个手机本身的无法更改的，可以通过下载软体来更改。

在应用商城搜寻来电接听软体，找到你喜欢的软体下载。

安装软体之后，开启，软体会提醒你 *** 作步骤，根据步骤 *** 作即可。

升级或刷机韧体，android237系统可以实现自定义滑动接听来电。

个人建议只是一个接听电话的方式，现在沟通基本都是用聊天工具，电话都是销售公司在用，没有必要大费周章去改变接听方式。

Android是一种基于Linux的自由及开放原始码的作业系统，主要使用于移动装置，如智慧手机和平板电脑，由Google公司和开放手机联盟领导及开发。

您好：

升级或刷机韧体android237系统可以实现自定义滑动接听来电，还有系统设定中==》通话设定==》接听电话==》使用应答模式 短按主萤幕键 ==》还有佩戴耳机时 自动接听来电。

现在还没有可靠有效的 软体可实现如 摇动感测器 或者 轻叩机体等接听电话的 安卓等软体，这种接听方式 一般是给有行动或者识别（如盲人）障碍的人士更方便的接听电话的，其一般需要一定的硬体模组支援，不过有讯息安卓40可整合或实现摇晃或者轻叩手机实现固定模式下的 *** 作。

祝您愉快-，-~~如有其它问题可直接百度hi我，或+Q讨论。如想知道其他最新数码资讯请百度 知道钢七连终身荣誉团。

安卓手机什么软体可以改变应用图示

通过安装手机主题就可以改变手机应用图示，下载手机主题的时候可以通过应用宝来下载，应用宝不光可以下载手机软体和手机游戏，也可以下载手机主题和手机桌布，而且内容非常全，什么型别的手机主题都可以在应用宝里下载到，安装使用也很稳定，很少出现相容性问题。

什么软体可以改变安卓手机开关机的声音？

手机不是可以设定开关机声音么，望采纳

安卓手机root可以改变udid吗

一般的时候，手机root之后就不可以官方升级了！ 不过你要是移除这个root的话，还是可以给手机升级的！ 有个叫应用宝的软体就是可以做到这个的！ 你可以去下载试试的~把手机设定里的USB除错开启， 这个在设定的开发者选项里的，然后连上电脑， 等著应用宝给手机安装驱动，在我的手机工具箱里面。 有内个一键root能给手机移除许可权，也可以获得许可权， 你升级之后，还可以用这个重新获得许可权，还是很简单的~

安卓手机什么软体可以改来电

三星手机设定来电 方法：

设定-声音和振动- -选择需要的系统 。如需自定义来电 ，请向上滑动萤幕-点选“+”从装置储存中新增-选择已下载的 即可。

安卓手机什么软体可以改变游戏的背景音乐

我觉得不需要什么软体，只要找到背景音乐的根目录，把里面的档案替换掉就行了。但一定要注意格式

“daiweijiade”说的也是一个办法，但我那个方法更根本

另外，你嫌自己换太烦的话，可以百度一下该游戏的修改器

可不可以改变vivo y23l的来电接听方式

手机的来电接听方式是手机系统预设的，不可以随意更改的。

安卓市场里可以改变接电话方式的软体是什么

可以去机锋等大点的android应用市场去淘，这种型别的软体比较多的。

怎样改变手机来电接听方式

改变手机来电接听方式的方法：

1升级或刷机韧体android237系统可以实现自定义滑动接听来电，还有系统设定中==》通话设定==》接听电话==》使用应答模式 短按主萤幕键 ==》还有佩戴耳机时 自动接听来电。

2现在还没有可靠有效的 软体可实现如 摇动感测器 或者 轻叩机体等接听电话的 安卓等软体，这种接听方式 一般是给有行动或者识别(如盲人)障碍的人士更方便的接听电话的，其一般需要一定的硬体模组支援，不过有讯息安卓40可整合或实现摇晃或者轻叩手机实现固定模式下的 *** 作。

改变手机来电接听方式的方法：

1手机待机页面，点选应用程式图示。

2进入手机应用程式介面，点选设定齿轮图示。

3在手机设定介面，点选辅助功能。

4进入辅助功能后，点选接听和结束通话-按下主页键，勾选。

5完成上述 *** 作后，当有电话呼入时，就可以按“主萤幕”键，即“HOME键”接听来电。

本文以App作为例子，实际应用不限于App范围。

大部分场合都可以通过程序调试来定位问题，但有些场景使用抓包来定位接口问题更准确、更方便，如以下场景：

要实现对App的网络数据抓包，需要监控App与服务器交互之间的网络节点，监控其中任意一个网络节点（网卡），获取所有经过网卡中的数据，对这些数据按照网络协议进行解析，这就是抓包的基本原理。

但是中间网络节点，不受我们控制，所以基本无法实现抓包的，只能在客户端和服务端进行抓包。

通常我们监控本地网卡数据，如下图：

本地网络 指的是WIFI的路由，如果直接抓路由器的包还是比较麻烦的，因此我们会在 手机 和 本地路由 之间加一层 代理服务 ，这样只要抓代理服务的网络数据即可：

虽然在 手机 侧也可实现抓包，但和 本地路由 一样，抓包比较麻烦，如果不是没有办法，尽量还是不在手机侧抓包。但是有一种情况必须在手机端抓包，那就是在4G网络情况下：

4G网络状态下如何抓包，以及它的劣势，我们后面章节再细讲。

抓包实际上是分析网络协议的一种过程，尽管繁琐的细节劳动都让抓包工具做了，但我们还是需要了解下基础的网络协议，好帮助我们更好的分析问题。

首先需要了解下经典的OSI七层网络模型，以及每层的作用，其次对TCP、>

埋点是数据采集的专用术语，在数据驱动型业务中，如营销策略、产品迭代、业务分析、用户画像等，都依赖于数据提供决策支持，希望通过数据来捕捉特定的用户行为，如按钮点击量、阅读时长等统计信息。因此，数据埋点可以简单理解为：针对特定业务场景进行数据采集和上报的技术方案。

数据埋点非常看重两件事，一个是数据记录的准确性，另一个则是数据记录的完备性。

先讲数据的准确性。数据埋点非常强调规范和流程，因为参数的规范与合法，将直接影响到数据分析的准确性，如果准确性得不到保障，那么所有基于埋点得出的结论，都是不可信的。辛辛苦苦做了很久的方案，一旦因为一个疏忽的小问题，导致下游集中投诉，其实非常划不来。

道理每个人都懂，但现实情况中，数据埋点所面对的客观环境，其实非常复杂，例如：

因此本文有非常长的篇幅来写流程问题，其实是非常有必要的。

再讲数据的完备性。因为埋点主要是面向分析使用，对用户而言是个额外的功能，因此埋点的业务侵入性很强，很容易对用户体验造成影响。别的不说，仅仅是流量的消耗，就很容被用户喷。因此，要提前想清楚，我们要采集哪些东西，因为修改方案的成本，是伤不起的。

通常情况下，我们需要记录用户在使用产品过程中的 *** 作行为，通过4W1H模型可以比较好的保障信息是完备的。4W1H包括：

规定好记录信息的基本方法之后，按照固定的频率，如每小时、每天，或者是固定的数量，比如多少条日志，或者是网络环境，比如在Wifi下上传，我们就可以开心的把埋点数据用起来了。

当然，数据记录的时效性也比较重要，但因为埋点数据通常量级会比较大，且各个端数据回传的时间不同，因此想做到实时统计，还是需要分场景来展开。在Flink技术日渐成熟的今天，全链路的实时采集与统计，已经不是什么难题。

在埋点的技术方案中，首先要重视的，是用户唯一标识的建设。如果做不到对用户的唯一识别，那么基础的UV统计，都将是错误的。

因此，在数据埋点方案中，有两个信息是一定要记录的，即设备ID+用户ID。设备ID代表用户使用哪个设备，如安卓的ANDROID_ID/IMEI，IOS中的IDFA/UDID，浏览器的Cookie，小程序的OpenID等。用户ID，代表用户在产品中所注册的账号，通常是手机号，也可以是邮箱等其他格式。

当这两个信息能够获得时，不论是用户更换设备，或者是同一台设备不同账号登录，我们都能够根据这两个ID，来识别出谁在对设备做 *** 作。

其次，我们来看一下Web的数据采集技术。Web端数据采集主要通过三种方式实现：服务器日志、URL解析及JS回传。

浏览器的日志采集种类又可以分为两大类：页面浏览日志和页面交互日志。

除此之外，还有一些针对特定场合统计的日志，例如页面曝光时长日志、用户在线 *** 作监控等，但原理都基于上述两类日志，只是在统计上有所区分。

再次，我们来看下客户端的数据采集。与网页日志对应的，是手机应用为基础的客户端日志，由于早期手机网络通讯能力较差，因而SDK往往采用延迟发送日志的方式，也就是先将日志统计在本地，然后选择在Wifi环境下上传，因而往往会出现统计数据延迟的情况。现如今网络环境好了很多，4G、5G流量充足，尤其是视频类APP基本上都是一直联网，因而很多统计能够做到实时统计。

客户端的日志统计主要通过SDK来完成，根据不同的用户行为分成不同的事件，“事件”是客户端日志行为的最小单位，根据类型的不同，可以分为页面事件（类比页面浏览）和控件点击事件（类比页面交互）。对于页面事件，不同的SDK有不同的方式，主要区别为是在页面创建时发送日志，还是在页面浏览结束后发送日志，区别在于业务统计是否需要采集用户的页面停留时长。

页面事件的统计主要统计如下三类信息：

埋点其实还需要考虑数据上传的方案，批量的数据可以通过Flume直接上报，流式的可以写到Kafka，或者直接使用Flink来处理。这些框架相关的内容不是本文考虑的重点，有兴趣的可以自行查阅资料。

有了指导思路和技术方案后，我们就可以着手制定相应的数据埋点流程规范了。

笼统上，流程规范会分成五个步骤，即需求评审、埋点申请、技术开发、埋点验证、发布上线。

第一步，需求评审。

前文提到过，数据埋点的方案一旦确定，返工和排查问题的成本都很高，但数据埋点之后的分析工作，又涉及到了PD、BI、算法、数据等多个角色。因此非常有必要，将需求内容和数据口径统一收口，所有人在一套口径下，将需求定义出来，随后业务侧再介入，进行埋点方案的设计和开发。

以前文提到的4W1H模型为例，常见的记录内容如下：

最后我们统计时，按照上述约定，统计用户在某个时间和地点中，看到了哪些信息，并完成了怎样的动作。上下游的相关人员，在使用这份数据时，产生的歧义或者是分歧，会小很多。

第二步，埋点申请

当下的热门应用，大多是以超级APP的形式出现，比如微信、淘宝、支付宝、抖音，超级APP会承载非常多的业务，因此技术方案上会十分统一。

因此，当我们的技术方案确定后，通常要在相应的埋点平台上，进行埋点申请。申请的内容包括分配的SPM、SCM码是什么，涉及到的平台是哪些，等等。SPM、SCM是什么，有什么用，同样可以自行查阅。

第三步，技术开发

当需求确定、申请通过后，我们就可以开始开发动作了，这里基本上是对研发同学进行约束。埋点的开发，简单讲，是分成行为埋点和事件埋点两个大类，每一类根据端的不同进行相应的开发。具体的技术方案详见前文01章节。

详细的设计规范，是需要留文档的，因为代码不能反应业务的真实意图，而不论是事后复盘与业务交接，都需要完整的文档来阐述设计思路。

第四步，埋点验证

埋点的验证很关键，如果上线后才发现问题，那么 历史 数据是无法追溯的。

验证有两种方式，一种是实时的功能验证，一种是离线的日志验证。

实时功能验证，指功能开发好后，在灰度环境上测试相应的埋点功能是否正常，比如点击相应的业务模块，日志是否会正确的打印出来。通常而言，我们需要验证如下三个类型的问题：

除去实时验证，我们也需要把日志写到测试环境中，查看数据上报的过程是否正确，以及对上报后的数据进行统计，侧面验证记录的准确性，如统计基本的PV、UV，行为、事件的发生数量。

很多时候，数据是需要多方验证的，存在一定的上下游信息不同步问题，比如对某个默认值的定义有歧义，日志统计会有效的发现这类问题。

第五步，发布上线。

应用的发布上线通常会有不同的周期，例如移动端会有统一的发版时间，而网页版只需要根据自己的节奏走，因此数据开始统计的时间是不同的。最后，应用应当对所有已发布的埋点数据，有统一的管理方法。

大多数时候，数据埋点的技术方案，只需要设计一次，但数据准确性的验证，却需要随着产品的生命周期持续下去，因此仅仅依靠人肉来准确性验证是不够的，我们需要平台来支持自动化的工作。埋点的准确性，大体有两种方法保障：一种是灰度环境下验证真实用户数据的准确性；另一种则是在线上环境中，验证全量数据的准确性。因此，发布上线之后，后续的管理动作，应该是对现有流程的自动化管理，因为团队大了，需要埋点的东西多种多样，让平台自己测试、自动化测试，就是很多测试团队必须走的路

以上就是关于明明就是iOS系统的，结果微信要安装苹果定制版的居然提示这个，求助怎么回事，有谁知道的求告知全部的内容，包括:明明就是iOS系统的，结果微信要安装苹果定制版的居然提示这个，求助怎么回事，有谁知道的求告知、iOS自动化真机测试验证环境过程中常见问题解析、什么软体可以改变安卓手机来电接听方式等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！