🔧 阿川の電商水電行

Shopify 顧問、維護與客製化

💡

小任務 / 單次支援方案

單次處理 Shopify 修正／微調

⭐️

維護方案

每月 Shopify 技術支援 + 小修改 + 諮詢

🚀

專案建置

Shopify 功能導入、培訓 + 分階段交付

👉 瞭解詳情 / 免費諮詢

小編精選 - 技術文章翻譯 · 02月27日

Android 17 有什麼需要適配的？ 2026 Android 禁止側載又是什麼？

Android 17 有什麼需要適配的？2026 Android 禁止側載又是什麼？

Android 官方已經發布了 Android 17 的相關適配文檔，其中有不少值得提前關注的內容，另外在去年谷歌也發布過 Android 開發者認證的通告，沒認證的應用將無法安裝，而時間節點也正好是 2026 。

Android 17 適配

All Apps 影響

`usesCleartextTraffic` 的棄用規劃

注意，這個變更在這 Android 17 這裡不是立刻更改，而是會在未來版本計劃棄用 usesCleartextTraffic，所以官方建議開發者遷移到 Network Security Config 來按域名白名單方式允許 HTTP。

不會還有個需要注意的是，Network Security Config 只支持 API 24+，低於 24 的 app 可能需要兩者都配，同時這個變更並不是針對 target 的，也就是就算你不用 target android 17 ，也會在未來受到影響。

“隱式 URI grant” 的限制

這個也是未來的變更預警，官方計劃在 Android 18 上生效，在之前當 app 用 Send / SendMultiple / ImageCapture 攜帶 URI 啟動 intent 時，系統當前會“自動”把讀寫 URI 權限給目標 app，所以 Android 17 開始建議開發者別依賴系統自動授予，而要顯式授予 URI 權限。

在 Android 17 之前，當你發送一個帶有 ACTION_SEND（分享）的 Intent 時，系統看到你帶了個 URI，會自動地幫目標應用開了讀寫權限。

現狀： 開發者即便忘了寫 FLAG_GRANT_READ_URI_PERMISSION，代碼通常也能跑通
Android 18 ： 如果你不顯式授權，目標應用（接收方）打開 URI 時會可能會直接報 SecurityException

這其實也貼合未來的 Android 將更深度地集成類似 Gemini 的系統級 AI 的場景，這些 AI 能夠跨應用讀取螢幕內容、處理 Intent，而如果系統允許隱式授權，那麼 AI 在處理複雜的鏈式任務（例如：從 A 應用提取圖片 -> B 應用修圖 -> C 應用分享）時，權限鏈路風險會大的提升。

顯式授權建立了一個 “權限存根” ，可以讓 AI 介入時，方便系統清晰地追蹤到：是用戶在 A 應用授權了 AI 讀取這個檔案。

對於開發者來說就是：任何走 intent + content URI 之類，如分享/拍照回傳的鏈路都應該顯式 grantUriPermission / flags。

旋轉等配置變化後，系統不再“恢復之前的鍵盤顯示狀態”

從 Android 17 開始：如果發生配置變化（比如旋轉），且你的 app 自己沒有處理，那麼系統不會恢復之前 IME（軟鍵盤）的狀態。

如果開發者希望旋轉後鍵盤仍然彈出，需要顯式在 windowSoftInputMode 或在 onCreate() / onConfigurationChanged() 裡主動請求。

Background audio hardening

Android 17 上後台音頻收緊，如果 app 在沒有可見 Activity時還想控制音頻（播放/請求焦點/調音量），需要：

运行一个 前台服務（FGS） ，且不是 SHORT_SERVICE；
並且這個 FGS 必須帶有 while-in-use（WIU）能力：要麼因 MediaSessionEvent 啟動，要麼在 app 可見時由用戶觸發啟動

當然，異常情況的反饋也很“陰間”

播放與音量相關 API 可能靜默失敗（不拋異常、也不給失敗信息）
Audio focus 請求會返回 AUDIOFOCUS_REQUEST_FAILED

針對 targetSdk=37

MessageQueue 無鎖”實現

針對 targetSdk 為 Android 17 的場景，官方引入了名為 DeliQueue 的新架構，將傳統的基於單一鎖（Monitor Lock）的 MessageQueue 替換為無鎖數據結構，它使用 Treiber 堆進行無鎖消息插入，並結合最小堆進行單線程處理。

目的是減少主線程鎖競爭、降低掉幀，但可能會破壞那些反射訪問 MessageQueue 私有字段/方法的代碼，實際上一般正常使用無礙，只會覺得性能變好了，特別是 Flutter 的 MethodChannel ，無鎖 MessageQueue 大概率會提升不少性能，但是如果你用過什麼黑魔法 hack 過 MessageQueue ，那就很可能異常了。

比如你通過反射訪問私有字段 mMessages ，那麼這部分代碼都會失效，就算 mMessages 字段為了兼容性依然存在，但它也會永遠返回 null。

BAL（後台啟動 Activity）進一步收緊，擴展到 `IntentSender`

官方把 Background Activity Launch 相關保護擴展到 IntentSender，並要求從舊常量遷移到更細粒度的模式，例如 MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE

Localhost protections：新增安裝時權限 `USE_LOOPBACK_INTERFACE`

這是一個安裝時權限，所以它的限制比較多，它引入了 USE_LOOPBACK_INTERFACE：在跨 app / 跨 profile 的 127.0.0.1 / ::1 通信默認被阻斷，需要通信雙方都在 manifest 裡聲明該權限並獲得同意，當然，同一 app 內部 loopback 不受影響。

而在 Target 是 17 且缺失權限時，socket 可能直接 EPERM。

默認啟用 Certificate Transparency（CT）

現在在 Target 是 17 時，證書透明度 (CT) 會默認開啟，CT 是一套用於記錄和審計數字證書發行情況的系統：

要求所有的證書頒發機構（CA）必須將他們簽發的每一個證書都公開登記到一個“審計日誌”中
防止 CA 被黑客攻擊或錯誤地簽發了假證書（例如，有人非法給 google.com 簽發了個證書並嘗試進行中間人攻擊）

當你的應用 targetSdkVersion 升級到 37 後，系統會對所有 HTTPS 連接強制執行 CT 檢查，如果伺服器返回的 SSL 證書沒有被記錄在公共 CT 日誌中（或者沒有附帶有效的 SCT 簽名），Android 系統會直接拒絕連接。

而在 Android 17 之前，你需要通過 network_security_config.xml 手動加入 <certificateTransparency enabled="true" />，而在 Android 17 之後，這個標籤默認就是 true。

雖然 Flutter 引擎使用的是 C++ 的 BoringSSL，但在 Android 平台上，系統可能會在底層（Socket 級別）執行某些安全策略，或者 cronet_http 等場景受到影響。

Safer Native DCL 擴展到 native

Android 14 的 “Safer Dynamic Code Loading” 原本覆蓋 DEX/JAR，而 Android 17 Target 版本下會擴展到 native：用 System.load() 加載的 native 檔案必須是只讀，否則拋 UnsatisfiedLinkError。

官方的目的很明確，那就是禁止你動態加載代碼。

大屏（sw>600dp）：忽略方向/可調整大小/比例限制

對大屏的“強制自適配”變成標準行為，Target 17 後，Android 16 曾提供的臨時 opt-out 被移除，這個我們在之前就聊過，實際上從 Android 16 開始，Google 將逐步淘汰用於限制應用螢幕方向和大小調整的清單屬性及運行時 API ，而 Android 17 開始，這個退出標誌不再有效：

<activity ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
  ...
</activity>

<application ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>

當然，還是存在一定規則範圍

僅對 sw>600dp（大屏）生效；
目標 Android 17+ 時，方向/可調大小/比例限制在大屏上不再起作用，app 會填滿窗口
Android 16 的臨時 opt-out 在 Android 17 被移除。

也就是大屏設備全屏/多窗口模式下，這些會被忽略： screenOrientation、resizableActivity、minAspectRatio、maxAspectRatio、setRequestedOrientation()、getRequestedOrientation()；並且一堆 portrait/landscape 取值都忽略。