Android教程網 >> Android技術 >> 關於Android編程 >> Android7(N)開發者應該知道的一切(最全)

Android7(N)開發者應該知道的一切(最全)

編輯：關於Android編程

1.多窗口支持

Android N 添加了對同時顯示多個應用窗口的支持。在手持設備上，兩個應用可以在“分屏”模式中左右並排或上下並排顯示。在電視設備上，應用可以使用“畫中畫”模式，在用戶與另一個應用交互的同時繼續播放視頻。

如果您使用 N Preview SDK 構建應用，則可以配置應用處理多窗口顯示的方法。例如，您可以指定 Activity 的最小允許尺寸。您還可以禁用應用的多窗口顯示，確保系統僅以全屏模式顯示應用。

概覽

Android N 允許多個應用同時共享屏幕。例如，用戶可以分屏顯示應用，在左邊查看網頁，同時在右邊寫郵件。用戶體驗取決於設備：

運行 Android N 的手持設備具有分屏模式。在此模式中，系統以左右並排或上下並排的方式分屏顯示兩個應用。用戶可以拖動兩個應用之間的分界線，放大其中一個應用，同時縮小另一個。

在運行 Android N 的 Nexus Player 上，應用能以畫中畫模式顯示，即在用戶浏覽網頁或與其他應用交互的同時繼續顯示內容。

較大設備的制造商可選擇啟用自由形狀模式，在該模式中，用戶可以自由調整各 Activity 的尺寸。若制造商啟用此功能，設備將同時具有自由形狀模式和分屏模式。

圖 1.兩個應用在分屏模式中左右並排顯示。

用戶可以通過以下方式切換到多窗口模式：

若用戶打開Overview 屏幕並長按 Activity 標題，則可以拖動該 Activity 至屏幕突出顯示的區域，使 Activity 進入多窗口模式。

若用戶長按 Overview 按鈕，設備上的當前 Activity 將進入多窗口模式，同時將打開 Overview 屏幕，用戶可在該屏幕中選擇要共享屏幕的另一個 Activity。

用戶可以在兩個 Activity 共享屏幕的同時在這兩個 Activity 之間拖放數據 (在此之前，用戶只能在一個 Activity 內部拖放數據)。

多窗口生命周期

多窗口模式不會更改Activity 生命周期。

在多窗口模式中，在指定時間只有最近與用戶交互過的 Activity 為活動狀態。該 Activity 將被視為頂級 Activity。所有其他 Activity 雖然可見，但均處於暫停狀態。但是，這些已暫停但可見的 Activity 在系統中享有比不可見 Activity 更高的優先級。如果用戶與其中一個暫停的 Activity 交互，該 Activity 將恢復，而之前的頂級 Activity 將暫停。

注：在多窗口模式中，用戶仍可以看到處於暫停狀態的應用。應用在暫停狀態下可能仍需要繼續其操作。例如，處於暫停模式但可見的視頻播放應用應繼續顯示視頻。因此，我們建議播放視頻的 Activity 不要暫停其onPause()處理程序中的視頻。應暫停onStop()中的視頻，並恢復onStart()中的視頻播放。

如處理運行時變更中所述，用戶使用多窗口模式顯示應用時，系統將通知 Activity 發生配置變更。這也會發生在當用戶調整應用大小，或將應用恢復到全屏模式時。該變更與系統通知應用設備從縱向模式切換到橫向模式時的 Activity 生命周期影響基本相同，但設備不僅僅是交換尺寸，而是會變更尺寸。如處理運行時變更中所述，您的 Activity 可以自行處理配置變更，或允許系統銷毀 Activity，並以新的尺寸重新創建該 Activity。

如果用戶調整窗口大小，並在任意維度放大窗口尺寸，系統將調整 Activity 以匹配用戶操作，同時根據需要發布運行時變更。如果應用在新公開區域的繪制滯後，系統將使用windowBackground屬性或默認windowBackgroundFallback樣式屬性指定的顏色暫時填充該區域。

針對多窗口模式配置應用

如果您的應用面向 Android N，您可以對應用的 Activity 是否支持多窗口顯示以及顯示方式進行配置。您可以在清單文件中設置屬性，以控制大小和布局。根 Activity 的屬性設置適用於其任務棧中的所有 Activity。例如，如果根 Activity 已android:resizeableActivity設定為 true，則任務棧中的所有 Activity 都將可以調整大小。

注：如果您使用低於 Android N 版本的 SDK 構建多向應用，則用戶在多窗口模式中使用應用時，系統將強制調整應用大小。系統將顯示對話框，提醒用戶應用可能會發生異常。系統不會調整定向應用的大小;如果用戶嘗試在多窗口模式下打開定向應用，應用將全屏顯示。

android:resizeableActivity

在清單的或節點中設置該屬性，啟用或禁用多窗口顯示：

android:resizeableActivity=["true" | "false"]

如果該屬性設置為 true，Activity 將能以分屏和自由形狀模式啟動。如果此屬性設置為 false，Activity 將不支持多窗口模式。如果該值為 false，且用戶嘗試在多窗口模式下啟動 Activity，該 Activity 將全屏顯示。

如果您的應用面向 Android N，但未對該屬性指定值，則該屬性的值默認設為 true。

android:supportsPictureInPicture

在清單文件的節點中設置該屬性，指明 Activity 是否支持畫中畫顯示。如果android:resizeableActivity為 false，將忽略該屬性。

android:supportsPictureInPicture=["true" | "false"]

布局屬性

對於 Android N，清單元素支持以下幾種屬性，這些屬性影響 Activity 在多窗口模式中的行為：

android:defaultWidth

以自由形狀模式啟動時 Activity 的默認寬度。

android:defaultHeight

以自由形狀模式啟動時 Activity 的默認高度。

android:gravity

以自由形狀模式啟動時 Activity 的初始位置。請參閱Gravity參考資料，了解合適的值設置。

android:minimalHeight、android:minimalWidth

分屏和自由形狀模式中 Activity 的最小高度和最小寬度。如果用戶在分屏模式中移動分界線，使 Activity 尺寸低於指定的最小值，系統會將 Activity 裁剪為用戶請求的尺寸。

例如，以下節點顯示了如何指定 Activity 在自由形狀模式中顯示時 Activity 的默認大小、位置和最小尺寸：

在多窗口模式中運行應用

Android N 添加了新功能，以支持可在多窗口模式中運行的應用。

多窗口模式中被禁用的功能

在設備處於多窗口模式中時，某些功能會被禁用或忽略，因為這些功能對與其他 Activity 或應用共享設備屏幕的 Activity 而言沒有意義。此類功能包括：

某些系統 UI自定義選項將被禁用;例如，在非全屏模式中，應用無法隱藏狀態欄。

系統將忽略對android:screenOrientation屬性所作的更改。

多窗口變更通知和查詢

Activity類中添加了以下新方法，以支持多窗口顯示。有關各方法的詳細信息，請參閱N Preview SDK 參考。

Activity.isInMultiWindowMode()

調用該方法以確認 Activity 是否處於多窗口模式。

Activity.isInPictureInPictureMode()

調用該方法以確認 Activity 是否處於畫中畫模式。

注：畫中畫模式是多窗口模式的特例。如果myActivity.isInPictureInPictureMode()返回 true，則myActivity.isInMultiWindowMode()也返回 true。

Activity.onMultiWindowModeChanged()

Activity 進入或退出多窗口模式時系統將調用此方法。在 Activity 進入多窗口模式時，系統向該方法傳遞 true 值，在退出多窗口模式時，則傳遞 false 值。

Activity.onPictureInPictureModeChanged()

Activity 進入或退出畫中畫模式時系統將調用此方法。在 Activity 進入畫中畫模式時，系統向該方法傳遞 true 值，在退出畫中畫模式時，則傳遞 false 值。

每個方法還有Fragment版本，例如Fragment.isInMultiWindowMode()。

進入畫中畫模式

如需在畫中畫模式中啟動 Activity，請調用新方法Activity.enterPictureInPictureMode()。如果設備不支持畫中畫模式，則此方法無效。如需了解詳細信息，請參閱畫中畫文檔。

在多窗口模式中啟動新 Activity

在啟動新 Activity 時，用戶可以提示系統如果可能，應將新 Activity 顯示在當前 Activity 旁邊。要執行此操作，可使用標志Intent.FLAG_ACTIVITY_LAUNCH_TO_ADJACENT。傳遞此標志將請求以下行為：

如果設備處於分屏模式，系統會嘗試在啟動系統的 Activity 旁創建新 Activity，這樣兩個 Activity 將共享屏幕。系統並不一定能實現此操作，但如果可以，系統將使兩個 Activity 處於相鄰的位置。

如果設備不處於分屏模式，則該標志無效。

如果設備處於自由形狀模式，則在啟動新 Activity 時，用戶可通過調用ActivityOptions.setLaunchBounds()指定新 Activity 的尺寸和屏幕位置。如果設備不處於多窗口模式，則該方法無效。

注：如果您在任務棧中啟動 Activity，該 Activity 將替換屏幕上的 Activity，並繼承其所有的多窗口屬性。如果要在多窗口模式中以單獨的窗口啟動新 Activity，則必須在新的任務棧中啟動此 Activity。

支持拖放

用戶可以在兩個 Activity 共享屏幕的同時在這兩個 Activity 之間拖放數據 (在此之前，用戶只能在一個 Activity 內部拖放數據)。因此，如果您的應用目前不支持拖放功能，您可以在其中添加此功能。

N Preview SDK 擴展了android.view軟件包，以支持跨應用拖放。有關以下類和方法的詳細信息，請參閱N Preview SDK 參考。

android.view.DropPermissions

令牌對象，負責指定對接收拖放數據的應用授予的權限。

View.startDragAndDrop()

View.startDrag()的新別名。要啟用跨 Activity 拖放，請傳遞新標志View.DRAG_FLAG_GLOBAL。如需對接收拖放數據的 Activity 授予 URI 權限，可根據情況傳遞新標志View.DRAG_FLAG_GLOBAL_URI_READ或View.DRAG_FLAG_GLOBAL_URI_WRITE。

View.cancelDragAndDrop()

取消當前正在進行的拖動操作。只能由發起拖動操作的應用調用。

View.updateDragShadow()

替換當前正在進行的拖動操作的拖動陰影。只能由發起拖動操作的應用調用。

Activity.requestDropPermissions()

請求使用DragEvent中包含的ClipData傳遞的內容 URI 的權限。

測試應用的多窗口支持

無論您是否針對 Android N 更新應用，都應驗證應用在多窗口模式下的行為，以防用戶嘗試在運行 Android N 的設備上以多窗口模式啟動應用。

配置測試設備

如果在設備上安裝 Android N，則將自動支持分屏模式。

如果應用並非使用 N Preview SDK 構建

如果您的應用不是使用 N Preview SDK 構建的，則用戶嘗試在多窗口模式中使用應用時，系統將強制調整應用大小，除非應用進行了定向聲明。

如果您的應用沒有進行定向聲明，則應在運行 Android N 的設備上啟動應用，並嘗試將應用切換到分屏模式。驗證並確保在強制調整應用大小時用戶體驗可接受。

如果應用進行了定向聲明，則應嘗試將應用切換到多窗口模式。驗證並確保執行此操作後，應用仍保持全屏模式。

如果支持多窗口模式

如果您的應用是使用 N Preview SDK 構建的，且未禁用多窗口支持，則分別在分屏和自由形狀模式下驗證以下行為。

在全屏模式下啟動應用，然後通過長按 Overview 按鈕切換到多窗口模式。驗證並確保應用正常切換。

直接在多窗口模式中啟動應用，驗證並確保應用正常啟動。您可以按一下 Overview 按鈕，再長按應用的標題欄，並將其拖動到屏幕上任一突出顯示的區域，從而在多窗口模式中啟動應用。

拖動分界線，在分屏模式中調整應用的大小。驗證並確保應用正常調整大小且未崩潰，並且必要的 UI 元素仍可見。

如果您指定了應用的最小尺寸，請嘗試將應用尺寸調整到低於最小值。驗證並確保無法將應用尺寸調整到低於指定最小值。

完成所有測試後，驗證並確保應用性能可以接受。例如，驗證並確保調整應用大小後更新 UI 沒有長時間的滯後。

測試檢查單

要在多窗口模式中驗證應用性能，請執行以下操作。除非另有說明，否則請分別在分屏和多窗口模式中執行以下操作。

進入和退出多窗口模式。

從您的應用切換到另一個應用，驗證並確保應用在非活動但可見的狀態下正常運行。例如，如果您的應用在播放視頻，則驗證並確保在用戶與另一個應用交互時視頻仍在繼續播放。

在分屏模式中，嘗試移動分界線，放大或縮小應用。分別在左右和上下並排顯示模式中嘗試這些操作。驗證並確保應用不會崩潰，主要功能可見，且調整操作不需要過長時間。

快速連續執行幾次調整操作。驗證並確保應用不會崩潰或出現內存洩漏。有關檢查應用內存使用率的信息，請參閱查看內存使用率。

在多個不同窗口配置中正常使用應用，驗證並確保應用正常運行。驗證並確保文本可讀，且 UI 元素大小正常，不影響交互。

如果已禁用多窗口支持

如果您通過設置android:resizableActivity="false"禁用了多窗口支持，則應在運行 Android N 的設備上啟動應用，並嘗試將應用切換到自由形狀和分屏模式。驗證並確保執行此操作後，應用仍保持全屏模式。

2.通知欄

Android N 引入了一些新 API，允許應用發布具有高度可見性和交互性的通知。

Android N 擴展了現有RemoteInput通知 API，以支持手持式設備上的內聯回復。此功能允許用戶從通知欄快速進行回復，無需訪問應用。

此外，Android N 還允許捆綁類似的通知並將它們顯示為一則通知。為了實現此功能，Android N 使用現有的NotificationCompat.Builder.setGroup()方法。用戶可以從通知欄展開各通知，並分別對每則通知進行回復和清除等操作。

最後，Android N 還添加了一些新 API，允許您在應用的自定義通知視圖中使用系統裝飾元素。這些 API 可幫助確保通知視圖與標准模板的展示效果相一致。

本文重點介紹您在應用中使用新通知功能時應加以考慮的一些重要變更。

直接回復

利用 Android N 中的直接回復功能，用戶可以直接在通知界面內快速回復短信或更新任務列表。在手持式設備上，可通過通知中另外附加的按鈕進行內聯回復操作。當用戶通過鍵盤回復時，系統會將文本回復附加到您為通知操作指定的 Intent，並將 Intent 發送到手持式設備應用。

圖 1.Android N 添加了Reply操作按鈕。

添加內聯回復操作

要創建支持直接回復的通知操作：

創建一個可添加到通知操作的RemoteInput.Builder實例。該類的構造函數接受系統用作文本輸入密鑰的字符串。之後，手持式設備應用使用該密鑰檢索輸入的文本。

// Key for the string that's delivered in the action's intent.

private static final String KEY_TEXT_REPLY = "key_text_reply";

String replyLabel = getResources().getString(R.string.reply_label);

RemoteInput remoteInput = new RemoteInput.Builder(KEY_TEXT_REPLY)

.setLabel(replyLabel)

.build();

使用addRemoteInput()向操作附加RemoteInput對象。

// Create the reply action and add the remote input.

Notification.Action action =

new Notification.Action.Builder(R.drawable.ic_reply_icon,

getString(R.string.label), replyPendingIntent)

.addRemoteInput(remoteInput)

.build();

對通知應用操作並發出通知。

// Build the notification and add the action.

Notification newMessageNotification =

new Notification.Builder(mContext)

.setSmallIcon(R.drawable.ic_message)

.setContentTitle(getString(R.string.title))

.setContentText(getString(R.string.content))

.addAction(action))

.build();

// Issue the notification.

NotificationManager notificationManager =

NotificationManager.from(mContext);

notificationManager.notify(notificationId, newMessageNotification);

在觸發通知操作時系統提示用戶輸入回復。

圖 2.用戶從通知欄輸入文本。

從內聯回復檢索用戶輸入

要從通知界面接收用戶輸入並發送到在回復操作的 Intent 中聲明的 Activity：

通過傳遞通知操作的 Intent 作為輸入參數來調用getResultsFromIntent()。該方法返回含有文本回復的Bundle。

Bundle remoteInput = RemoteInput.getResultsFromIntent(intent);

使用產生的密鑰查詢捆綁包(提供給RemoteInput.Builder構造函數)。以下代碼段說明了方法如何從捆綁包檢索輸入文本：

// Obtain the intent that started this activity by calling

// Activity.getIntent() and pass it into this method to

// get the associated string.

private CharSequence getMessageText(Intent intent) {

Bundle remoteInput = RemoteInput.getResultsFromIntent(intent);

if (remoteInput != null) {

return remoteInput.getCharSequence(KEY_TEXT_REPLY);

}

return null;

}

使用您為上一項通知提供的相同的通知 ID 來建立和發布另一項通知。進度指示器從通知界面消失，以告知用戶已回復成功。在處理這項新通知時，使用被傳遞到接收器onReceive()方法的上下文。

// Build a new notification, which informs the user that the system

// handled their interaction with the previous notification.

Notification repliedNotification =

new Notification.Builder(context)

.setSmallIcon(R.drawable.ic_message)

.setContentText(getString(R.string.replied))

.build();

// Issue the new notification.

NotificationManager notificationManager =

NotificationManager.from(context);

notificationManager.notify(notificationId, repliedNotification);

對於交互式應用(例如聊天)，這可以用來在處理檢索到的文本時添加其他上下文。例如，這些應用可以顯示多行聊天記錄。當用戶通過RemoteInput回復時，您可以使用setRemoteInputHistory()方法更新回復歷史。

在應用收到遠程輸入後，必須更新或取消通知。如果用戶使用直接回復來對遠程更新進行回復，則不可取消通知。否則，更新通知以顯示用戶的回復。對於使用MessagingStyle的通知，您應該添加回復來作為最新消息。當使用其它模板時，您可以將用戶的回復追加到遠程輸入歷史。

捆綁通知

Android N 為開發者提供了表示通知隊列的新方法：捆綁通知。這類似於 Android Wear 中的通知堆棧功能。例如，如果應用為接收的消息創建通知，那麼在接收到多個消息時，應用會將通知捆綁在一起成為一個群組。您可以使用現有的Builder.setGroup()方法捆綁類似的通知。

通知組對組內的通知施加層次結構。層次結構的頂層是父級通知，其顯示該群組的摘要信息。用戶可以逐步展開通知組，隨著用戶深入展開，系統將顯示更多信息。當用戶展開捆綁包時，系統將顯示其所有子通知的更多信息;當用戶展開其中一則通知時，系統顯示該通知的所有內容。

圖 3.用戶可以逐步展開通知組。

注：如果同一應用發送了四條或以上通知，並且未指定分組，系統會自動將它們分到一組。

如需了解如何將通知添加到組，請參閱將各通知添加到組。

捆綁通知最佳做法

本節提供了有關何時使用通知組而非早期版本 Android 平台中的InboxStyle通知的指南。

何時使用捆綁通知

只有在您的用例滿足以下所有條件時才應使用通知組：

子通知為完整通知，且可以單獨顯示，無需群組摘要。

單獨顯示子通知更合理。例如：

子通知可操作，且每個子通知均有特定的操作。

子通知中包含用戶想要查看的更多信息。

好的通知組用例示例包括：顯示傳入消息列表的短信應用，或顯示收到的電子郵件列表的電子郵件應用。

適合顯示單一通知的用例示例包括：從某一個人收到的單獨消息，或以列表表示的單行文本項目。您可以使用InboxStyle或BigTextStyle實現此功能。

顯示捆綁通知

即使組內僅含有一則子通知，應用也應發布組摘要。如果只含有一則通知，系統將取消摘要並直接顯示子通知。這樣可確保用戶在滑動切換組內的子通知時，系統仍可以提供一致的用戶體驗。

注：本版本 Android N 目前還無法在僅含一則子通知時取消通知組的摘要。我們將在之後版本的 Android N 中添加此功能。

掃視通知

雖然系統通常以群組的方式顯示子通知，但您可以進行設置，使其暫時作為浮動通知顯示。該功能非常實用，因為其允許用戶立即訪問最近的子通知以及與其相關的操作。

後向兼容性

自 Android 5.0(API 級別 21)起，NotificationAPI 中就添加了通知組和遠程輸入，以支持 Android Wear 設備。如果您已經使用這些 API 構建通知，則只需驗證應用行為是否符合上述指南，並考慮實現setRemoteInputHistory()。

為了支持後向兼容性，支持庫的NotificationCompat類中提供了相同的 API，以便您構建可在早期 Android 版本中運行的通知。在手持式設備和平板電腦上，用戶只能看到摘要通知，因此應用應仍提供收件箱式或類似形式的通知顯示模式，以顯示群組的全部信息內容。鑒於 Android Wear 設備允許用戶查看所有子通知，包括更早級別平台上的通知，您應在不依賴 API 級別的基礎上構建子通知。

自定義視圖

從 Android N 開始，您將可以自定義通知視圖，同時仍可以使用系統裝飾元素，例如通知標頭、操作和可展開的布局。

為啟用該功能，Android N 添加了以下 API，以便您樣式化自己的自定義視圖：

DecoratedCustomViewStyle()

樣式化除媒體通知外的其他通知。

DecoratedMediaCustomViewStyle()

樣式化媒體通知。

如需使用這些新 API，可調用setStyle()方法，並向其傳遞所需的自定義視圖樣式。

此代碼段顯示了如何使用DecoratedCustomViewStyle()方法構建自定義通知對象。

Notification notification = new Notification.Builder()

.setSmallIcon(R.drawable.ic_stat_player)

.setLargeIcon(albumArtBitmap))

.setCustomContentView(contentView);

.setStyle(new Notification.DecoratedCustomViewStyle())

.build();

消息傳遞樣式

Android N 引入了一項新的 API 來自定義通知樣式。使用MessageStyle類，您可以更改在通知中顯示的多個標簽，包括會話標題、其他消息和通知的內容視圖。

以下代碼段演示了如何使用MessageStyle類來自定義通知樣式。

Notification notification = new Notification.Builder()

.setStyle(new Notification.MessagingStyle("Me")

.setConversationTitle("Team lunch")

.addMessage("Hi", timestamp1, null) // Pass in null for user.

.addMessage("What's up?", timestamp2, "Coworker")

.addMessage("Not much", timestamp3, null)

.addMessage("How about lunch?", timestamp4, "Coworker"));

3.Data Saver

在智能手機的整個生命周期，蜂窩數據計劃的成本通常會超出設備本身的成本。在 N Developer Preview 中，用戶可以在整個設備上啟用 Data Saver，以減少流量消耗，無論是在漫游，賬單周期即將結束，還是使用少量的預付費數據包。

當用戶在Settings中啟用 Data Saver 且設備位於按流量計費的網絡上時，系統屏蔽後台流量消耗，同時指示應用在前台盡可能使用較少的數據。用戶可以將特定應用加入白名單以允許後台按流量計費的流量消耗，即使在打開 Data Saver 時也是如此。

N Developer Preview 擴展ConnectivityManagerAPI，為應用提供檢索用戶的 Data Saver 首選項和監控首選項變更的方式。這被認為是應用檢查用戶是否啟用了 Data Saver 並努力限制前台和後台流量消耗的有效方法。

檢查 Data Saver 首選項

在 N Developer Preview 中，應用可以使用ConnectivityManagerAPI 來確定正在應用的是哪些流量消耗限制。getRestrictBackgroundStatus()方法返回下列值之一：

RESTRICT_BACKGROUND_STATUS_DISABLED

Data Saver 已禁用。

RESTRICT_BACKGROUND_STATUS_ENABLED

用戶已為此應用禁用 Data Saver。應用應努力限制前台流量消耗，並妥善處理後台流量消耗限制。

RESTRICT_BACKGROUND_STATUS_WHITELISTED

用戶已啟用 Data Saver，但應用在白名單中。應用應努力限制前台和後台流量消耗。

這被認為是在設備連接到按流量計費的網絡時限制流量消耗的有效方法，即使 Data Saver 被禁用或應用在白名單中。以下示例代碼使用ConnectivityManager.isActiveNetworkMetered()和ConnectivityManager.getRestrictBackgroundStatus()來確定應用應使用多少數據：

ConnectivityManager connMgr = (ConnectivityManager)

getSystemService(Context.CONNECTIVITY_SERVICE);

// Checks if the device is on a metered network

if (connMgr.isActiveNetworkMetered()) {

// Checks user’s Data Saver settings.

switch (connMgr.getRestrictBackgroundStatus()) {

case RESTRICT_BACKGROUND_STATUS_ENABLED:

// Background data usage is blocked for this app. Wherever possible,

// the app should also use less data in the foreground.

case RESTRICT_BACKGROUND_STATUS_WHITELISTED:

// The app is whitelisted. Wherever possible,

// the app should use less data in the foreground and background.

case RESTRICT_BACKGROUND_STATUS_DISABLED:

// Data Saver is disabled. Since the device is connected to a

// metered network, the app should use less data wherever possible.

}

} else {

// The device is not on a metered network.

// Use data as required to perform syncs, downloads, and updates.

}

請求白名單權限

如果您的應用需要使用後台數據，它可以通過發送一項包含您的應用軟件包名稱的 URI 的Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGSIntent 來請求白名單權限：例如package:MY_APP_ID。

發送 Intent 和 URI 將啟動Settings應用，還會顯示您的應用的流量消耗設置。用戶隨後可以決定是否啟用應用的後台數據。在您發送此 Intent 之前，先詢問用戶是否希望啟用Settings應用，以啟用後台流量消耗，這是一種有效的做法。

監控 Data Saver 首選項變更

應用可以通過創建一條BroadcastReceiver以偵聽ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED以及使用Context.registerReceiver()動態注冊接收器來監控 Data Saver 首選項變更。當應用接收到這條廣播時，應通過調用ConnectivityManager.getRestrictBackgroundStatus()來檢查新的 Data Saver 首選項是否會影響其權限。

注：系統只會向使用Context.registerReceiver()進行動態注冊的應用發送此廣播。在其清單中注冊接收此廣播的應用將不會收到它們。

使用 Android 調試橋命令測試

Android 調試橋 (ADB)提供了多條命令，可用於檢查和配置網絡權限：

從白名單中移除指定軟件包 UID，以阻止當 Data Saver 啟用時後台按流量計費的流量消耗。

4.TV

TV 輸入服務允許用戶通過時移 API 暫停和繼續頻道播放。 Android N 通過允許用戶保存多個錄制的會話，擴展了時移。

用戶可以提前安排錄制，或在觀看節目時開始錄制。系統保存錄制後，用戶即可使用系統 TV 應用浏覽、管理和播放錄制。

如果想要為 TV 輸入服務提供錄制功能，您必須指示系統您的應用支持錄制，實現錄制節目功能，處理和傳達錄制期間發生的所有錯誤，並管理錄制的會話。

注：Live Channels 應用尚不提供可讓用戶創建或訪問錄制的方式。在變更 Live Channels 應用之前，可能無法充分測試您的 TV 輸入服務的錄制體驗。

指示支持錄制

為了通知系統您的 TV 輸入服務支持錄制，請將您的服務元數據 XML 文件中的android:canRecord屬性設置為true：

如需了解有關服務元數據文件的詳細信息，請參閱在清單中聲明您的 TV 輸入。

或者，您可以使用以下步驟在您的代碼中表明錄制支持：

在TvInputService.onCreate()方法中，使用TvInputInfo.Builder類創建一個新的TvInputInfo對象。

創建新的TvInputInfo對象時，在調用build()之前先調用setCanRecord(true)，以表明您的服務支持錄制。

通過調用TvInputManager.updateTvInputInfo()在系統中注冊TvInputInfo對象。

錄制會話

TV 輸入服務注冊其支持錄制功能後，系統會在需要訪問應用的錄制實現時調用TvInputService.onCreateRecordingSession()。實現您自己的TvInputService.RecordingSession子類並在觸發onCreateRecordingSession()回調後返回它。此子類負責切換到正確的頻道數據，錄制請求的數據，以及向系統傳達錄制狀態和錯誤。

系統調用在頻道 URI 中傳遞的RecordingSession.onTune()時，將調到該 URI 指定的頻道。通過調用notifyTuned()通知系統應用已調到所需的頻道，或者，如果應用無法調到正確的頻道，請調用notifyError()。

系統接下來調用RecordingSession.onStartRecording()回調。您的應用必須立即開始錄制。系統調用此回調時，它可能會提供一個 URI，其中包含有關將錄制的節目的信息。完成錄制後，您需要將此數據復制到RecordedPrograms數據表。

最後，系統調用RecordingSession.onStopRecording()。此時，您的應用必須立即停止錄制。您還需要在RecordedPrograms表中創建一個條目。此條目應在RecordedPrograms.COLUMN_RECORDING_DATA_URI列中包含錄制的會話數據 URI，以及在初始調用onStartRecording()時系統提供的任何節目信息。

如需了解有關如何訪問RecordedPrograms表的更多詳情，請參閱管理錄制的會話。

處理錄制錯誤

如果錄制期間發生錯誤，使錄制的數據無法使用，則通過調用RecordingSession.notifyError()通知系統。同樣，您可以在創建錄制會話後調用notifyError()，以通知系統您的應用不再錄制會話。

如果錄制期間發生錯誤，但您想提供可使用的部分錄制供用戶播放，則調用RecordingSession.notifyRecordingStopped()以使系統可以使用部分會話。

管理錄制的會話

系統在TvContract.RecordedPrograms內容提供程序表中維護來自所有支持錄制的頻道應用的所有已錄制會話的信息。此信息可通過RecordedPrograms.Uri內容 URI 訪問。使用內容提供程序 API 讀取、添加和刪除此表中的條目。

如需了解有關使用內容提供程序數據的詳細信息，請參閱內容提供程序基本知識。

最佳做法

TV 設備的存儲可能有限，因此請運用您的最佳判斷來分配存儲，以保存錄制的會話。如果沒有足夠的空間存儲錄制的會話，請使用RecordingCallback.onError(RECORDING_ERROR_INSUFFICIENT_SPACE)。

當用戶發起錄制時，您應盡快開始錄制數據。為便於執行此操作，請在系統調用onCreateRecordingSession()回調時完成前期的所有耗時任務，如訪問和分配存儲空間。這樣做讓您能夠在觸發onStartRecording()回調時立即開始錄制。

5.密匙Key Attestation

密鑰認證會給你更多的信心，你在使用你的應用程序的密鑰存儲在設備的硬件支持的密鑰庫。下面的部分描述如何驗證性能的硬件支持的密鑰和如何解釋認證證書的擴展數據模式。

檢索和驗證密鑰對硬件支持

在密鑰認證，你指定一個密鑰對的別名。在返回的認證工具，提供了一個證書鏈，您可以使用它來驗證，密鑰對的性質。

在這個鏈的根證書簽名使用的認證密鑰，該設備制造商注入設備的硬件支持密鑰存儲在。

筆記在設備與Android和谷歌播放服務船，根證書是由谷歌發行。你應該確認在谷歌的根證書列表出現這個根證書。

實施重點認證，完成以下步驟：

使用密鑰庫對象的getcertificatechain()得到一個參考的X.509證書與密鑰相關的硬件支持外鏈的方法。

通過檢查每個證書的有效性CRL對象的isrevoked()方法

警告：雖然你可以在你的應用程序直接完成這個過程，它的安全檢查證書吊銷列表單獨的服務器上，你的信任。

創建一個認證對象，通過在證書鏈作為參數的第一個元素：

/“證書”包含一個特定的證書關聯的密鑰鏈

/ /對在設備的硬件支持的密鑰庫。

attestationcert X509Certificate= (X509Certificate)證書【零]

認證hardwarekeyattestation= 新認證(attestationcert)

認證對象提取擴展數據在這個證書將這些信息存儲在一個更方便的格式。更多的細節擴展的數據模式，看證書擴展數據模式。

在使用訪問器方法認證類從證書檢索擴展數據。這些方法使用相同的名稱和結構層次在證書擴展數據圖式。

例如，查看設備的TEE驗證啟動鍵，使用以下方法序列：

/“hardwarekeyattestation”包含了認證的第一要素

/ /證書鏈。

authorizationlistteeauthlist=hardwarekeyattestation。getteeenforced()

rootoftrustteerootoftrust=teeauthlist。getrootoftrust()

字節[ ]teeverifiedbootkey=teerootoftrust。getverifiedbootkey()

從擴展數據比較認證與設定的值，您期望的硬件支持的密鑰包含對象。

警告：雖然你可以在你的應用程序直接完成這個過程，它的安全檢查在一個單獨的服務器，你信任證書的擴展數據。

證書擴展數據模式

密鑰認證驗證擴展數據顯示在第一證書在設備的硬件支持的密鑰庫內的鏈。的證書存儲的信息根據ASN。1模式：

KeyDescription ::= SEQUENCE {

attestationVersion INTEGER,

attestationSecurityLevel SecurityLevel,

keymasterVersion INTEGER,

keymasterSecurityLevel SecurityLevel,

attestationChallenge OCTET_STRING,

保留octet_string,

softwareEnforced AuthorizationList,

teeEnforced AuthorizationList,

}

SecurityLevel ::= ENUMERATED {

Software (0),

TrustedEnvironment (1),

}

AuthorizationList ::= SEQUENCE {

purpose [1] EXPLICIT SET OF INTEGER OPTIONAL,

algorithm [2] EXPLICIT INTEGER OPTIONAL,

keySize [3] EXPLICIT INTEGER OPTIONAL,

digest [5] EXPLICIT SET OF INTEGER OPTIONAL,

padding [6] EXPLICIT SET OF INTEGER OPTIONAL,

ecCurve [10] EXPLICIT INTEGER OPTIONAL,

rsaPublicExponent [200] EXPLICIT INTEGER OPTIONAL,

activeDateTime [400] EXPLICIT INTEGER OPTIONAL,

originationExpireDateTime [401] EXPLICIT INTEGER OPTIONAL,

usageExpireDateTime [402] EXPLICIT INTEGER OPTIONAL,

noAuthRequired [503] EXPLICIT NULL OPTIONAL,

userAuthType [504] EXPLICIT INTEGER OPTIONAL,

authTimeout [505] EXPLICIT INTEGER OPTIONAL,

allowWhileOnBody [506] EXPLICIT NULL OPTIONAL,

allApplications [600] EXPLICIT NULL OPTIONAL,

applicationId [601] EXPLICIT OCTET_STRING OPTIONAL,

creationDateTime [701] EXPLICIT INTEGER OPTIONAL,

origin [702] EXPLICIT INTEGER OPTIONAL,

rollbackResistant [703] EXPLICIT NULL OPTIONAL,

rootOfTrust [704] EXPLICIT RootOfTrust OPTIONAL,

osVersion [705] EXPLICIT INTEGER OPTIONAL,

osPatchLevel [706] EXPLICIT INTEGER OPTIONAL,

attestationChallenge [708] EXPLICIT INTEGER OPTIONAL,

attestationApplicationId [709] EXPLICIT OCTET_STRING OPTIONAL,

}

RootOfTrust ::= SEQUENCE {

verifiedBootKey OCTET_STRING,

deviceLocked BOOLEAN,

verifiedBootState VerifiedBootState,

}

VerifiedBootState ::= ENUMERATED {

Verified (0),

SelfSigned (1),

Unverified (2),

Failed (3),

}

下面的列表給出了各元素在圖式：

keydescription

這個序列的值提供了密鑰對被通過密鑰認證驗證的一般信息和提供容易獲得額外的細節。

attestationversion

密鑰的認證功能的版本。應設置為1。

attestationsecurity

這個安全水平該認證。

筆記雖然它可能證明是密鑰存儲在Android系統，如果attestationsecurity值設置為軟件你不能信任這些證明如果Android系統成為損害。

keymasterversion

大師的硬件抽象層(HAL)版本。使用0 代表0.2版或0.3版，1代表1，2代表版本2。

keymastersecurity

這個安全水平實施的大師。

attestationchallenge

一個密鑰對，利用關鍵認證驗證有關的挑戰字符串。

保留

只有系統的應用程序使用該值。在所有其他應用程序，這個值是空的。

softwareenforced

可選的。keymaster the授權列表這是由Android系統的執行，不是由裝置的通。

teeenforced

可選的。keymaster the授權列表這是由設備的TEE執行。

安全級別

這個數據結構在多大程度上反映了軟件的功能，如密鑰對，是基於它的位置在保護裝置。

因為數據結構是一個枚舉，它具有完全相同的一個以下值：

軟件

創建和管理功能是在 Android系統實現邏輯。用於創建和存儲密鑰對的目的，這位置比發球不太安全但比你的應用程序的進程空間更安全。

trustedenvironment

邏輯用於創建和管理的特點是實施安全硬件，如T恤。用於創建和存儲密鑰的目的，這個位置更安全，因為安全的硬件抗遠程高度。

authorizationlist

這個數據結構包含密鑰對的性質本身，在大師的硬件抽象層(HAL)的定義。你比較這些值到設備的當前狀態或一組預期值進行驗證，使用你的應用程序的一密鑰仍然有效。

每個域名對應一個類似命名的大師標簽。例如，密鑰大小在授權列表字段對應的km_tag_key_size大師的標簽。

在下面的列表中的每個字段是可選的：

目的

對應於km_tag_purpose大師的標簽，它使用1個標簽ID值。

算法

對應於km_tag_algorithm大師的標簽，它使用的 2標簽的ID值。

當一個authorizationlist對象是關鍵認證有關，該值始終是km_algorithm_rsa或_公裡_ EC算法。

密鑰大小

對應於km_tag_key_size大師的標簽，它使用3個標簽ID值。

消化

對應於一天_公裡_文摘大師的標簽，它使用5個標簽ID值。

襯墊

對應於km_tag_padding大師的標簽，它使用6個標簽ID值。

eccurve

對應於_公裡_ EC標記_曲線大師的標簽，它使用一個10 標簽ID值。

用於生成橢圓曲線的參數集(EC)的密鑰對，采用ECDSA簽名與驗證，在Android系統。

rsapublicexponent

對應於_ _公裡_ RSA公共_指數標簽大師的標簽，它使用一個標簽ID 值200。

activedatetime

對應於_ Active DateTime _公裡_標簽大師的標簽，它使用一個標簽ID值 400。

originationexpiredatetime

對應於一天_公裡_起源_ datetime _ expire大師的標簽，它使用一個標簽ID值為401。

usageexpiredatetime

對應於km_tag_usage_expire_datetime大師的標簽，它使用一個標簽ID 值402。

noauthrequired

對應於公裡_標簽_沒有_ auth _ required大師的標簽，它使用一個標簽ID 值503。

當一個authorizationlist對象是關鍵認證有關，該值始終是真實的。

userauthtype

對應於_標簽使用_ auth公裡_ _類型大師的標簽，它使用一個標簽ID值 504。

authtimeout

對應於公裡_標簽_ auth _暫停。大師的標簽，它使用的 505標簽的ID值。

allowwhileonbody

對應於km_tag_allow_while_on_body大師的標簽，使用價值的標簽ID。

允許使用的身份驗證超時時間，如果用戶還穿著他們身上的裝置後的關鍵。注意安全身體上的傳感器確定設備是否被佩戴在用戶的體。

當一個authorizationlist對象是關鍵認證有關，該值始終是真實的。

所有應用

對應於_標簽應用全_ _公裡大師的標簽，使用價值的標簽ID。

指示是否在設備上的所有應用程序都可以訪問密鑰對。

當一個authorizationlist對象是關鍵認證有關，該值始終是真實的。

applicationid

對應於km_tag_application_id大師的標簽，它使用一個標簽ID值 601。

creationdatetime

對應於一天_公裡_ _創作的DateTime大師的標簽，它使用一個標簽ID 值701。

起源

對應於km_tag_origin大師的標簽，它使用702個標簽ID值。

當一個authorizationlist對象是關鍵認證有關，這個值通常設置為km_origin_generated。如果認證使用大師版本0.2或0.3，然而，起源可設置為km_origin_unknown相反。

rollbackresistant

對應於km_tag_rollback_resistant大師的標簽，它使用一個標簽ID 值703。

rootoftrust

對應於km_tag_root_of_trust大師的標簽，它使用一個標簽ID值 704。

更多詳情，請參見描述rootoftrust數據結構。

osversion

對應於我們把_公裡_ _版本大師的標簽，這使用705標簽ID值。

與大師相關的Android操作系統的版本，指定為一六位整數。例如，版本6.0.1 表示為060001。

只有大師1或更高版本包含此值在授權清單。

ospatchlevel

對應於km_tag_patchlevel大師的標簽，這使用706標簽ID值。

與安全補丁，在大師用相關的年份和月份，指定為一六位整數。例如，六月的 2016補丁是表示為201606。

只有大師1或更高版本包含此值在授權清單。

attestationchallenge

對應於km_tag_attestation_challenge大師標簽，它使用一個708標簽的ID值。

那是在大師定義的密鑰相關的挑戰字符串。

attestationapplicationid

對應於km_tag_attestation_application_id大師的標簽，它使用709個標簽ID值。

那個簽名密鑰對是在大師認證證書的唯一ID。

rootoftrust

這個值的集合定義了設備的狀態信息。

需要的是下面列表中的每個字段：

verifiedbootkey

一個安全的關鍵，驗證了系統的圖像哈希。建議你使用SHA-256算法對這個散列。

devicelocked

如果設備的Bootloader鎖定真實，使驗證啟動檢查和防止符號裝置的圖像被閃到裝置。有關此功能的更多信息，參見驗證啟動文檔

verifiedbootstate

這個引導狀態該裝置根據驗證啟動特征。

osversion

設備上的Android操作系統的新版本，指定為一六位數。例如，版本6.0.1表示 060001。

patchmonthyear

與安全補丁，目前設備上安裝相關的年份和月份，指定為一六位整數。例如，六月的 2016補丁是表示為201606。

verifiedbootstate

這個數據結構提供了設備當前的啟動狀態，這代表提供給用戶和應用程序的裝置啟動完後保護水平。有關此功能的更多信息，參見開機狀態在驗證啟動文件部分。

這是數據結構中的枚舉，因此需要准確的以下值之一：

表明該裝置已驗證失敗。認證證書不應使用該值為verifiedbootstate。

6.網絡安全配置

Android N 包含一個網絡安全配置特性，讓應用可以在一個安全的聲明性配置文件中自定義其網絡安全設置，而無需修改應用代碼。可以針對特定域和特定應用配置這些設置。該特性的主要功能如下所示：

自定義信任錨：針對應用的安全連接自定義哪些證書頒發機構 (CA) 值得信賴。例如，信任特定的自簽署證書或限制應用信任的公共 CA 集。

僅調試重寫：在應用中以安全方式調試安全連接，而不會增加安裝基數的風險。

Cleartext traffic 選擇退出：防止應用意外使用 cleartext traffic。

證書固定：將應用的安全連接限制為特定的證書。

添加安全配置文件

網絡安全配置特性使用一個 XML 文件，您可以在該文件中指定應用的設置。您必須在應用的清單中包含一個條目來指向該文件。以下代碼摘自一份清單，演示了如何創建此條目：

...

自定義信任的 CA

應用可能需要信任自定義的 CA 集，而不是平台默認值。出現此情況的最常見原因包括：

連接到具有自定義證書頒發機構(自簽署、由公司內部 CA 簽發等)的主機。

將 CA 集僅限於您信任的 CA，而不是每個預裝 CA。

信任系統中未包含的附加 CA。

默認情況下，來自所有應用的安全(例如 TLS、HTTPS)連接均信任預裝的系統 CA，而面向 API 級別 23 (Android M) 及更低級別的應用默認情況下還會信任用戶添加的 CA 存儲。應用可以使用base-config(針對應用范圍的定制)或domain-config(針對每個域的定制)自定義自己的連接。

配置自定義 CA

假設您要連接到使用自簽署 SSL 證書的主機，或者連接到其 SSL 證書是由您信任的非公共 CA(如公司內部 CA)簽發的主機。

res/xml/network_security_config.xml:

example.com

以 PEM 或 DER 格式將自簽署或非公共 CA 證書添加到res/raw/my_ca。

限制信任的 CA 集

如果應用不想信任系統信任的所有 CA，則可以自行指定，縮減要信任的 CA 集。這樣可防止應用信任任何其他 CA 簽發的欺詐性證書。

限制信任的 CA 集的配置與針對特定域信任自定義 CA相似，不同的是，前者要在資源中提供多個 CA。

res/xml/network_security_config.xml:

secure.example.com

cdn.example.com

以 PEM 或 DER 格式將信任的 CA 添加到res/raw/trusted_roots。請注意，如果使用 PEM 格式，文件必須僅包含 PEM 數據，且沒有額外的文本。您還可以提供多個元素，而不是只能提供一個元素。

信任附加 CA

應用可能需要信任系統不信任的附加 CA，出現此情況的原因可能是系統還未包含此 CA，或 CA 不符合添加到 Android 系統中的要求。應用可以通過為一個配置指定多個證書源來實現此目的。

res/xml/network_security_config.xml:

配置用於調試的 CA

調試通過 HTTPS 連接的應用時，您可能需要連接到沒有用於生產服務器的 SSL 證書的本地開發服務器。為了支持此操作，而又不對應用的代碼進行任何修改，您可以通過使用debug-overrides指定僅在android:debuggable為true時才信任的僅調試 CA。通常，IDE 和構建工具會自動為非發布版本設置此標志。

這比一般的條件代碼更安全，因為出於安全考慮，應用存儲不接受被標記為可調試的應用。

res/xml/network_security_config.xml:

選擇退出 Cleartext Traffic

旨在連接到僅使用安全連接的目標的應用可以選擇不再對這些目標提供 cleartext(使用解密的 HTTP 協議而非 HTTPS)支持。此選項有助於防止應用因外部源(如後端服務器)提供的 URL 發生變化而意外回歸。請參閱NetworkSecurityPolicy.isCleartextTrafficPermitted()了解更多詳情。

例如，應用可能需要確保所有與secure.example.com的連接始終是通過 HTTPS 完成，以防止來自惡意網絡的敏感流量。

res/xml/network_security_config.xml:

secure.example.com

固定證書

一般情況下，應用信任所有預裝 CA。如果有預裝 CA 要簽發欺詐性證書，則應用將面臨被中間人攻擊 (MiTM) 的風險。有些應用通過限制信任的 CA 集或通過證書固定來選擇限制其接受的證書集。

通過按公鑰的哈希值(X.509 證書的 SubjectPublicKeyInfo)提供證書集完成證書固定。然後，證書鏈僅在至少包含一個已固定的公鑰時才有效。

請注意，使用證書固定時，您應始終包含一個備份密鑰，這樣，當您需要強制切換到新密鑰時，或更改 CA 時(固定到某個 CA 證書或該 CA 的中間證書時)，您應用的連接性不會受到影響。否則，您必須推送應用的更新以恢復連接性。

此外，可以設置固定到期時間，在該時間之後不執行證書固定。這有助於防止尚未更新的應用出現連接問題。不過，設置固定到期時間可能會繞過證書固定。

res/xml/network_security_config.xml:

example.com

7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=

fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE=

配置繼承行為

繼承未在特定配置中設置的值。此行為允許進行更復雜的配置，同時保證配置文件可讀。

如果未在特定條目中設置值，則使用來自下一個更通用的條目中的值。未在domain-config中設置的值從父級domain-config(如果已嵌套)或從base-config(如果未嵌套)中獲取。未在base-config中設置的值使用平台默認值。

例如，考慮所有與example.com的子域的連接必須使用自定義 CA 集。此外，允許使用這些域的 cleartext traffic，連接到secure.example.com時除外。通過在example.com的配置中嵌套secure.example.com的配置，不需要重復trust-anchors。

res/xml/network_security_config.xml:

example.com

secure.example.com

配置文件格式

網絡安全配置特性使用 XML 文件格式。文件的整體結構如以下代碼示例所示：

...

android.com

...

以下部分介紹語法和文件格式的其他詳細信息。

可包含：

0 或 1 個

任意數量的

0 或 1 個

usesCleartextTraffic=["true" | "false"]>

...

語法：

可包含：

說明：

目標不在domain-config涵蓋范圍內的所有連接所使用的默認配置。

未設置的任何值均使用平台默認值。面向上述 API 級別 24 及更高級別的應用的默認配置：

面向 API 級別 23 及更低級別的應用的默認配置：

語法：

usesCleartextTraffic=["true" | "false"]>

...

可包含：

1 個或多個

0 或 1 個

任意數量的已嵌套

說明

用於按照domain元素的定義連接到特定目標的配置。

請注意，如果有多個domain-config元素涵蓋某個目標，則使用匹配域規則最具體(最長)的配置。

語法：

example.com

屬性：

includeSubdomains

如果為"true"，則此域規則與域及所有子域(包括子域的子域)匹配，否則，該規則僅適用於精確匹配項。

說明：

語法：

...

可包含：

0 或 1 個

說明：

當android:debuggable為"true"時將應用的重寫，IDE 和構建工具生成的非發布版本通常屬於此情況。將在debug-overrides中指定的信任錨添加到所有其他配置，並且當服務器的證書鏈使用其中一個僅調試信任錨時不執行證書固定。如果android:debuggable為"false"，則完全忽略此部分。

語法：

...

可包含：

任意數量的

說明：

用於安全連接的信任錨集

語法：

說明：

用於trust-anchors元素的 X.509 證書集。

屬性：

src

CA 證書的來源，可以是

指向包含 X.509 證書的文件的原始資源 id。證書必須以 DER 或 PEM 格式編碼。如果為 PEM 證書，則文件不得包含額外的非 PEM 數據，如注釋。

用於預裝系統 CA 證書的"system"

用於用戶添加的 CA 證書的"user"

overridePins

指定來自此源的 CA 是否繞過證書固定。如果為"true"，則為穿過此源的其中一個 CA 的鏈頒發證書，並且不執行證書固定。這對於調試 CA 或支持用戶對應用的安全流量進行中間人攻擊 (MiTM) 非常有用。

默認值為"false"，除非在debug-overrides元素中另外指定(在這種情況下，默認值為"true")。

語法：

...

可包含：

任意數量的

說明：

公鑰固定 (PKP) 集。對於要信任的安全連接，信任鏈中必須有一個公鑰位於 PKP 集中。有關固定形式，請參閱。

屬性：

expiration

采用yyyy-MM-dd格式的日期，在該日期及之後固定過期，因而禁用固定。如果未設置該屬性，則固定不會過期。

設置到期時間有助於防止未更新到其 PKP 集(例如，由於用戶禁用應用更新)的應用出現連接問題。

語法：

base64 encoded digest of X.509

SubjectPublicKeyInfo (SPKI)

屬性：

用於生成 PKP 的摘要算法。目前僅支持"SHA-256"。

7.ICU4J Android

ICU4J 是一個廣泛使用的開源 Java 庫集合，為軟件應用提供 Unicode 和全球化支持。 Android N 在android.icu軟件包下顯示 Android 框架中的 ICU4J API 子集，供應用開發者使用。這些 API 使用設備上具有的本地化數據。因此，您可以通過不將 ICU4J 庫編譯到 APK 來減少 APK 占用空間;相反，您可以只在框架中調用它們。 (在此情況下，您可能想要提供多個版本的 APK，這樣，運行比 Android N 低的 Android 版本的用戶可以下載包含 ICU4J 庫的應用版本。)

本文檔開頭提供了有關支持這些庫所需的最低 Android API 級別的一些基本信息。然後，介紹關於 Android 特定的 ICU4J 實現您需要了解的內容。最後，介紹如何在 Android 框架中使用 ICU4J API。

與 ICU4J 的關系

Android N 通過android.icu軟件包(而非com.ibm.icu)顯示 ICU4J API 的子集。由於種種原因，Android 框架可能選擇不顯示 ICU4J API;例如，Android N 不顯示一些已棄用的 API 或 ICU 團隊尚未將其聲明為“穩定”的 API。由於 ICU 團隊將來會棄用這些 API，因此，Android 也會將其標記為已棄用，但將繼續包含它們。

表 1.Android N 中使用的 ICU 和 CLDR 版本。

Android API 級別ICU 版本CLDR 版本

Android N5628

以下是幾點注意事項：

ICU4J Android 框架 API 不包含所有的 ICU4J API。

NDK 開發者應了解 Android ICU4C 不受支持。

Android 框架中的 API 不會取代 Android 對使用資源進行本地化的支持。

從 com.ibm.icu 遷移至 android.icu 軟件包

如果您已在應用中使用 ICU4J API，且android.icuAPI 符合您的要求，那麼要遷移至框架 API，需要將 Java 導入從com.ibm.icu更改為android.icu。然後，您可以從 APK 移除您自己的 ICU4J 文件的副本。

注：ICU4J 框架 API 使用android.icu命名空間，而不是com.ibm.icu。這是為了避免在包含自己的com.ibm.icu庫的 APK 中出現命名空間沖突。

從其他 Android SDK API 遷移至 android.icu API

java和android軟件包中的某些類與在 ICU4J 中找到的一些類等效。不過，ICU4J 通常為標准和語言提供更廣泛的支持。

下面是一些入門示例：

類替代項

java.lang.Characterandroid.icu.lang.UCharacter

java.text.BreakIteratorandroid.icu.text.BreakIterator

java.text.DecimalFormatandroid.icu.text.DecimalFormat

java.util.Calendarandroid.icu.util.Calendar

android.text.BidiFormatterandroid.icu.text.Bidi

android.text.format.DateFormatandroid.icu.text.DateFormat

android.text.format.DateUtilsandroid.icu.text.DateFormatandroid.icu.text.RelativeDateTimeFormatter

授權

ICU4J 按照 ICU 許可發布。如需了解詳情，請參閱ICU 用戶指南。

8.Java 8 支持

Android N 支持 Java 8 語言功能，您可以在開發面向 Android N 的應用時使用這些功能。本頁面介紹了 Android N Preview 中支持的新語言功能、如何正確設置項目以使用這些功能，以及您可能遇到的任何已知問題。

要開始使用這些功能，您需要下載並設置 Android Studio 2.1 和 Android N Preview SDK，包括所需的 Jack 工具鏈和更新的 Android Plugin for Gradle。如果您尚未安裝 Android N Preview SDK，請參閱Develop for Android N 設置。

注：開發面向 Android N 平台的應用並不要求必須使用新的 Java 8 語言功能。如果您不想使用 Java 8 語言功能編寫代碼，您可以將項目的源和目標兼容性值保留為 Java 7，但您仍必須使用 JDK 8 進行編譯，以便針對 Android N 平台進行構建。

支持的 Java 8 語言功能和 API

Android 目前僅支持部分 Java 8 語言功能。在開發面向 Android N Preview 的應用時，現已可使用以下功能：

默認和靜態接口方法

Lambda 表達式(也在 API 級別 23 及更低版本中使用)

重復注解

方法引用(也在 API 級別 23 及更低版本中使用)

注：在 Android 的較早版本中測試 Lambda 表達式和方法引用，前往您的build.gradle文件，將compileSdkVersion和targetSdkVersion設置為 23 或更低版本。您仍需要啟用 Jack 工具鏈以使用這些 Java 8 功能。

此外，現已可使用以下 Java 8 語言功能 API：

反映和語言相關 API：

java.lang.FunctionalInterface

java.lang.annotation.Repeatable

java.lang.reflect.Method.isDefault()

和與重復注解關聯的反映 API，例如AnnotatedElement.getAnnotationsByType(Class)

實用程序 API：

java.util.function

java.util.stream

啟用 Java 8 功能和 Jack 工具鏈

要使用新的 Java 8 語言功能，還需使用新的Jack 工具鏈。新的 Android 工具鏈將 Java 源語言編譯成 Android 可讀取的 Dalvik 可執行文件字節碼，且有其自己的.jack庫格式，在一個工具中提供了大多數工具鏈功能：重新打包、壓縮、模糊化以及 Dalvik 可執行文件分包。

以下是構建 Android Dalvik 可執行文件可用的兩種工具鏈的對比：

舊版 javac 工具鏈：

javac(.java-->.class) -->dx(.class-->.dex)

新版 Jack 工具鏈：

Jack(.java-->.jack-->.dex)

配置 Gradle

如需為您的項目啟用 Java 8 語言功能和 Jack，請在模塊層級的build.gradle文件中輸入以下內容：

android {

...

defaultConfig {

...

jackOptions {

enabled true

}

compileOptions {

sourceCompatibility JavaVersion.VERSION_1_8

targetCompatibility JavaVersion.VERSION_1_8

}

已知問題

Instant Run目前不能用於 Jack，在使用新的工具鏈時將被禁用。

由於 Jack 在編譯應用時不生成中間類文件，依賴這些文件的工具目前不能用於 Jack。例如以下工具：

對類文件進行操作的 Lint 檢測工具

需要應用類文件的工具和庫(例如使用 JaCoCo 進行儀器測試中)

如果您在使用 Jack 的過程中發現其他問題，請提交錯誤。

9.Android for Work 更新

QR 碼配置

Android for Work 現在支持使用 QR 碼來配置企業負責的設備。安裝向導現在允許您通過掃描 QR 碼來配置設備。

工作資料安全性挑戰

個人資料所有者可以要求用戶為在工作資料中運行的應用指定安全性挑戰。系統會在用戶嘗試打開任何工作應用時顯示安全性挑戰。如果用戶成功完成安全性挑戰，系統可解鎖工作資料並將其解密(如果需要)。

如果個人資料所有者發送一項ACTION_SET_NEW_PASSWORDIntent，系統會提示用戶設置一項安全性挑戰。個人資料所有者也可以發送一項ACTION_SET_NEW_PARENT_PROFILE_PASSWORDIntent 來提示用戶設置設備鎖定。

個人資料所有者可以選擇為工作挑戰設置不同於其他設備密碼策略的密碼策略。例如，設備挑戰響應的最小長度可以與其它密碼要求的長度不同。個人資料所有者使用常見的DevicePolicyManager方法來設置挑戰策略，如setPasswordQuality()和setPasswordMinimumLength()。個人資料所有者還能通過使用由新的DevicePolicyManager.getParentProfileInstance()方法返回的DevicePolicyManager實例來設置設備鎖定，此外，個人資料所有者可以使用DevicePolicyManager類的新setOrganizationColor()和setOrganizationName()方法來自定義工作挑戰的憑據屏幕。

有關新方法和常量的詳細信息，請參閱N Preview SDK 參考中的DevicePolicyManager參考頁面。

停用應用訪問

設備所有者和個人資料所有者可以通過調用新DevicePolicyManager.setPackagesSuspended()方法來臨時暫停軟件包訪問。所有者可以用同樣的方法來重新啟用這些軟件包。

在軟件包被暫停期間，它不能啟動 Activity ，到軟件包的通知會被阻止，而概覽屏幕中的應用條目會被隱藏。暫停的軟件包不會顯示在概覽屏幕中，並且它們不能顯示對話(包括提醒和 Snackbar)，也不能播放音頻或振動設備。

啟動器應對暫停的應用應用一個獨特的 UI，以指示應用目前不可用;例如它們可以將應用圖標顯示為灰色。啟動器可以通過調用新DevicePolicyManager.getPackageSuspended()方法來確定應用是否被暫停。

切換工作模式

在雙個人資料設備上，用戶可以打開或關閉工作模式。在工作模式關閉時，托管個人資料會被暫時關閉。工作資料應用、後台同步和通知都會被停用，包括個人資料所有者應用。在工作資料被停用時，系統會顯示一個持久的狀態圖標，以提醒用戶他們將無法啟動工作應用。系統啟動器會指示工作應用和小工具都將無法訪問。

Always-On VPN

設備所有者和個人資料所有者可以要求工作應用始終通過指定的 VPN 連接到網絡。如果所有者設置了此要求，設備會在啟動時自動開始 VPN。

所有者可以通過調用新DevicePolicyManager.setAlwaysOnVpnPackage()方法來要求使用 VPN。通過調用新DevicePolicyManager.GetAlwaysOnVpnPackage()方法來確定所有者是否設置了 VPN 要求。

由於 VPN 服務無需應用交互即可由系統直接綁定，因此，VPN 客戶端必須針對 Always on VPN 處理新的入口點。像以前一樣，您可以通過使用與操作android.net.VpnService匹配的 Intent 過濾器查找活動的服務。

用戶可以使用Settings > More > VPN屏幕來手動設置實現VpnService的 Always on VPN 客戶端。

聯系人與工作資料集成

個人資料所有者可以允許主用戶對工作聯系人進行本地搜索和目錄查找。例如，用戶可以從他們的個人撥號器或聯系人應用訪問個人和工作目錄聯系人(如果他們的個人資料管理員允許)。

利用聯系人提供程序的開發者可以使用企業聯系人 API 從主用戶訪問工作資料目錄條目(如果策略允許)：

ContactsContract.Contacts.ENTERPRISE_CONTENT_FILTER_URI

ContactsContract.Phone.ENTERPRISE_CONTENT_FILTER_URI

ContactsContract.Email.ENTERPRISE_CONTENT_FILTER_URI

ContactsContract.Callable.ENTERPRISE_CONTENT_FILTER_URI

ContactsContract.Directory.ENTERPRISE_CONTENT_URI

ContactsContract.Directory.isEntepriseDirectoryId()

個人資料所有者可以使用以下新方法來控制主用戶的工作聯系人可見性：

DevicePolicyManager.setCrossProfileContactsSearchDisabled()

DevicePolicyManager.getCrossProfileContactsSearchDisabled()

遠程重新啟動

設備所有者可以遠程重新啟動設備。有些情況下，部署在公共場所的封裝內設備會阻止訪問電源按鈕。如果設備需要重新啟動，管理員可以使用新DevicePolicyManager.reboot()方法來進行此操作。

停用數據網絡漫游

設備所有者可以使用新的UserManager用戶限制DISALLOW_DATA_ROAMING來停用數據網絡漫游。

企業進程記錄

設備所有者可以通過遠程跟蹤設備活動來識別可疑活動，包括應用啟動、ADB Activity 和屏幕解鎖。進程記錄不要求用戶同意。若要檢索記錄，設備所有者可以使用DevicePolicyManager.setSecurityLoggingEnabled()來啟用設備記錄。

API 更改包括：

新類android.app.admin.SecurityLog和它的方法

void DevicePolicyManager.setSecurityLoggingEnabled()

boolean DevicePolicyManager.isSecurityLoggingEnabled()

ListDevicePolicyManager.retrieveSecurityLogs()

ListDevicePolicyManager.retrievePreRebootSecurityLogs()

void DeviceAdminReceiver.onSecurityLogsAvailable()

遠程錯誤報告

設備所有者可以遠程觸發和檢索包含設備狀態轉儲文件的錯誤報告，這允許對已知事故或受損害的設備進行取證調查。鑒於錯誤報告的詳細性質，需要經過用戶同意。

Android N 包括以下 API 添加來支持此功能。如需詳細信息，請參閱N Preview SDK 參考。

DevicePolicyManager.requestBugreport()

DeviceAdminReceiver.onBugreportFailed()

DeviceAdminReceiver.onBugreportShared()

DeviceAdminReceiver.onBugreportSharingDeclined()

DeviceAdminReceiver.BUGREPORT_FAILURE_FAILED_COMPLETING

DeviceAdminReceiver.BUGREPORT_FAILURE_FILE_NO_LONGER_AVAILABLE

移除客戶端證書

個人資料所有者和設備所有者現在可以通過調用新方法DevicePolicyManager.removeKeyPair()來移除通過installKeyPair()安裝的客戶端證書。

允許訪問安裝設備上的客戶端證書

如果個人資料所有者或設備所有者授予第三方應用管理證書的權限，應用便可授予自身訪問其所安裝證書的權限，無需所有者進行任何干預。

用於管理證書的現有 API 經過擴展，現包括：

DevicePolicyManager.installKeyPair()

系統 UI 策略透明度

影響用戶體驗或限制用戶設置的策略是向用戶完全公開的，個人資料所有者和設備所有者可以將策略歸於他們公司的 IT 部門。除了“Settings”中一貫的“Action not allowed”消息之外，IT 管理員可以通過以下新DevicePolicyManager方法在設備設置中設置組織特定的支持消息：

DevicePolicyManager.setShortSupportMessage()

DevicePolicyManager.setLongSupportMessage()

應用限制管理增強

設備或個人資料所有者可以通過新DevicePolicyManager.setApplicationRestrictionsManagingPackage()方法啟用另一項應用，以管理應用限制。提名的應用可以通過調用DevicePolicyManager.isCallerApplicationRestrictionsManagingPackage()來檢查是否已被授予此權限。

提名管理應用限制的應用可以為該用戶或個人資料內的任何軟件包調用setApplicationRestrictions()和getApplicationRestrictions()。

位置關閉開關

用戶可以停用工作應用的位置權限，同時仍可繼續在個人應用中訪問位置信息。 Location Settings 中的一個單獨的位置訪問開關允許用戶拒絕對工作資料內運行的應用的位置更新或最後位置查詢。

頂層位置關閉開關停用對主個人資料和托管個人資料的位置訪問權限。

自定義配置

應用可以用企業顏色和徽標來自定義個人資料所有者和設備所有者配置流程。

DevicePolicyManager.EXTRA_PROVISIONING_MAIN_COLOR

自定義流程顏色。

DevicePolicyManager.EXTRA_PROVISIONING_LOGO_URI

用企業徽標來自定義流程。

多 Wi-Fi CA 證書

個人資料所有者和設備所有者可以為一項指定的 Wi-Fi 配置設置多個 CA 證書。如果企業 Wi-Fi 網絡針對有相同 SSID 的獨立接入點設置了獨立 CA，IT 管理員可以使用新setCaCertificates()方法將所有相關 CA 包括在 Wi-Fi 配置中。

添加的 API 有：

WifiEnterpriseConfig.setCaCertificates()

WifiEnterpriseConfig.getCaCertificates()

自定義鎖屏消息

設備所有者可以提供將顯示在鎖屏上的所有者信息。該信息的優先級高於用戶鎖屏消息(如果已設置)。新DevicePolicyManager方法有：

setDeviceOwnerLockScreenInfo()

getDeviceOwnerLockScreenInfo()

工作資料 ConnectionService

個人資料所有者可以為調用後端(調用帳戶)指定一項使用工作特定ConnectionService的工作撥號器應用。工作撥號器會保持僅限工作的調用記錄，並僅依賴於工作聯系人。無論撥號應用是什麼，用戶都將獲得一致的調用內 UI 體驗。傳入到工作調用帳戶的工作調用會與傳入到個人調用帳戶的個人調用相區別。

撥號器應檢查新標記android.telecom.Call.PROPERTY_WORK_CALL，以確定一項調用是否是工作調用。如果一項調用是工作調用，撥號器應通過添加工作徽章等方式做如此指示。

鎖定壁紙

新的用戶限制 (DISALLOW_SET_WALLPAPER) 可以阻止用戶更改他們的壁紙。設備所有者或個人資料所有者仍可以改變壁紙，但只能更改他們控制的用戶或個人資料的壁紙。例如，個人資料所有者不能更改父用戶的壁紙，但主個人資料的個人資料所有者或設備所有者卻可以。想要更改壁紙的個人資料所有者或設備所有者應檢查他們管理的用戶或個人資料是否有壁紙 (isWallpaperSupported()) 以及他們是否被允許更改這個壁紙(通過新方法WallpaperManager.isWallpaperSettingAllowed())。

鎖定用戶圖標

新的用戶限制 (DISALLOW_SET_USER_ICON) 阻止用戶更改其用戶圖標。用戶的設備所有者或個人資料所有者仍可以更改圖標。但是個人資料所有者只能更改其控制的個人資料的用戶圖標。

設備運行狀況監測

設備所有者或個人資料所有者可以使用新的HardwarePropertiesManager界面來檢索有關設備運行狀況的信息，如 CPU 或 GPU 溫度和 CPU 使用率。新的監測界面特別適合監測在遠程位置運行的無人值守設備。

10.作用域目錄訪問

應用(如照片應用)通常只需要訪問外部存儲中的特定目錄，例如Pictures目錄。現有的外部存儲訪問方法未經專門設計，無法輕松地為這些類型的應用提供目標目錄訪問。例如：

在您的清單中請求READ_EXTERNAL_STORAGE或WRITE_EXTERNAL_STORAGE將允許訪問外部存儲上的所有公共目錄，這可能導致訪問的內容超出應用需要的內容。

使用存儲訪問框架通常會讓您的用戶通過一個系統 UI 選取目錄，如果應用始終訪問同一個外部目錄，則該操作沒有任何必要。

Android N 提供簡化的全新 API 以訪問通用外部存儲目錄。

訪問外部存儲目錄

使用StorageManager類獲取適當的StorageVolume實例。然後，通過調用該實例的StorageVolume.createAccessIntent()方法創建一個 Intent。使用此 Intent 訪問外部存儲目錄。若要獲取所有可用卷的列表，包括可移動介質卷，請使用StorageManager.getVolumesList()。

如果您有關於特定文件的信息，使用StorageManager.getStorageVolume(File)來獲得包含該文件的StorageVolume。調用在StorageVolume上的createAccessIntent()以訪問文件的外部存儲目錄。

在二級卷(例如外部 SD 卡)上，當調用StorageVolume.createAccessIntent()以請求訪問整個卷，而不是特定目錄時，傳入“null”。如果您向主要卷傳入“null”，或者如果您傳入無效的目錄名，StorageVolume.createAccessIntent()將返回“null”。

以下代碼段展示如何在主要共享存儲中打開Pictures目錄：

StorageManager sm = (StorageManager)getSystemService(Context.STORAGE_SERVICE);

StorageVolume volume = sm.getPrimaryVolume();

Intent intent = volume.createAccessIntent(Environment.DIRECTORY_PICTURES);

startActivityForResult(intent, request_code);

系統嘗試授予對外部目錄的訪問權限，並使用一個簡化的 UI 向用戶確認訪問權限(如果需要)：

圖 1.一個請求訪問 Pictures 目錄的應用。

如果用戶授予訪問權限，則系統會調用onActivityResult()重寫方法，且結果代碼為Activity.RESULT_OK，Intent 數據包含 URI。使用提供的 URI 訪問目錄信息，與使用存儲訪問框架返回的 URI 類似。

如果用戶不授予訪問權限，則系統會調用onActivityResult()重寫方法，且結果代碼為Activity.RESULT_CANCELED，Intent 數據為 null。

注：獲得特定外部目錄的訪問權限也會獲得該目錄中子目錄的訪問權限。

訪問可移動介質上的目錄

若要使用作用域目錄訪問來訪問可移動介質上的目錄，首先要添加一個用於偵聽MEDIA_MOUNTED通知的BroadcastReceiver，例如：

當用戶裝載可移動介質時，如 SD 卡，系統將發送一則MEDIA_MOUNTED通知。此通知在 Intent 數據中提供一個StorageVolume對象，您可用它訪問可移動介質上的目錄。以下示例訪問可移動介質上的Pictures目錄：

// BroadcastReceiver has already cached the MEDIA_MOUNTED

// notification Intent in mediaMountedIntent

StorageVolume volume = (StorageVolume)

mediaMountedIntent.getParcelableExtra(StorageVolume.EXTRA_STORAGE_VOLUME);

volume.createAccessIntent(Environment.DIRECTORY_PICTURES);

startActivityForResult(intent, request_code);

最佳做法

請盡可能保留外部目錄訪問 URI，這樣即不必重復要求用戶授予訪問權限。在用戶授予訪問權限後，使用目錄訪問 URI 調用getContentResolver().takePersistableUriPermssion()。系統將保留此 URI，後續的訪問請求將返回RESULT_OK，且不會向用戶顯示確認 UI。

如果用戶拒絕授予外部目錄訪問權限，請勿立即再次請求訪問權限。一再不停地請求訪問權限會導致非常差的用戶體驗。如果用戶拒絕了一項請求，而應用再次請求訪問，UI 會顯示一個Don't ask again復選框：