Android教程網 >> Android技術 >> 關於Android編程 >> Android N Preview 行為變更 (版本的更改）

Android N Preview 行為變更 (版本的更改）

編輯：關於Android編程

行為變更

Android N 除了提供諸多新特性和功能外，還對系統和 API 行為做出了各種變更。本文重點介紹您應該了解並在開發應用時加以考慮的一些重要變更。

如果您之前發布過 Android 應用，請注意您的應用可能受到這些平台變更的影響。

性能提升

為延長設備的電池壽命、降低內存使用率以及提升應用性能，Android N 對系統行為做出了一些變更。這些變更可能會影響系統資源和系統通知對應用的可用性。您應仔細檢查這些變更並評估應用可能需要做何調整以適應這些變更。

打盹

Android 6.0（API 級別 23）引入了打盹模式，當用戶設備未插接電源、處於靜止狀態且屏幕關閉時，該模式會推遲 CPU 和網絡活動，從而延長電池壽命。而 Android N 則通過在設備未插接電源且屏幕關閉狀態下、但不一定要處於靜止狀態（例如用戶外出時把手持式設備裝在口袋裡）時應用部分 CPU 和網絡限制，進一步增強了打盹模式。

圖 1.打盹模式如何應用第一級系統活動限制以延長電池壽命的圖示。

當設備處於充電狀態且屏幕已關閉一定時間後，設備會進入打盹模式並應用第一部分限制：關閉應用網絡訪問、推遲作業和同步。如果進入打盹模式後設備處於靜止狀態達到一定時間，系統則會對PowerManager.WakeLock、AlarmManager鬧鈴、GPS 和 Wi-Fi 掃描應用余下的打盹限制。無論是應用部分還是全部打盹限制，系統都會喚醒設備以提供簡短的維護時間窗口，在此窗口期間，應用程序可以訪問網絡並執行任何被推遲的作業/同步。

圖 2.打盹模式如何在設備處於靜止狀態達到一定時間後應用第二級系統活動限制的圖示。

請注意，激活屏幕或插接設備電源時，系統將退出打盹模式並取消這些處理限制。此項新增的行為不會影響有關使您的應用適應 Android 6.0（API 級別 23）中所推出的舊版本打盹模式的建議和最佳實踐，如打盹和應用待機優化中所討論。您仍應遵循這些建議（例如使用 Google Cloud Messaging (GCM) 發送和接收消息）並開始安排更新計劃以適應新增的打盹行為。

Project Svelte：後台優化

Android N 刪除了三項隱式廣播，以幫助優化內存使用和電量消耗。此項變更很有必要，因為隱式廣播會在後台頻繁啟動已注冊偵聽這些廣播的應用。刪除這些廣播可以顯著提升設備性能和用戶體驗。

移動設備會經歷頻繁的連接變更，例如在 Wi-Fi 和移動數據之間切換時。目前，可以通過在應用清單文件中注冊一個接收器來偵聽隱式CONNECTIVITY_ACTION廣播，讓應用能夠監控這些變更。由於很多應用會注冊接收此廣播，因此單次網絡切換即會導致所有應用被喚醒並同時處理此廣播。

同理，應用可以注冊接收來自其他應用（例如相機）的隱式ACTION_NEW_PICTURE和ACTION_NEW_VIDEO廣播。當用戶使用相機應用拍攝照片時，這些應用即會被喚醒以處理廣播。

為減緩這些問題，Android N 應用了以下優化措施：

面向 Android N 開發的應用不會收到CONNECTIVITY_ACTION廣播，即使它們已有清單條目來請求接受這些事件的通知。在前台運行的應用如果使用BroadcastReceiver請求接收通知，則仍可以在主線程中偵聽CONNECTIVITY_CHANGE。
應用無法發送或接收ACTION_NEW_PICTURE或ACTION_NEW_VIDEO廣播。此項優化會影響所有應用，而不僅僅是面向 Android N 的應用。

未來的 Android 版本還可能會棄用其他隱式廣播以及未綁定的後台服務。有鑒於此，您應避免依賴在清單文件中聲明的接收器來偵聽隱式廣播或刪除此依賴關系，以及避免或刪除對後台服務的依賴關系。

Android 框架提供多種解決方案來降低這些隱式廣播或後台服務的必要性。例如，JobSchedulerAPI 提供了一個穩健可靠的機制來安排滿足指定條件（例如連入不按流量計費的網絡）時所執行的網絡操作。您甚至可以使用JobScheduler來響應內容提供程序所發生的變更。

如需了解有關此行為變更及如何改寫應用的詳細信息，請參閱後台優化。

權限更改

Android N 做了一些權限更改，包括用戶帳戶權限和向外部存儲設備寫入信息的新權限，這些更改可能會影響您的應用。下面概要列出了預覽版中已發生更改的權限。

GET_ACCOUNTS（已棄用）

GET_ACCOUNTS 權限現已棄用。對於面向 Android N 的應用，系統將忽略此權限。

輔助工具改進

為提高平台對於視力不佳或視力受損用戶的可用性，Android N 做出了一些更改。這些更改一般並不要求更改您的應用代碼，不過您應仔細檢查並使用您的應用測試這些功能，以評估它們對用戶體驗的潛在影響。

屏幕縮放

Android N 支持用戶設置顯示尺寸，以放大或縮小屏幕上的所有元素，從而提升設備對視力不佳用戶的可訪問性。用戶無法將屏幕縮放至低於最小屏幕寬度sw320dp，該寬度是 Nexus 4 的寬度，也是常規中等大小手機的寬度。

圖 3.右側屏幕顯示的是一台運行 Android N 系統映像的設備增大顯示尺寸後的效果。

當設備密度發生更改時，系統會以如下方式通知正在運行的應用：

如果是面向 API 級別 23 或更低版本系統的應用，則系統會自動終止其所有後台進程。這意味著如果用戶切換離開此類應用，轉而打開Settings屏幕並更改Display size設置，則系統會像處理內存不足的情況一樣終止該應用。如果應用具有任何前台進程，則系統會如處理運行時變更中所述將配置變更通知給這些進程，就像對待設備屏幕方向變更一樣。
如果是面向 Android N 的應用，則其所有進程（前台和後台）都會收到有關配置變更的通知，如處理運行時變更中所述。

大多數應用並不需要進行任何更改即可支持此功能，不過前提是這些應用遵循 Android 最佳實踐。具體要檢查的事項：

在屏幕寬度為sw320dp的設備上測試您的應用，並確保其充分運行。
當設備配置發生變更時，更新任何與密度相關的緩存信息，例如緩存位圖或從網絡加載的資源。當應用從暫停狀態恢復運行時，檢查配置變更。
注：如果您要緩存與配置相關的數據，則最好也包括相關元數據，例如該數據對應的屏幕尺寸或像素密度。保存這些元數據便於您在配置變更後決定是否需要刷新緩存數據。
避免用像素單位指定尺寸，因為像素不會隨屏幕密度縮放。應改為使用與密度無關像素(dp) 單位指定尺寸。

設置向導中的視覺設置

Android N 在“Welcome”屏幕中加入了“Vision Settings”，用戶可以在新設備上設置以下輔助工具設置：Magnification gesture、Font size、Display size和TalkBack。此項變更增強了與不同屏幕設置相關的錯誤的可見性。要評估此功能的影響，您應在啟用這些設置的狀態下測試應用。您可以在Settings > Accessibility中找到這些設置。

NDK 應用鏈接至平台庫

Android N 做了一些命名空間更改，以阻止加載非公開 API。如果您使用 NDK，則只能使用 Android 平台提供的公開 API。在下一個官方發布的 Android 版本上使用非公開 API 會導致應用崩潰。

為提醒您使用了非公開 API，在 Android N 設備上運行的應用會在有應用調用非公開 API 時在日志消息輸出中生成一個錯誤。此錯誤還會作為消息顯示在設備屏幕上，以幫助增強您對此情況的認識。您應檢查應用代碼以刪除使用非公開平台 API，並使用預覽版設備或模擬器全面測試應用。

如果您的應用依賴平台庫，則請參見 NDK 文檔，了解使用公開 API 等效項替換普通私有 API 的典型修復。您還可以鏈接至平台庫，而無需實現此應用，如果應用使用的庫是平台的一部分（例如libpng），但不屬於 NDK，則更可如此。此情況下，請確保您的 APK 包含您打算鏈接到的所有 .so 文件。

注意：有些第三方庫可能會鏈接至非公開 API。如果您的應用使用這些庫，那麼當您的應用在下一個官方發布的 Android 版本上運行時可能會出現崩潰現象。

應用不應依賴或使用不屬於 NDK 的原生庫，因為這些庫可能會發生更改或從一個 Android 版本遷移至另一版本。例如，從 OpenSSL 切換至 BoringSSL 即屬於此類更改。此外，不同的設備可能提供不同級別的兼容性，因為不屬於 NDK 中的平台庫沒有兼容性要求。如果您必須在較舊設備上訪問非 NDK 庫，則請依據 Android API 級別進行加載。

為幫助您診斷此類問題，下面列舉了一些在您試圖使用 Android N 開發應用時可能遇到的 Java 和 NDK 錯誤：

Java 錯誤示例：

java.lang.UnsatisfiedLinkError: dlopen failed: library "/system/lib/libcutils.so"
    is not accessible for the namespace "classloader-namespace"

NDK 錯誤示例：

dlopen failed: cannot locate symbol "__system_property_get" referenced by ...

以下是遇到這類錯誤的應用的一些典型修復：

可以使用標准 JNI 函數來替代使用 libandroid_runtime.so 中的 getJavaVM 和 getJNIEnv：

AndroidRuntime::getJavaVM -> GetJavaVM from 
AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or
JavaVM::AttachCurrentThread from .

可以使用公開備選項__system_property_get來替代使用libcutils.so中的property_get符號。如需這樣做，請使用__system_property_get及以下 include 函數：
```
#include 
```
應使用應用本地版本來替代使用libcrypto.so中的SSL_ctrl符號。例如，您應在.so文件中靜態鏈接libcyrpto.a，或者在應用中包含您自己的來自 BoringSSL 或 OpenSSL 的動態libcrypto.so。

Android for Work

Android N 包含一些針對面向 Android for Work 的應用的變更，包括對證書安裝、密碼重置、二級用戶管理、設備標識符訪問權限的變更。如果您是要針對 Android for Work 環境開發應用，則應仔細檢查這些變更並相應地修改您的應用。

您必須先安裝授權證書安裝程序，然後 DPC 才能對其進行設置。對於面向 N SDK 的配置文件和設備所有者應用，您應在設備策略控制器 (DPC) 調用DevicePolicyManager.setCertInstallerPackage()之前安裝授權證書安裝程序。如果尚未安裝此安裝程序，則系統會引發IllegalArgumentException。
針對設備管理員的重置密碼限制現在也適用於配置文件所有者。設備管理員無法再使用DevicePolicyManager.resetPassword()來清除或更改已經設置的密碼。不過，設備管理員仍可以設置密碼，但只能在設備沒有密碼、PIN 或圖案時這樣做。
即使設置了限制，設備所有者和配置文件所有者仍可以管理帳戶。而且，即使具有DISALLOW_MODIFY_ACCOUNTS用戶限制，設備所有者和配置文件所有者仍可調用 Account Management API。
設備所有者可以更輕松地管理二級用戶。當設備在設備所有者模式下運行時，系統將自動設置DISALLOW_ADD_USER限制。這樣可以防止用戶創建非托管二級用戶。此外，CreateUser()和createAndInitial()方法已棄用，取而代之的是DevicePolicyManager.createAndManageUser()方法。
設備所有者可以訪問設備標識符。設備所有者可以使用DevicePolicyManagewr.getWifiMacAddress()訪問設備的 Wi-Fi MAC 地址。如果設備上從未啟用 Wi-Fi，則此方法將返回一個null值。

如需了解有關 Android N 中針對 Android for Work 所做變更的詳細信息，請參閱Android for Work 更新。

其他重要說明

如果一個應用在 Android N 上運行，但卻是針對更低 API 級別開發的，那麼在用戶更改顯示尺寸時，系統將終止此應用進程。因此，應用必須能夠正常處理此情景。否則，當用戶從最近使用記錄中恢復運行應用時，應用將會出現崩潰現象。
您應測試應用以確保不會發生此行為。要進行此測試，您可以通過 DDMS 手動終止應用，以造成相同的崩潰現象。

在密度發生更改時，系統不會自動終止面向 N 及更高版本的應用；不過，這些應用仍可能對配置變更做出不良響應。
Android N 上的應用應能夠正常處理配置變更，並且在後續啟動時不會出現崩潰現象。您可以通過更改字體大小 (Setting>Display>Font size) 並隨後從最近使用記錄中恢復運行應用，來驗證應用行為。