您了解Android O中对设备标识符的改变吗？

　　如果给 Android 撰写一个编年史，那每年的 都是一个新的 Android 年的开启，它预示着 Android 在后续一年新的方向和趋势。本次课课家将为大家带来Android O中对设备标识符的改变，大家一定要认真阅读!

　　Android O 引入若干改进，帮助用户控制标识符的使用。这些改进包括：

　　限制使用不可重置的设备范围标识符

　　更新 Android O WLAN 堆栈，更改 Pixel、Pixel XL 和 Nexus 5x 手机所使用的 WLAN 芯片组固件，以便在探测请求中随机分配 MAC 地址

　　更新应用请求帐号信息的方式，提供更多面向用户的控制

　　设备标识符变更

　　以下是 Android O 中对设备标识符所做的部分变更：

　　Android ID

　　在 O 中，对于设备上的每个应用和每个用户，Android ID(Settings.Secure.ANDROID_ID 或 SSAID)均有不同的值。需要使用设备范围的标识符的开发者应改用可重置的标识符，例如广告 ID，以便赋予用户更多的控制权。广告 ID 还提供了面向用户的设置，用于限制广告跟踪。

　　此外，在 Android O 中：

　　只要软件包名称和签名密钥相同，在软件包卸载或重新安装时，ANDROID_ID 的值不会改变。应用可以依靠此值保持每次重新安装之后的状态。

　　如果应用安装在运行更早版本 Android 的设备上，则除非卸载并重新安装该应用，否则，在设备更新至 Android O 之后，应用的 Android ID 将保持不变。

　　只有在设备恢复出厂设置或者签名密钥在卸载和重新安装事件期间轮换时，Android ID 的值才会改变。

　　只有预装 Google Play 服务和广告 ID 的设备制造商才需要更改此值。其他设备制造商可以提供一个替代的可重置 ID 或者继续提供 ANDROID ID。

　　Build.SERIAL

　　为了与访问 IMEI 所需的运行时权限保持一致，对于针对 Android O 或更新版本的应用，现已弃用 android.os.Build.SERIAL。它们可以改为使用新的 Android O API，即Build.getSerial()，只要调用方拥有 PHONE 权限，该函数将返回实际序列号。在未来版本的 Android 中，针对 Android O 的应用所查询到的 Build.SERIAL 将显示为“UNKNOWN”。为避免中断旧版应用的正常工作，针对以前版本 Android 的应用所查询到的设备序列号仍和以前一样。

　　Net.Hostname

　　Net.Hostname 提供设备的网络主机名。在之前版本的 Android 中，网络主机名的默认值和 DHCP 主机名选项的值均包含 Settings.Secure.ANDROID_ID。在 Android O 中，net.hostname 为空，DHCP 客户端在 IETF RFC 7844 之后，不再发送主机名(匿名保护的个人资料)。

　　Widevine ID

　　对于搭载 O 的新设备，Widevine 客户端 ID 将为每个应用软件包名称和网络源(对于网络浏览器)返回一个不同的值。

　　特殊的系统和设置属性

　　除了 Build.SERIAL 之外，还有其他设置和系统属性在 Android O 中不可用。这些包括：

　　ro.runtime.firstboot：在上次滑屏或上次启动之后第一次启动的毫秒级时间戳

　　htc.camera.sensor.front_SN：相机序列号(在某些 HTC 设备上可用)

　　persist.service.bdroid.bdaddr：蓝牙 MAC 地址属性

　　Settings.Secure.bluetooth_address：设备蓝牙 MAC 地址。在 O 中，只有拥有 LOCAL_MAC_ADDRESS 权限的应用才可以使用此属性。

　　在 WLAN 探测请求中，随机分配 MAC 地址

　　我们携手安全研究人员1 ，共同针对 Google Pixel 和 Nexus 5X 设备中的芯片组固件所产生的 WLAN 扫描流量设计了可靠的 MAC 地址随机分配功能。随后，Android Connectivity 团队又与制造商合作，更新这些设备所使用的 WLAN 芯片组固件。

　　Android O 将这些固件变更集成到 Android WLAN 堆栈中，因此，使用这些更新过固件的芯片组并运行 O 或更高版本 Android 的设备将可以充分利用这些变更。

　　以下是我们对运行 O 及更高版本 Android 的 Pixel、Pixel XL 和 Nexus 5x 固件所做的一些变更：

　　在 WLAN 从接入点断开时，每次扫描 WLAN 时，手机都会使用新的随机分配的 MAC 地址(无论设备是否处于待机状态)。

　　每次扫描的初始数据包序列号也是随机生成的。

　　不必要的探测请求信息元素已被移除：所要求的信息元素仅限于 SSID 和 DS 参数集。

　　getAccounts API 中的变更

　　在 Android O 及更高版本中，拥有 GET_ACCOUNTS 权限不再足以获取对设备上已注册帐号列表的访问权。应用必须使用管理特定帐号类型的应用所提供的 API，或者用户必须通过帐号选择器 Activity 授予访问此帐号的权限。例如，Gmail 可以访问设备上已注册的 Google 帐号，这是因为 Google 拥有 Gmail 应用，但用户可能需要授予 Gmail 对设备上注册的其他帐户信息的访问权。

　　要获得帐号访问权限，针对 Android O 或更高版本的应用应使用 AccountManager#newChooseAccountIntent() 或特定于身份验证器的方法。目标 SDK 版本较低的应用仍可使用当前的流程。

　　在 Android O 中，应用也可以使用 AccountManager.setAccountVisibility()/ getVisibility() 方法来管理这些应用所拥有的帐号的可见性策略。

　　此外，LOGIN_ACCOUNTS_CHANGED_ACTION 广播已弃用，但在 Android O 中仍可工作。应用应使用 addOnAccountsUpdatedListener() 来获取运行时帐户的更新，以获取应用指定的帐户类型列表。

　　知识分享：

　　生来就为无处不在的 Android

　　Android Wear、Android Auto、Android TV … 这些 Android 打头的不同设备解决方案目标是为了什么?这和市面上各式各样的 Android 电视、Android 手表、Android 盒子有什么不同?要说清楚这个，先要聊一点看上去不大相关的话题，就是“可移植性”。

Android 架构图

　　从技术角度来看，Android 在整体架构设计上天生具有良好的可移植性，能够较为轻松的适配到不同的硬件设备上。如图 1 所示，Android 系统其实是构建在 Linux 内核之上的一个「运行时」(Android Runtime)，由于 Linux 具有强大的可移植性，几乎可以嵌入到任何一个设备中运行，所以移植 Android 到新的硬件设备只需实现新的硬件抽象层(Hardware Abstraction Layer，HAL)，按 Android 定义的标准为硬件上的 WiFi、相机等设备撰写驱动，而不需要修改上层的相关实现，难度大幅降低。

　　了解这一点就可以知道，将 Android 移植到不同的设备上并不是困难的事情，这也是非官方的 Android 电视、盒子可以很容易实现的原因。正是基于此，Android Wear 这些项目期望解决的并不是移植的问题，而是移植以后需要考虑的问题，包括

　　统一的交互模式。之前不同厂商定制的电视、手表等设备，缺少统一的交互模式和控件库的支持，不仅对于用户而言增加了学习成本，对于开发者而言，也难于基于不同的实现机制来构建应用，生态系统也就难于构建。Material Design 为不同的设备构建了统一的“设计语言”，在 Android Wear、Android TV 等项目中，在 Material Design 的设计语言基础上，针对不同设备的交互特征提供了界面库支持，使得应用适配不同的设备变得简单起来。尤其是，Android 还将 Google 的语音识别服务带到了这些不同的设备上，使得很多复杂的交互都统一到了“说话就好”的交互模式下。

　　简单而统一的互联互通。不同设备有不同特征，在很多场景下都需要将各式设备“连接”起来，一起工作，才能发挥更大的价值。而现在如果你去买台第三方 Android 电视，要么是无法与其他 Android 设备通信，要么就是用各自不同的方案来解决，对用户来说学习成本高，对开发者来说则是不友好。而 Android Wear 这些解决方案，将互联互通实现到了 Google Play 服务中，实现到了 Android 系统中，使得连接变得简单而无缝，为开发者提供了更多的可能性。

　　更好的解决核心需求。为什么出门要戴手表?为什么汽车需要车载系统?为什么客厅要摆电视?手表、电视这样的设备原本就有它需要解决的核心需求，引入 Android 到这些设备，本质上是为了更好的解决用户在这些场景的这些核心需求。Android Wear、Android TV 这些项目一方面是引入了大量 Google 服务来解决这些设备的核心需求，另一方面也为开发者提供了易用的、针对不同硬件场景的 API 来接入更多好的服务，一并更好满足这些需求。

　　在各个设备上解决这些问题，是 Android Wear、Android Auto、Android TV 这些解决方案共同的目标，以 Android Wear 为例，来看看 Android 是如何设计和解决这些问题的。

　　后台应用限制：

　　Android O将进一步改善在Android Marshmallow和Nougat系统中不断增强的后台应用休眠功能，这是一种能够改善电池续航能力的特性，将运行在后台、但是用户已经不再使用的应用做“休眠”处理。虽然对广播、后台服务和位置更新等功能有所限制，但是却可以很好的改善设备潜在续航能力。

　　通知分类管理：

　　谷歌从未停止过对Android系统通知中心的改进，这是一件好事，Android O当然也不例外。改进的通知管理功能，可以根据不同类型的app对通知进行分类。比如用户可以轻松的一键简直新闻类或者游戏类应用的通知消息，从而可以精细化的打造自己想要的通知中心。

　　自动填表API：

　　Android O还对应用程序增加了自动填表的API接口，这样用户可以很容易的在各种需要登录信息的App中更轻松的登录账户，而这个功能有点类似于密码管理类的应用。目前这个功能需要API接口，需要开发者二次开发才可以实现，这对于总要登录不同账户的用户来说，节省了不少时间。

　　小结：对于开发者而言，这听上去是很幸福的消息，“一次开发多处部署”的移动开发时代，就这样到来了。当然如果大家还要了解更多相关方面的详细内容的话，课课家教育平台欢迎大家的咨询!