2. 程式人生 > >Android修煉之Pie 適配的搬運工

Android修煉之Pie 適配的搬運工

阿新 • • 發佈：2018-12-12

自嘲時刻

Android P正式版（以下稱為Pie）已經正式上線了，各大廠商已經開始了系統升級工作，咱做上層開發的也得跟上節奏。當然了，新版本所有的行為更改內容都可以在官網上找到，對於其中如何繞開非SDK介面限制的問題，也有各路大神給出瞭解決方案。所以，我只能當搬運工了（偷笑ing）。下面我會結合現有的開發經驗，聊聊Pie中對我們開發影響較大的一些更新，重頭戲還是適配齊劉海和非SDK介面限制。

行為變更

這裡只會列出部分行為變更（僅代表個人見解），感興趣的同學直接去官網檢視。

通知渠道設定更新

更新內容：

  • 遮蔽渠道組：現在，使用者可以針對某個應用在通知設定中遮蔽整個渠道組。 您可以使用 isBlocked() 函式確定何時遮蔽一個渠道組，從而不會向該組中的渠道傳送任何通知。
  • 全新的廣播 Intent 型別：現在，當通知渠道和渠道組的遮蔽狀態發生變更時，Android 系統將傳送廣播 Intent。 擁有已遮蔽的渠道或渠道組的應用可以偵聽這些 Intent 並做出相應的迴應。

影響：APP的推送功能可能需要適配，Pie中可以知道渠道組的狀態了。

ImageDecoder & AnimatedImageDrawable

更新內容:

  • ImageDecoder 類，可提供現代化的影象解碼方法。 使用該類取代 BitmapFactory 和 BitmapFactory.Options API。ImageDecoder 讓您可通過位元組緩衝區、檔案或 URI 來建立 Drawable 或 Bitmap。
  • AnimatedImageDrawable 類，用於繪製和顯示 GIF 和 WebP 動畫影象。 AnimatedImageDrawable 的工作方式與 AnimatedVectorDrawable 的相似之處在於，都是渲染執行緒驅動 AnimatedImageDrawable 的動畫。

影響：對APP級別的影響應該較小，畢竟大部分都是使用第三方庫來實現圖片資源的載入。可能對SDK影響較大，SDK裡基本都是自己寫Image壓縮解碼邏輯，所以可以考慮使用。

統一生物識別身份驗證對話方塊

更新內容: 在 Android 9 中，系統代表您的應用提供生物識別身份驗證對話方塊。 該功能可建立標準化的對話方塊外觀、風格和位置，讓使用者更加確信，他們在使用可信的生物識別憑據檢查程式進行身份驗證。

影響：接入了生物識別功能的（如：指紋）APP就有統一的提示對話方塊了，挺好的。就是不知道標準的風格是否適合各種應用。

螢幕旋轉

更新內容:

  • 為避免無意的旋轉，我們新增了一種模式，哪怕裝置位置發生變化，也會固定在當前螢幕方向上。 必要時使用者可以通過按系統欄上的一個按鈕手動觸發旋轉。
  • 從 Android 9 開始，對縱向旋轉模式做出了重大變更。縱向模式已重新命名為旋轉鎖定，它會在自動螢幕旋轉關閉時啟用。當裝置處於旋轉鎖定模式時，使用者可將其螢幕鎖定到頂層可見 Activity 所支援的任何旋轉。 Activity 不應假定它將始終以縱向呈現。

影響：使用者可以在關閉自動旋轉的情況下，手動旋轉螢幕；能否旋轉取決於頂層可見Activity所支援的旋轉設定。

文字

更新內容:

  • 文字預先計算：PrecomputedText 類使您能提前計算和快取所需資訊，改善了文字渲染效能。
  • 放大器：Magnifier 類是一種可提供放大器API的微件，可在所有應用中實現一致的放大器功能體驗。
  • Smart Linkify：Android 9增強了TextClassifier類，該類可利用機器學習在選定文字中識別一些實體並建議採取相應的操作。
  • 文字佈局：藉助幾種便捷函式和屬性，可以更輕鬆地實現介面設計。

影響：這個無疑強化了TextView的能力，應該比現在設定TextVie的樣式方便。

電源管理

更新內容:

  • 新增了一個應用待機群組的概念，系統將根據使用者的使用模式限制應用對 CPU 或電池等裝置資源的訪問。 五個群組如下：
  1. 活躍 如果使用者當前正在使用應用，應用將被歸到“活躍”群組中。 如果應用處於“活躍”群組，系統不會對應用的作業、報警或 FCM 訊息施加任何限制。
  2. 工作集 如果應用經常執行，但當前未處於活躍狀態，它將被歸到“工作集”群組中。 如果應用處於“工作集”群組，系統會對它執行作業和觸發報警的能力施加輕度限制。
  3. 常用 如果應用會定期使用，但不是每天都必須使用，它將被歸到“常用”群組中。 如果應用處於“常用”群組，系統將對它執行作業和觸發報警的能力施加較強的限制，也會對高優先順序 FCM 訊息的數量設定限制。
  4. 極少使用 如果應用不經常使用，那麼它屬於“極少使用”群組。 如果應用處於“極少使用”群組，系統將對它執行作業、觸發警報和接收高優先順序FCM訊息的能力施加嚴格限制。系統還會限制應用連線到網路的能力。
  5. 從未使用 安裝但是從未執行過的應用會被歸到“從未使用”群組中。 系統會對這些應用施加極強的限制。

影響：無疑，Google在幫Android機省電、省資源，算是一個比較好的更新。但是，我相信廠商會對分組策略稍作修改（或者白名單啥的），以方便自身應用可以隨時喚起。總的來說，應該對應用的Push類功能影響較大。

許可權變更

更新內容:

  • 構建序列號棄用：在 Android 9 中，Build.SERIAL 始終設定為 “UNKNOWN” 以保護使用者的隱私。 如果您的應用需要訪問裝置的硬體序列號，您應改為請求 READ_PHONE_STATE 許可權，然後呼叫 getSerial()。
  • 前臺服務：針對 Android 9 或更高版本並使用前臺服務的應用必須請求 FOREGROUND_SERVICE 許可權。
  • 後臺對感測器的訪問受限：Android 9限制後臺應用訪問使用者輸入和感測器資料的能力。
  • 限制訪問通話記錄：Android 9 引入 CALL_LOG 許可權組並將 READ_CALL_LOG、WRITE_CALL_LOG 和 PROCESS_OUTGOING_CALLS 許可權移入該組。
  • 限制訪問電話號碼：在未首先獲得 READ_CALL_LOG 許可權的情況下，除了應用的用例需要的其他許可權之外，運行於 Android 9 上的應用無法讀取電話號碼或手機狀態。
  • 限制訪問 Wi-Fi 位置和連線資訊：在 Android 9 中，應用進行 Wi-Fi 掃描的許可權要求比之前的版本更嚴格。具體限制見官網。

影響：許可權變更對收集手機應用資訊和監聽應用WiFi狀態（主要是位置資訊）都有很大影響，特別是對這些資訊有依賴的業務。

Apache Http被棄用

更新內容: 從 Android 9 開始，預設情況下Apache網路庫已從 bootclasspath 中移除且不可用於應用。

影響：終於要徹底拋棄Apache庫了，但業務硬要用的話，還是可以自己匯入jar包或者在AndroidManifest.xml中使用uses-library標籤。

適配齊劉海

有Pixel的同學可以把系統升級到Pie檢視效果，也可以下載相應映象用模擬器測試（最好使用AS3.1以上）。Pie提供了三種劉海樣式：

  1. 邊角劉海（我相信絕對沒廠商用…）

邊角劉海

  1. 正常劉海（被iPhone X帶出來的風格…）

正常劉海

  1. 劉海+下巴（為啥要有下巴…）

劉海

下巴

在Pie中，官方提供了DisplayCutout類來獲取劉海塊相關資料；通過getDisplayCutout()函式可以知道劉海是否存在；通過窗口布局屬性layoutInDisplayCutoutMode可以讓應用為裝置螢幕缺口周圍的內容進行佈局。直接上程式碼吧：

    @TargetApi(28)
    public void showDisplayCutout(View view) {
        // 注意：getRootWindowInsets()只有在檢視載入完成後，才會返回，否則返回null
        DisplayCutout cutout = getWindow().getDecorView().getRootWindowInsets().getDisplayCutout();
        if (cutout == null) { // 沒有劉海的時候拿到的DisplayCutout為null
            Log.d(TAG, "showDisplayCutout: 普通屏，沒有劉海");
            return;
        }
        List<Rect> rects = cutout.getBoundingRects(); // 獲取可能的凹凸塊
        if (rects.size() == 1) {
            Log.d(TAG, "showDisplayCutout: 有劉海");
            Rect rect = rects.get(0);
            Log.d(TAG, "showDisplayCutout: 劉海區域：" + rect);
        } else {
            Log.d(TAG, "showDisplayCutout: 有劉海和下巴");
            for (Rect rect : rects) {
                Log.d(TAG, "showDisplayCutout: 區域：" + rect);
            }
        }

        // 獲取安全區域的資料，單位px
        int safeInsetLeft = cutout.getSafeInsetLeft();
        int safeInsetTop = cutout.getSafeInsetTop();
        int safeInsetRight = cutout.getSafeInsetRight();
        int safeInsetBottom = cutout.getSafeInsetBottom();
        Log.d(TAG, "showDisplayCutout: 安全區域距離螢幕左邊：" + safeInsetLeft);
        Log.d(TAG, "showDisplayCutout: 安全區域距離螢幕頂部：" + safeInsetTop);
        Log.d(TAG, "showDisplayCutout: 安全區域距離螢幕右邊：" + safeInsetRight);
        Log.d(TAG, "showDisplayCutout: 安全區域距離螢幕底部：" + safeInsetBottom);

        int statusBarHeight = getStatusBarHeight();
        Log.d(TAG, "showDisplayCutout: 狀態列高度：" + statusBarHeight);
    }

    private int getStatusBarHeight() {
        int result = 0;
        int resourceId = getResources().getIdentifier("status_bar_height", "dimen", "android");
        if (resourceId > 0) {
            result = getResources().getDimensionPixelSize(resourceId);
        }
        return result;
    }

注意：

  • getRootWindowInsets()只有在View載入完後才會返回值，否則返回null。所以，如果你想在生命週期（onCreate等）裡直接呼叫的話，可能會出現空指標異常，可以使用post runnable的方式處理。
  • 劉海的高度不一定和狀態列的高度一樣，應該是小於登入狀態列高度。

設定視窗屬性：

@Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_second);

        // 設定全屏
        getWindow().getDecorView().setSystemUiVisibility(View.SYSTEM_UI_FLAG_FULLSCREEN | View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN);

        //沉浸式狀態列
//        getWindow().addFlags(WindowManager.LayoutParams.FLAG_TRANSLUCENT_STATUS);

        WindowManager.LayoutParams lp = getWindow().getAttributes();
        // 只有當DisplayCutout完全包含在系統欄中時，才允許視窗延伸到DisplayCutout區域。 否則，窗口布局不與DisplayCutout區域重疊。
        lp.layoutInDisplayCutoutMode = WindowManager.LayoutParams.LAYOUT_IN_DISPLAY_CUTOUT_MODE_DEFAULT;
        // 該視窗決不允許與DisplayCutout區域重疊。
//        lp.layoutInDisplayCutoutMode = WindowManager.LayoutParams.LAYOUT_IN_DISPLAY_CUTOUT_MODE_NEVER;
        // 該視窗始終允許延伸到螢幕短邊上的DisplayCutout區域。
//        lp.layoutInDisplayCutoutMode = WindowManager.LayoutParams.LAYOUT_IN_DISPLAY_CUTOUT_MODE_SHORT_EDGES;
        getWindow().setAttributes(lp);
    }

部分效果圖：

  1. 普通頁面帶狀態列 頁面帶狀態列

  2. 全屏頁面預設情況 全屏頁面預設情況

  3. 全屏頁面強制使用劉海區域 全屏強制使用劉海區域

  4. 沉浸式 沉浸式頁面

適配方案：

  • 對於有狀態列的頁面，不會受到劉海的影響，內容會展示在狀態列下方。
  • 對於全屏頁面，預設情況下系統會把展示內容下移到劉海之下，會產生一個黑條，此時需要注意頁面底部的內容，要避免因為下移導致的顯示不全問題；如果修改了視窗配置為LAYOUT_IN_DISPLAY_CUTOUT_MODE_SHORT_EDGES，則會強制使用劉海區域，這時頁面要規避劉海塊的那一點區域。
  • 對於沉浸式頁面，是受到影響最大的，預設情況下就會使用劉海區域，所以頁面內容要進行區域規避。

非SDK介面限制

Android 9（API 級別 28）引入了針對非 SDK 介面的使用限制，無論是直接使用還是通過反射或 JNI 間接使用。無論應用是引用非 SDK 介面還是嘗試使用反射或 JNI 獲取其控制代碼，均適用這些限制。 如果我們使用非SDK介面，會出現幾種情況：

  1. logcat日誌 類似 Accessing hidden field Landroid/os/Message;->flags:I (light greylist, JNI) 格式；
  2. 彈警告Toast
  3. 引發系統錯誤

非SDK介面都記錄在了不同的名單下：

  1. 白名單：SDK
  2. 淺灰名單：仍可以訪問的非 SDK 函式/欄位。
  3. 深灰名單： 對於目標 SDK 低於 API 級別 28 的應用，允許使用深灰名單介面。 對於目標 SDK 為 API 28 或更高級別的應用：行為與黑名單相同。
  4. 黑名單：受限，無論目標 SDK 如何，平臺將表現為似乎介面並不存在。

限制原理分析

  1. 編譯過程中有一個hiddenapi過程，會根據名單檔案，對dex中所有函式和欄位進行重新標記；
  2. runtime的時候，Art虛擬機器會根據函式和欄位的標記，並結合呼叫者的身份返回特定值；這些值就決定了呼叫者是否能成功呼叫介面。

階段一

階段二

如何繞過

還是大佬們的文章：

其中替換classloader的方式目前是最可靠的。

總結

參考資料：

  1. 其他資料已經在文中列出，不再重複；

相關推薦

Android修煉之Pie 適配的搬運工

自嘲時刻 Android P正式版（以下稱為Pie）已經正式上線了，各大廠商已經開始了系統升級工作，咱做上層開發的也得跟上節奏。當然了，新版本所有的行為更改內容都可以在官網上找到，對於其中如何繞開非SDK介面限制的問題，也有各路大神給出瞭解決方案。所以，我只能當

Android筆記之螢幕適配全攻略

Android螢幕適配出現的原因 在我們學習如何進行螢幕適配之前，我們需要先了解下為什麼Android需要進行螢幕適配。 由於Android系統的開放性，任何使用者、開發者、OEM廠商、運營商都可以對Android進行定製，修改成他們想要的樣子。

Android 螢幕適配之 dimens 適配

相信做手機端的 App 的小夥伴，只要是產品稍微大一點，就會面臨螢幕適配的問題，對於適配這個問題，網上眾說紛紜，以前雖然有零零散散的看過，但是沒有實踐過，也是在最近遇到這個需求的情況下才研究了一下，現在做個記錄。 1 參考連結 http://blog.csdn.net/qq_341

Android APP全方位效能調優之螢幕適配終結者

優點 1. 無侵入性 首先科普下 Android 中的一個長度單位：pt，它表示一個點，是螢幕的物理尺寸，其大小為 1 英寸的 1 / 72，也就是 72pt 等於 1 英寸（其實 Android 中還有比較少見的 in 和 mm 的長度單位）。而我本次的適配使用的單位恰好是 pt，所以對你

Android面試題-機型適配之痛，例如三星、小米、華為、魅族等。

原始碼分析相關面試題 Activity相關面試題 Service相關面試題 與XMPP相關面試題 與效能優化相關面試題 與登入相關面試題 與開發相關面試題 與人事相關面試題 由於開源三方定製

Android之機型適配

Android中的機型適配 在軟體開發的過程中,為了讓軟體在不同的場景下都可以使用,所以機型適配是不可或缺並且非常重要耗時的一個環節. 一:機型適配需要考慮的幾個方面: 1,Android的版本 2.手機廠商 3.螢幕的尺寸 4.網路的制式 5

android之螢幕適配（三）實踐dimens.xml尺寸適配不同的平板

android3.2以後，為了提供更精準的對佈局檔案的控制，可以通過為資原始檔（res目錄下檔案）增加字尾來指定該資料夾裡的xml佈局檔案或color.xml，string.xml是為哪種大小的螢幕使用。 第一種字尾：sw<N>dp,如layout-sw600

Android之螢幕適配

        網上螢幕適配的方式有很多，比如按百分比的、按解析度的，這裡我是按最小寬度去適配，也是Google建議的方式。         1.首先下載螢幕適配外掛ScreenMatch。         AS→File→Settings→plugins→SreenMa

android 手機適配之values適配dimen值

android 適配螢幕的方式有很多,最方便最直接的無非就是適配values裡的dimens檔案值來進行適配. 張鴻洋大神已經寫過一篇適配的文章,很詳細 但是我在閱讀的時候還是有點疑問,這個values-1920x1080到底是dp值還是手機解析度,因為我在

Android知識梳理之螢幕適配全攻略

       引言: 我相信Android碎片化問題是讓所有的Android開發者都比較頭疼的問題.尤其是螢幕適配這一塊兒.想要自己的app在不同的裝置上面都有一個比較好的顯示效果.就必須做好相應的螢幕適配.本文是結合網上的相關知識總結、官方文件結合自己的一些理解來進行闡述

dubbo之日誌適配及訪問日誌

訪問日誌 DDU ring toc accesslog span rate slf4j spa 日誌適配 自 2.2.1 開始，dubbo 開始內置 log4j、slf4j、jcl、jdk 這些日誌框架的適配 1，也可以通過以下方式顯示配置日誌輸出策略： 命令行

Android 多屏幕適配 dp和px的關系 最好用dp

linear title url -h pre ref end 建議 限制 Android 多屏幕適配 dp和px的關系 一直以來別人經常問我，android的多屏幕適配到底是怎麽弄，我也不知道如何講解清楚，或許自己也是挺迷糊。 以下得出的結論主要是結合官方文檔進行分析

Android P的APP適配總結，讓你快人一步

信息 最新 webview 包名 圖片 bmp illegal 名單 block 歡迎大家前往騰訊雲+社區，獲取更多騰訊海量技術實踐幹貨哦~ 本文由QQ音樂技術團隊發表於雲+社區專欄 上篇：Android P 行為變更適配 Android P 這次有很多行為變更，其中不

Android中的icon適配

一、icon的簡介 icon是應用圖示，官方建議將圖示根據不同的dpi放置在res/mipmap資料夾下。 二、icon的發展歷史 1、官方系統 官方系統在8.0前後存在一些區別，在8.0系統之前，android允許自定義icon形狀。7.0系統之開始，對launcher介面做了圓形的限制，8.0系統

Android 資原始檔螢幕適配

一、圖片適配: mipmap-xhdpi：720P，表示1280x720解析度，用於存放2x切圖 mipmap-xxhdpi：1080P，表示1920x1080解析度，用於存放3x切圖 mipmap-xxxhdpi：2K，表示2560x1440解析度，用於存放4x切圖  

Android通知欄介紹與適配總結（上篇）

此文已由作者黎星授權網易雲社群釋出。 歡迎訪問網易雲社群，瞭解更多網易技術產品運營經驗。 由於歷史原因，Android在釋出之初對通知欄Notification的設計相當簡單，而如今面對各式各樣的通知欄玩法，谷歌也不得不對其進行更新迭代調整，增加新功能的同時，也在不斷地改變樣式，試圖迎合更多

Android修煉之混淆

自嘲時刻 作為Java和Android開發者，大家應該都對混淆很熟悉了。網上也有各路大神提供的混淆模板，基本上直接拿來用就好。但我還是想捋一捋，因為工作中被混淆這傢伙“玩弄”了好幾次，必須把它記在小本本上。 介紹 基本概念 混淆，字面上來說就是把專案中的包名、類名、方法名和變數名等進行更改，用以迷惑別

Android修煉之檢測非SDK介面

前言 上篇文章Android修煉之Pie 適配的搬運工中介紹了Android P的一些行為變更並提供了一些對齊劉海和非SDK介面的適配建議，大部分人還是更加關心非SDK介面的問題，所以本文來說一下如何檢測非SDK介面。 區分SDK介面和非SDK介面 一般來說，SDK介面是指在Android框架軟體包索引

Android 8.0 通知適配

下面說一下Android O (8.0)（API 26）通知的相關適配 一、分析 Android O 之前開啟一個App的設定的通知是這樣的 傳送一條通知通過下面程式碼 /* * 簡單的傳送通知 */ private void showNotification

Android 8.0(Oreo) 適配

前陣子，市場中心丟來一個鍋，說華為、360、應用寶要求開發者適配 Android P，否則應用將被不推薦、隱藏甚至下架（華為），從 2018 年 8 月 1 日起，所有向 Google Play 首次提交的新應用都必須針對 Android 8.0 (API 等級 26) 開發