本文來自微信公眾號： 少數(shù)派 ，作者：克萊德，原文標題：《App 再也不能亂讀你的通訊錄，Android 17 這些升級值得關(guān)注》

Android 17在Beta測試階段就給人一種「無從下手」的感覺：或許是因為Google現(xiàn)在每年都會給每個大版本推送兩次更新，而每次正式版之前的測試周期被壓縮到只有2-3個月，即便讓Gemini來寫代碼，應(yīng)該都不太可能端出太多讓人眼前一亮的新東西。

Android 17更新時間線

上周Beta 4版本的發(fā)布，意味著Android 17目前已經(jīng)進入了Platform Stability階段，所以在下半年的測試開啟前我們應(yīng)該都看不到什么新東西了。

那Android 17在過去兩個多月時間里都加了哪些新功能呢？交互這邊我們或許能（在Pixel設(shè)備上先）看見的：聯(lián)系人選擇器、本地網(wǎng)絡(luò)權(quán)限、分離式語音助理音量、大屏優(yōu)化、接力API，看不見的底層那邊則有MessageQueue無鎖化、基于設(shè)備總RAM的應(yīng)用內(nèi)存限制、usesClearTraffic棄用、限制隱式URI授予、旋轉(zhuǎn)后恢復默認輸入法可見性……

這篇文章我們就來展開聊聊，就當是給Android 17的首次正式版做個「前瞻」了。

▍碰一碰互傳

Tap to Share并不是什么已經(jīng)正式確認的Android 17功能，所以我們上面并沒有提到它。

Android Authority最早在3月底的One UI 9（基于Android 17）泄漏固件中發(fā)現(xiàn)了這個功能，9to5Google則在后續(xù)拿到了Pixel設(shè)備這邊的功能截圖和交互動畫。

One UI和Pixel OS中的碰一碰互傳功能

iOS用戶看到Tap to Share的功能示意圖，可能會想起iOS 17上線的名片投送（NameDrop）功能，而稍有年紀的Android用戶則會第一時間想起Android Beam——Google在2011年發(fā)布的、基于藍牙傳輸協(xié)議的跨設(shè)備分享方案。Android Beam借助NFC功能和「碰一碰」這個交互，精簡了藍牙傳輸分享這個流程中最為繁瑣的搜索配對流程。

盡管交互方式頗具前瞻性，Android Beam里子依然是藍牙傳輸，在十多年前的Android手機市場，這種設(shè)計簡直是把能疊的buff都疊滿了。一方面NFC在非旗艦Android機型上并非標配，另一方面藍牙傳輸?shù)乃俣然疽馕吨c大文件分享、傳輸無緣。所以后續(xù)的故事也說得通：三星在Android Beam的基礎(chǔ)之上開發(fā)了基于Wi-Fi傳輸協(xié)議的S Beam，Google則進一步在「親兒子」三星理念的影響下推出了Nearby Share（現(xiàn)在改名叫Quick Share）。Android Beam就像一個技術(shù)預覽，在Android系統(tǒng)的角落里閑置了八年后，在Android 10中被徹底隱藏，并且在2023年的Android 14正式版中從Android代碼中完全移除。

交互動效

考慮到今年Quick Share已經(jīng)成熟到可以兼容AirDrop了，Google再借Android Beam的理念幫它「打包」一個上層交互的想法也算是合情合理，甚至有點Android Beam精神傳承的味道——至少在看到動畫效果之前我是這么想的。

▍聯(lián)系人選擇器

盡管在國產(chǎn)應(yīng)用這邊的采用率有限，但Android系統(tǒng)近幾年在「照片選擇器」這個功能上的投入還是值得肯定的：從最初作為Android 13正式版的新功能上線，到后續(xù)作為Google服務(wù)的組件完成對老機型的向下兼容，照片選擇器作為一項「借鑒iOS」的隱私設(shè)計，在鋪開的過程中算是結(jié)合到了Android生態(tài)機型多、版本碎片率高的客觀現(xiàn)實。

Android 17的聯(lián)系人選擇器或許也會成為類似的功能。Google在這里借鑒了Apple在2024年的iOS 18中推出的Contact Access授權(quán)模式，在Android 17上為聯(lián)系人選擇這一操作準備了一套更為隱私友好的標準化界面，用戶通過這個系統(tǒng)提供的標準化界面來選擇聯(lián)系人披露范圍。

聯(lián)系人選擇器的三種選擇模式

作為一個借鑒iOS平臺而來的特性，Android 17的聯(lián)系人選擇器也有一些相比iOS更加細致的設(shè)計：在iOS中，聯(lián)系人訪問權(quán)限的披露粒度是聯(lián)系人條目，即我們可以選擇開放給應(yīng)用的最小信息單元是某個聯(lián)系人條目；而Android 17這邊雖然看上去功能類似但披露粒度更細，應(yīng)用需要在intent里首先按照具體的聯(lián)系人信息字段（比如電話號碼、郵箱、生日）聲明自己要訪問的聯(lián)系人信息類別，用戶通過聯(lián)系人選擇器選擇聯(lián)系人披露范圍后，應(yīng)用才能拿到這些聯(lián)系人信息中的對應(yīng)字段。

iOS中的聯(lián)系人選擇器

不過「非強制性」這一點依然是Android 17聯(lián)系人選擇器功能目前看來最大的未知因素，正如照片選擇器至今依然沒有完全替代媒體文件訪問權(quán)限一樣，Android 17的聯(lián)系人選擇器也并非READ_CONTACTS聯(lián)系人訪問權(quán)限的直接替代。Google目前只是做了一個系統(tǒng)層面的標準界面，適配了Android 17的應(yīng)用可以選擇采用這套隱私友好的聯(lián)系人信息獲取流程，未適配Android 17的應(yīng)用如果原本在用Intent.ACTION_PICK，在新系統(tǒng)中也可以自動獲得新界面——但聯(lián)系人訪問權(quán)限還在，不想管Android平臺原生特性的應(yīng)用依然可以不管。

考慮到Google后續(xù)的確有通過拆分媒體訪問權(quán)限、降低系統(tǒng)版本要求等手段來推動照片選擇器的適配，這里不妨就留個希望，希望聯(lián)系人選擇器同樣也是入口先行，我們應(yīng)該能很快在下半年的更新中看到Google對聯(lián)系人讀取權(quán)限動刀吧。畢竟聯(lián)系人訪問權(quán)限也是一個不小的隱私泄露源頭。

▍本地網(wǎng)絡(luò)權(quán)限

和聯(lián)系人選擇器類似，Android 17同樣也引入了本地網(wǎng)絡(luò)權(quán)限。

首先必須明確一點：大家在iOS系統(tǒng)中看見的、大部分應(yīng)用發(fā)起的本地網(wǎng)絡(luò)權(quán)限申請，本質(zhì)上依然是想借助局域網(wǎng)發(fā)現(xiàn)能力做局域網(wǎng)設(shè)備探測、用戶畫像和用戶指紋識別，最終是要用來給你做個性化廣告追蹤和推薦的。我們的主張和當初文章中的一樣：就大部分應(yīng)用而言，它們都不需要給本地網(wǎng)絡(luò)權(quán)限。

iOS中的本地網(wǎng)絡(luò)權(quán)限

關(guān)聯(lián)閱讀：iOS 14新增的本地網(wǎng)絡(luò)權(quán)限，要開給第三方App嗎？

Google在Android 17中正式將本地網(wǎng)絡(luò)權(quán)限納入了NEARBY_DEVICES權(quán)限組當中，并且所有面向Android 17及以上系統(tǒng)版本開發(fā)的新應(yīng)用，默認情況下都會被屏蔽本地網(wǎng)絡(luò)訪問行為，包括TCP連接、UDP單播、多播、廣播等，甚至無法解析.local這樣的本地域名。這里Google同樣建議有特定需求的開發(fā)者選擇更為隱私友好的中轉(zhuǎn)方案，例如借助Android系統(tǒng)級Cast SDK中的輸出切換器來完成投屏，而如果是智能家居控制、IoT管理這類需要持續(xù)、廣泛訪問局域網(wǎng)的需求，再借助本地網(wǎng)絡(luò)權(quán)限向用戶請求授權(quán)。

我們也在這里第一次拋出本文的「數(shù)學題」：按照Google Play商店對應(yīng)用目標SDK等級的要求，2027年8月31日之后，Google Play商店中的應(yīng)用都必須請求本地網(wǎng)絡(luò)訪問權(quán)限。

▍大屏優(yōu)化

說「大屏優(yōu)化」其實有點寬泛，但以Android 17為目標平臺進行適配的新應(yīng)用，在Android 17上都將變成完全可由用戶隨意「拿捏」的形狀：屏幕方向、尺寸調(diào)整和寬高比限制，將不再適用于最小寬度大于600dp的顯示屏，應(yīng)用在大屏上運行時，默認會填滿整個顯示窗口，無論寬高比或用戶的首選屏幕方向如何。

這也給那些寫死應(yīng)用方向、強迫用戶旋轉(zhuǎn)內(nèi)屏使用、用「放大」替代「大屏適配」工作的做法下了整改通知：這里第二次拋出上面那道「數(shù)學題」，2027年8月31日之后，Google Play商店中僅適配移動端小屏交互的應(yīng)用將不復存在。

結(jié)合這些年折疊屏設(shè)備宛如抽獎般的實際體驗，可以說2027年這個時間窗口其實相當溫和，并且說到底Google也只是拿掉了一條「捷徑」——真有頭鐵的開發(fā)者，依然可以不做什么自適應(yīng)布局，任由應(yīng)用在大屏設(shè)備上縮放、變形，輕則設(shè)備使用形態(tài)轉(zhuǎn)換（比如外屏到內(nèi)屏）時應(yīng)用重載當前界面丟失，重則應(yīng)用內(nèi)相機方向混亂，圖像、文本完全不具備可讀性……

但話說回來，今年如果Apple按預期推出折疊屏設(shè)備，多多少少能幫到咱Android大屏應(yīng)用適配一把吧（笑）。

▍接力API

各種形態(tài)的設(shè)備越來越多，系統(tǒng)級接力API（Handoff）其實也早該端出來了：跨設(shè)備「接力」在Apple、華為鴻蒙生態(tài)中已布局多年，但大量的Android廠商依然需要一個平臺層面的支持來打破屏障。

在返回手勢那篇文章中我們提到，Android應(yīng)用中大部分看得見、摸得著的交互，都是由活動（activity）來承載的。Android 17的接力API也用到了這一基礎(chǔ)架構(gòu)，開發(fā)者只需要給想要接力的活動窗口打上特定標注，另一設(shè)備上的任務(wù)欄或啟動器中就會出現(xiàn)接續(xù)操作的提示。

應(yīng)用信息設(shè)置中已經(jīng)有了「任務(wù)連續(xù)性」選項

當前視頻播放到了幾分幾秒、文檔滾動到了哪一行、或者是購物車里勾選了哪幾樣商品，都能通過這個數(shù)據(jù)包傳遞到另一設(shè)備上、調(diào)用同一應(yīng)用的對應(yīng)活動窗口打開，并且Google也考慮到了一些比較特殊的使用情況，比如兩端如果都裝了同一App，接收端可以直接通過Deep Link啟動實現(xiàn)快速恢復，如果接收端沒裝App系統(tǒng)則會拉起瀏覽器，打開開發(fā)者在HandoffActivityData里設(shè)好的URL，實現(xiàn)「無縫降級」；另外還有僅傳遞URL鏈接的URL Handoff，適合跨設(shè)備書簽同步、新聞閱讀等場景。

目前Pixel啟動器中的瀏覽器標簽頁恢復功能應(yīng)該也是類似的實現(xiàn)

對國內(nèi)用戶來說，接力API其實也有一個變數(shù)：Google這套設(shè)備間活動流轉(zhuǎn)的機制顯然是基于Google服務(wù)和Google賬號搭建的，對Google Play相關(guān)服務(wù)的依賴目前也不明朗?？紤]到部分搭載了Google服務(wù)的國產(chǎn)機型在實際體驗方面均有縮水（比如Quick Share），只能祈禱接力API對Google服務(wù)的依賴低一點、或者國產(chǎn)Android廠商能做一些本地化適配吧。

▍其他改動

正如開頭所言，目前Android大版本更新的迭代速度加快，越來越多的新特性要么放在下半年，要么就干脆成為Pixel設(shè)備和三星設(shè)備獨占，其他廠商還得再等上個一年半載。看得見、摸得著，讓人眼前一亮的東西越來越少。

除了上述內(nèi)容，Android 17值得一提的新特性還有：

• 實時更新類通知新增了語義著色API，開發(fā)者可以在實時更新通知中用綠、橙、紅、藍四種預置顏色來設(shè)置符合使用情境的色彩樣式

  
  

• 針對助理應(yīng)用引入了專用的助理音量音頻流，助理聲音通過USAGE_ASSISTANT播放，音量調(diào)節(jié)和其他類別的音頻分離并支持單獨控制

  
  

可以單獨控制智能助理的語音音量了

• 引入了基于設(shè)備總RAM的應(yīng)用內(nèi)存限制，極端內(nèi)存泄漏等情況下的系統(tǒng)穩(wěn)定性表現(xiàn)應(yīng)該會更好，并且影響范圍更可控

  
  

• 音頻框架會對后臺音頻互動強制執(zhí)行限制，以確保這些更改是由用戶有意發(fā)起的（比如媒體播放），其他「非法」音頻請求會以靜默方式失敗，坊間流傳的「音頻播放?；睢剐∶钫锌赡軙?，各種奇奇怪怪的音樂播放被打斷的情況應(yīng)該會更少

  
  

• 底層MessageQueue完成了無鎖化重構(gòu)，從線程消息請求的底層層面減少了UI自動化執(zhí)行時的摩擦，感興趣的朋友可移步具透Plus。

  
  

以上便是Android 17正式版值得關(guān)注的主要更新，雖然大多數(shù)更新已是板上釘釘，但最終體驗還是得等到5月的Google I/O大會。我們到時候見！