Android 4.0 API

API 級別： 14

Android 4.0 (ICE_CREAM_SANDWICH) 是主要的平台版本，為使用者和應用程式開發人員新增各種新功能。除了下文討論的所有新功能和 API，Android 4.0 也是重要的平台版本，因為 Android 3.x 能在更小的螢幕上，提供大量的 API 和 Holographic 主題。現在，應用程式開發人員有了單一平台和整合式 API 架構，就能透過單一 APK 開發及發布應用程式，為手機、平板電腦等裝置提供 Android 4.0 (API 級別 14) 以上版本，為手機、平板電腦等裝置提供最佳使用者體驗。

對開發人員來說，Android 4.0 平台是 Android SDK 的可下載元件。可下載的平台內含一個 Android 程式庫和系統映像檔，以及一組模擬器外觀等項目。如要開始針對 Android 4.0 進行開發或測試，請使用 Android SDK Manager 將平台下載至 SDK。

API 總覽

下列各節提供 Android 4.0 新 API 的技術總覽。

Google 聯絡人供應程式中的 Social API

ContactsContract 供應商定義的 Contact API 已進一步支援新的社交導向功能，例如裝置擁有者的個人資料，以及使用者邀請個別聯絡人加入裝置上安裝的社群網路。

使用者個人資料

Android 現在包含代表裝置擁有者的個人資料 (如 ContactsContract.Profile 資料表所定義)。保留使用者身分的社交應用程式，可透過在 ContactsContract.Profile 中建立新的 ContactsContract.RawContacts 項目，為使用者個人資料的資料提供資料。也就是說，代表裝置使用者的原始聯絡人不屬於 ContactsContract.RawContacts URI 定義的傳統原始聯絡人表格；您必須改為在 CONTENT_RAW_CONTACTS_URI 的資料表中新增設定檔原始聯絡人。然後將這個表格中的原始聯絡人匯總為可向使用者顯示的單一個人資料 (標示為「我」)。

新增設定檔的原始聯絡人需要 android.Manifest.permission#WRITE_PROFILE 權限。同樣地，如要讀取設定檔資料表，您必須要求 android.Manifest.permission#READ_PROFILE 權限。不過，即使在為設定檔提供資料，大多數應用程式都不需要讀取使用者個人資料。讀取使用者個人資料是機密權限，對於要求此資料的應用程式而言，使用者應會採取特別的手段。

邀請意圖

INVITE_CONTACT 意圖動作可讓應用程式叫用動作，指出使用者想將聯絡人新增至社群網路。接收端應用程式會使用該應用程式邀請指定聯絡人加入社群網路。大多數的應用程式將執行這項作業的接收端。舉例來說，當使用者為列於使用者聯絡詳細資料中的特定社交應用程式選取「新增人脈」時，內建的「使用者」應用程式會叫用邀請意圖。

如要讓您的應用程式顯示在「新增連線」清單中，應用程式必須提供同步轉換器，以便同步處理社群網路中的聯絡人資訊。接著，您必須將 inviteContactActivity 屬性新增至應用程式的同步處理設定檔，以及系統傳送邀請意圖時應啟動的活動的完整名稱，向系統指出應用程式回應 INVITE_CONTACT 意圖。啟動的活動便可從意圖資料擷取相關聯絡人的 URI，並執行必要工作來邀請該聯絡人加入網路，或將使用者新增至使用者的連線。

大型相片

Android 現在支援聯絡人的高解析度相片。現在，當您將相片推送至聯絡人記錄時，系統會將相片處理為之前的 96x96 縮圖 (如先前一樣) 和儲存在新檔案型相片存放區的 256x256「顯示相片」(系統選擇的確切尺寸，日後可能會改變)。您可以在資料列的一般 PHOTO 欄中放置大型相片，讓系統處理成適當的縮圖並顯示相片記錄，藉此為聯絡人新增大型相片。

聯絡人使用情形意見回饋

新的 ContactsContract.DataUsageFeedback API 可讓您追蹤使用者以特定方式聯絡他人的頻率，例如使用者使用各電話號碼或電子郵件地址的頻率。這項資訊有助於改善每個與個別使用者相關聯絡方式的排名，並提供更好的聯絡方式建議。

日曆供應商

新的 Calendar API 可讓您讀取、新增、修改及刪除儲存在日曆提供者中的日曆、活動、參與者、提醒和快訊。

各種應用程式和小工具都能使用這些 API 讀取及修改日曆活動。不過，其中一些最吸引人的用途就是同步處理轉換器，將使用者的日曆從其他日曆服務與日曆提供者同步處理，以便提供所有使用者活動的統一位置。舉例來說，Google 日曆活動會透過 Google Calendar Sync 轉接器與日曆提供者同步處理，以便透過 Android 內建的日曆應用程式查看這些活動。

日曆提供者中的日曆和活動相關資訊的資料模型是由 CalendarContract 定義。使用者的日曆資料都會儲存在由 CalendarContract 各種子類別定義的數個資料表內：

  • CalendarContract.Calendars 資料表包含日曆專屬資訊。此表格中的每一列都包含單一日曆的詳細資料，例如名稱、顏色、同步處理資訊等。
  • CalendarContract.Events 資料表含有事件相關資訊。此表格中的每一列都包含單一活動的資訊，例如活動標題、位置、開始時間、結束時間等。這個事件可能發生一次或重複多次。參與者、提醒和延伸屬性會儲存在不同的資料表中，並使用活動的 _ID 將這些屬性與活動建立連結。
  • CalendarContract.Instances 資料表會保留發生事件的開始和結束時間。此資料表的每一列都代表一次出現次數。針對一次性事件，是將執行個體與事件的一對一對應。如果是週期性事件，系統會自動產生多個資料列，以便對應該事件的多次發生。
  • CalendarContract.Attendees 資料表包含活動參與者或邀請對象資訊。每一列都代表活動的一位邀請對象。該活動會指定邀請對象類型和使用者對活動的回應。
  • CalendarContract.Reminders 資料表內含快訊/通知資料。每一列都代表單一事件的一則快訊。一個活動可以設定多個提醒。每個事件的提醒數量是在 MAX_REMINDERS 中指定，由擁有指定日曆的同步轉接程式設定。提醒是在活動排定前的分鐘數內指定，並指定鬧鐘方式，例如使用快訊、電子郵件或簡訊提醒使用者。
  • CalendarContract.ExtendedProperties 資料表會保留同步轉接程式使用的不透明資料欄位。供應器不會對這個資料表中的項目執行任何動作，除非在相關事件遭到刪除時予以刪除。

如要透過日曆供應程式存取使用者的日曆資料，應用程式必須要求 READ_CALENDAR 權限 (用於讀取權限) 和 WRITE_CALENDAR (針對寫入權限)。

事件意圖

如果您只需要在使用者的日曆中新增事件，就可以使用 ACTION_INSERT 意圖搭配 Events.CONTENT_URI 定義的資料，在 Google 日曆應用程式中啟動可建立新活動的活動。使用意圖不需要任何權限，且您可以使用下列額外項目指定事件詳細資料：

語音信箱供應商

新的語音信箱供應商可讓應用程式在裝置上新增語音留言，以單一視覺呈現方式呈現所有使用者的語音留言。舉例來說，使用者有可能擁有多個語音留言來源，例如一個由手機服務供應商提供，另一個則是來自 IP 網路語音傳遞技術或其他語音服務。這些應用程式可以使用語音信箱供應商 API，在裝置上新增語音留言。接著，內建的「電話」應用程式會在統一的簡報中向使用者顯示所有語音留言。雖然系統的「電話」應用程式是唯一可以讀取所有語音留言的應用程式，但每個提供語音信箱的應用程式都可讀取該系統新增的語音留言，但無法讀取其他服務的語音留言。

由於 API 目前不允許第三方應用程式讀取系統的所有語音留言，因此只有能夠將語音留言傳送給使用者的第三方應用程式，才適合使用語音信箱 API。

VoicemailContract 類別會定義語音留言 Provder 的內容供應器。子類別 VoicemailContract.Voicemails 和 VoicemailContract.Status 提供資料表，應用程式可插入用於裝置儲存空間的語音信箱資料。如需語音信箱供應商應用程式的範例，請參閱「語音信箱供應商示範」。

多媒體

Android 4.0 針對與相片、影片和音樂等媒體互動的應用程式新增數個 API。

媒體效果

新的媒體效果架構可讓您為圖片和影片套用各種視覺效果。舉例來說，您可以使用圖片特效輕鬆修正紅眼、將圖片轉換成灰階、調整亮度、調整飽和度、旋轉圖片、套用魚眼效果等。系統會對 GPU 執行所有效果處理作業，以達到最佳效能。

為了盡可能提高效能，效果會直接套用至 OpenGL 紋理，因此應用程式必須具備有效的 OpenGL 背景，才能使用特效 API。要套用效果的紋理可能來自點陣圖、影片或甚至相機。不過，紋理必須符合下列特定限制：

  1. 這些圖片必須繫結至 GL_TEXTURE_2D 紋理圖片
  2. 必須包含至少一個 mipmap 層級

Effect 物件會定義可套用至圖片影格的單一媒體效果。建立 Effect 的基本工作流程如下：

  1. 從 OpenGL ES 2.0 結構定義呼叫 EffectContext.createWithCurrentGlContext()。
  2. 使用傳回的 EffectContext 呼叫 EffectContext.getFactory()，後者會傳回 EffectFactory 的例項。
  3. 呼叫 createEffect() 並向其傳遞 @link android.media.effect.EffectFactory} 的效果名稱，例如 EFFECT_FISHEYE 或 EFFECT_VIGNETTE。

如要調整效果的參數，請呼叫 setParameter() 並傳遞參數名稱和參數值。每種「效果」類型接受不同的參數，並附上「效果」名稱。例如，EFFECT_FISHEYE 有一個用於扭曲 scale 的參數。

如要對紋理套用效果，請對 Effect 呼叫 apply()，並傳入輸入紋理、寬度和高度，以及輸出紋理。輸入紋理必須繫結至 GL_TEXTURE_2D 紋理圖片 (通常透過呼叫 glTexImage2D() 函式完成)。您可以提供多個 mipmap 層級。如果輸出紋理尚未繫結至紋理圖片，系統會自動將效果繫結為 GL_TEXTURE_2D，並以一個 mipmap 層級 (0) 做為繫結，而大小與輸入的大小相同。

我們保證支援 EffectFactory 中列出的所有效果。不過，並非所有裝置都支援從外部程式庫提供的某些其他效果，因此您必須先呼叫 isEffectSupported()，檢查外部程式庫是否支援所需效果。

遙控器用戶端

新的 RemoteControlClient 可讓媒體播放器啟用遠端控制用戶端 (例如裝置螢幕鎖定畫面) 的播放控制項。媒體播放器也可以針對目前用於遙控器播放的媒體公開相關資訊，例如曲目資訊和專輯封面。

如要為媒體播放器啟用遠端控制用戶端，請使用其建構函式將 RemoteControlClient 例項化，然後向其傳遞廣播 ACTION_MEDIA_BUTTON 的 PendingIntent。該意圖也必須在應用程式中宣告處理 ACTION_MEDIA_BUTTON 事件的明確 BroadcastReceiver 元件。

如要宣告播放器可處理的媒體控制項輸入項目，您必須在 RemoteControlClient 上呼叫 setTransportControlFlags()，並傳遞一組 FLAG_KEY_MEDIA_* 旗標，例如 FLAG_KEY_MEDIA_PREVIOUS 和 FLAG_KEY_MEDIA_NEXT。

接著，您必須將 RemoteControlClient 傳遞至 MediaManager.registerRemoteControlClient() 來註冊。註冊完成後，您在將 RemoteControlClient 執行個體化時宣告的廣播接收器，將在按下遙控器上的按鈕時收到 ACTION_MEDIA_BUTTON 事件。您收到的意圖包含已按下媒體鍵的 KeyEvent，您可以使用 getParcelableExtra(Intent.EXTRA_KEY_EVENT) 從意圖中擷取。

如要顯示遙控器上的媒體播放資訊，請呼叫 editMetaData()，並將中繼資料新增至傳回的 RemoteControlClient.MetadataEditor。您可以為媒體圖片提供點陣圖、數值資訊 (例如經過時間)，以及曲目標題等文字資訊。如需可用金鑰的相關資訊，請參閱 MediaMetadataRetriever 中的 METADATA_KEY_* 旗標。

如需實作範例，請參閱隨機音樂播放器。該播放器提供了相容性邏輯，以便讓在 Android 4.0 裝置上啟用遠端控制用戶端，同時繼續支援搭載 Android 2.1 的裝置。

媒體播放器

  • 如要串流播放「MediaPlayer」的線上媒體，現在需要 INTERNET 權限。如果您使用 MediaPlayer 播放網際網路內容，請務必在資訊清單中新增 INTERNET 權限，否則媒體播放功能將無法在 Android 4.0 版本上運作。
  • setSurface() 可讓您定義 Surface，以做為影片接收器的行為。
  • setDataSource() 允許您透過要求傳送額外的 HTTP 標頭，這對 HTTP(S) 即時串流非常實用
  • HTTP(S) 直播現在會遵循所有要求的 HTTP Cookie

媒體類型

Android 4.0 新增對以下功能的支援：

  • HTTP/HTTPS 直播通訊協定第 3 版
  • ADTS 原始 AAC 音訊編碼
  • WEBP 圖片
  • Matroska 影片

詳情請參閱「支援的媒體格式」。

相機

Camera 類別現已提供 API，用於偵測臉孔及控制對焦和測光區域。

臉部偵測

相機應用程式現在可以使用 Android 的臉部偵測 API 強化自身能力，這種 API 不僅能偵測拍攝主體的臉孔，還能偵測眼睛和嘴巴等特定臉部功能。

如要偵測相機應用程式中的臉孔，您必須呼叫 setFaceDetectionListener() 來註冊 Camera.FaceDetectionListener。接著，您可以呼叫 startFaceDetection() 來啟動相機介面並開始偵測臉孔。

當系統在相機場景中偵測到一或多個臉孔時，會在 Camera.FaceDetectionListener 實作中呼叫 onFaceDetection() 回呼，包括 Camera.Face 物件陣列。

Camera.Face 類別的執行個體會提供偵測到的臉孔各種相關資訊，包括：

  • Rect，用於指定臉孔邊界 (相對於攝影機目前的視野範圍)
  • 介於 1 到 100 之間的整數，表示系統對物件是人臉的信心程度
  • 可用來追蹤多張臉孔的專屬 ID
  • 代表眼睛和嘴巴位置的多個 Point 物件

注意：部分裝置可能不支援臉部偵測，因此請呼叫 getMaxNumDetectedFaces() 進行檢查，並確認傳回值大於零。此外，部分裝置可能不支援眼睛和嘴巴辨識，在這種情況下，Camera.Face 物件中的欄位將為空值。

聚焦和測光區域

相機應用程式現在可以控制相機用於對焦的區域，以及用於測量白平衡和自動曝光的區域。這兩項功能都使用新的 Camera.Area 類別，指定相機目前檢視畫面應聚焦或計量付費的區域。Camera.Area 類別的執行個體會定義具有 Rect 的面積範圍及該區域權重 (使用整數)，代表該區域相對於其他考慮區域的重要性等級。

在設定焦點區域或計量區域之前，請先分別呼叫 getMaxNumFocusAreas() 或 getMaxNumMeteringAreas()。如果傳回零，表示裝置不支援對應的功能。

如要指定使用焦點或計量區域，只要呼叫 setFocusAreas() 或 setMeteringAreas() 即可。每個每個都會使用 Camera.Area 物件的 List，用於指出要考量聚焦或計量的區域。舉例來說，您可以實作一個功能，讓使用者可透過輕觸預覽畫面的某個區域來設定焦點區域，接著將其轉換為 Camera.Area 物件，並要求相機將焦點放在場景的該區域。該區域的焦點或曝光會隨區域中的場景變化而持續更新。

相片的持續自動對焦功能

現在可以在拍照時啟用持續自動對焦 (CAF) 功能。如要在相機應用程式中啟用 CAF，請將 FOCUS_MODE_CONTINUOUS_PICTURE 傳遞至 setFocusMode()。準備好拍攝相片時，請呼叫 autoFocus()。Camera.AutoFocusCallback 會立即收到回呼，指出是否已聚焦。如要在收到回呼後恢復 CAF，您必須呼叫 cancelAutoFocus()。

注意：使用 API 級別 9 新增的 FOCUS_MODE_CONTINUOUS_VIDEO 擷取影片時，也支援持續自動對焦。

其他相機功能

攝影機廣播意圖

  • Camera.ACTION_NEW_PICTURE：表示使用者已拍攝新相片。內建的相機應用程式會在拍照後叫用這個廣播，而第三方相機應用程式也應在拍照後廣播這項意圖。
  • Camera.ACTION_NEW_VIDEO：表示使用者擷取了新影片。內建的相機應用程式會在錄影後叫用這個廣播，而第三方相機應用程式也應在擷取影片後廣播這項意圖。

Android Beam (透過 NFC 進行 NDEF 推送)

Android Beam 是全新的 NFC 功能，可讓您透過裝置將 NDEF 訊息傳送至其他裝置 (也稱為「NDEF 推送」處理程序)。當兩部支援 Android Beam 的 Android 裝置靠近 (約 4 公分) 時，系統就會啟動資料移轉，且裝置背面通常必須碰觸。NDEF 訊息中的資料可以包含您想在裝置之間分享的任何資料。舉例來說，「使用者」應用程式會分享聯絡人、YouTube 分享影片，而瀏覽器會透過 Android Beam 分享網址。

如要使用 Android Beam 在裝置之間傳輸資料，您必須建立 NdefMessage，其中包含您要在前景活動時分享的資訊。然後，您必須採用下列兩種方式之一，將 NdefMessage 傳遞給系統：

如果您想在系統成功將 NDEF 訊息傳送至另一部裝置後，想要執行某些特定程式碼，可以實作 NfcAdapter.OnNdefPushCompleteCallback 並使用 setNdefPushCompleteCallback() 進行設定。收到訊息後，系統便會呼叫 onNdefPushComplete()。

在接收裝置上，系統會分派 NDEF 推送訊息，方法與一般 NFC 標記類似。系統會使用 ACTION_NDEF_DISCOVERED 動作叫用意圖來啟動活動，並提供網址或 MIME 類型根據 NdefMessage 中的第一個 NdefRecord 設定。針對想要回應的活動，您可以針對應用程式重視的網址或 MIME 類型宣告意圖篩選器。如要進一步瞭解標記調度工具，請參閱 NFC 開發人員指南。

如果想讓 NdefMessage 附加 URI，現在可以使用便利的方法 createUri，根據字串或 Uri 物件建構新的 NdefRecord。如果 URI 是特殊格式，且您希望應用程式在 Android Beam 事件期間也接收到這種特殊格式，則應使用相同的 URI 配置為活動建立意圖篩選器，以便接收收到的 NDEF 訊息。

您也應該透過 NdefMessage 傳遞「Android 應用程式記錄」，確保即使其他應用程式篩選出同一個意圖動作，應用程式也能處理收到的 NDEF 訊息。您可以呼叫 createApplicationRecord() 並傳遞應用程式的套件名稱，以建立 Android 應用程式記錄。當另一部裝置收到含有應用程式記錄的 NDEF 訊息，且多個應用程式包含處理指定意圖的活動時，系統一律會根據相符的應用程式記錄，將訊息傳送至應用程式中的活動。如果目標裝置目前尚未安裝您的應用程式，系統會使用 Android 應用程式記錄啟動 Google Play，並將使用者導向應用程式以便進行安裝。

如果您的應用程式未使用 NFC API 來執行 NDEF 推送訊息，Android 會提供預設行為：當應用程式在某部裝置的前景執行，且透過其他 Android 裝置叫用 Android Beam 時，其他裝置會收到包含可識別您應用程式的 Android 應用程式記錄的 NDEF 訊息。如果接收端裝置已安裝該應用程式，系統會啟動該應用程式；如果尚未安裝，Google Play 會開啟並將使用者導向您的應用程式，以便進行安裝。

如要進一步瞭解 Android Beam 和其他 NFC 功能，請參閱 NFC 基本概念開發人員指南。如需使用 Android Beam 的一些程式碼範例，請參閱 Android Beam 示範。

Wi-Fi P2P

Android 現已支援在沒有無線基地台或網際網路連線的情況下，Android 裝置和其他裝置類型 (符合 Wi-Fi 聯盟的 Wi-Fi DirectTM 認證計畫) 之間的 Wi-Fi 點對點 (P2P) 連線。Android 架構提供一組 Wi-Fi P2P API，可讓您在每部裝置支援 Wi-Fi P2P 時探索及連線至其他裝置，然後用遠距離的連線速度比藍牙連線更長。

新套件 android.net.wifi.p2p 包含透過 Wi-Fi 執行點對點連線的所有 API。您需要使用的主要類別是 WifiP2pManager，呼叫 getSystemService(WIFI_P2P_SERVICE) 即可取得。WifiP2pManager 包含可讓您：

您也必須使用其他介面和類別，例如：

如要使用 Wi-Fi P2P API，應用程式必須要求下列使用者權限：

Android 系統會在特定的 Wi-Fi P2P 事件期間播送多種不同的動作：

詳情請參閱 WifiP2pManager 說明文件。另請參閱 Wi-Fi P2P 示範應用程式範例。

藍牙健康裝置

Android 現在支援藍牙健康設定檔裝置，因此您可以建立應用程式，透過藍牙與支援藍牙的健康裝置 (例如心率監測器、血氧儀、溫度計和體重計) 進行通訊。

與一般耳機和 A2DP 設定檔裝置類似，您必須使用 BluetoothProfile.ServiceListener 和 HEALTH 設定檔類型呼叫 getProfileProxy()，才能與設定檔 Proxy 物件建立連線。

取得健康設定檔 Proxy (BluetoothHealth 物件) 後，與配對的健康裝置連線並通訊時，需使用下列新的藍牙類別：

  • BluetoothHealthCallback：您必須擴充這個類別並實作回呼方法，才能接收應用程式註冊狀態和藍牙通道狀態變更的相關更新資訊。
  • BluetoothHealthAppConfiguration：在對 BluetoothHealthCallback 的回呼期間，您會收到這個物件的執行個體，該執行個體會提供可用藍牙健康裝置的設定資訊，您必須用到該執行個體來執行多項作業，例如透過 BluetoothHealth API 啟動及終止連線。

如要進一步瞭解如何使用藍牙健康設定檔，請參閱 BluetoothHealth 的說明文件。

無障礙功能

Android 4.0 提供全新的觸控式探索模式和擴充 API，可讓您提供更多檢視內容或開發進階無障礙服務的相關資訊，為視障使用者改善無障礙體驗。

觸控探索模式

視障使用者現在可以透過輕觸並拖曳手指在螢幕上，聆聽內容的語音說明，藉此探索螢幕。觸控探索模式的運作方式與虛擬遊標類似，可讓螢幕閱讀器在模擬「懸停」事件時，讀取 android:contentDescription 和 setContentDescription() 提供的資訊，就像使用 D-Pad 或軌跡球瀏覽時一樣，螢幕閱讀器能夠辨識說明文字。因此，請留意這一點，您應該為應用程式中的檢視畫面提供說明文字，特別是 ImageButton、EditText、ImageView 和其他可能不自然包含說明文字的小工具。

檢視畫面無障礙功能

如要強化無障礙服務 (例如螢幕閱讀器) 可用的資訊，您可以在自訂 View 元件中，為無障礙事件導入新的回呼方法。

首先請注意，sendAccessibilityEvent() 方法的行為在 Android 4.0 中已變更。與先前的 Android 版本相同，當使用者在裝置上啟用無障礙服務和輸入事件 (例如點擊或懸停) 時，系統會透過呼叫 sendAccessibilityEvent() 通知各個檢視畫面。以往，sendAccessibilityEvent() 的實作會初始化 AccessibilityEvent，並傳送至 AccessibilityManager。新行為需要一些額外的回呼方法，可讓檢視畫面及其父項為事件新增更多背景資訊：

  1. 叫用時，sendAccessibilityEvent() 和 sendAccessibilityEventUnchecked() 方法會延後至 onInitializeAccessibilityEvent()。

    View 的自訂實作項目可能會想實作 onInitializeAccessibilityEvent()，將額外的無障礙資訊附加至 AccessibilityEvent，但也應該呼叫超級實作以提供預設資訊，例如標準內容說明、項目索引等。不過，您也不應在回呼中加入其他文字內容 (下一步會進行)。

  2. 初始化後，如果事件是應填入文字資訊的多種類型之一，檢視畫面便會收到會延遲 onPopulateAccessibilityEvent() 回呼的 dispatchPopulateAccessibilityEvent() 呼叫。

    如果 android:contentDescription 文字遺失或不足，View 的自訂實作通常應實作 onPopulateAccessibilityEvent()，以將額外文字內容新增至 AccessibilityEvent。如要在 AccessibilityEvent 中加入更多文字說明，請呼叫 getText().add()。

  3. 此時，View 會在父項檢視畫面上呼叫 requestSendAccessibilityEvent()，藉此將事件向上傳遞至檢視區塊階層。每個父項檢視區塊都有機會透過新增 AccessibilityRecord 來擴充無障礙資訊資訊，直到其最終到達根檢視畫面為止，透過 sendAccessibilityEvent() 將事件傳送至 AccessibilityManager。

除了上述的新方法 (在擴充 View 類別時很實用) 之外，您也可以擴充 AccessibilityDelegate 並在檢視區塊中使用 setAccessibilityDelegate() 設定，藉此攔截任何 View 上的這些事件回呼。如此一來，檢視區塊中的每個無障礙方法都會將呼叫延後至委派項目中的對應方法。例如，當檢視畫面收到對 onPopulateAccessibilityEvent() 的呼叫時，會將其傳遞至 View.AccessibilityDelegate 中的相同方法。委派程序未處理的任何方法都會直接傳回至檢視畫面，以便得知預設行為。這可讓您只覆寫任何特定檢視畫面所需的方法，而無需擴充 View 類別。

如要維持與 Android 4.0 以下版本的相容性，同時支援新的無障礙 API，請使用最新版本的第 4 版支援資料庫 (位於 Compatibility Package 中)，使用一系列公用程式類別，以回溯相容的設計提供新的無障礙功能 API。

無障礙服務

如果您正在開發無障礙服務，我們已大幅擴展各種無障礙事件的資訊，為使用者提供更進階的無障礙功能意見回饋。請特別注意，系統會根據檢視區塊組成產生事件，提供更詳盡的背景資訊資訊，並可讓無障礙服務週遊檢視區塊階層，以取得額外的檢視區塊資訊，並處理特殊情況。

如果您正在開發無障礙服務 (例如螢幕閱讀器)，您可以透過下列程序存取其他內容資訊和周遊檢視區塊階層：

  1. 收到應用程式的 AccessibilityEvent 後，請呼叫 AccessibilityEvent.getRecord() 以擷取特定 AccessibilityRecord (事件中可能會有多筆記錄)。
  2. 從 AccessibilityEvent 或個別 AccessibilityRecord 中，您可以呼叫 getSource() 來擷取 AccessibilityNodeInfo 物件。

    AccessibilityNodeInfo 代表視窗內容的單一節點，並且採用此格式，可讓您查詢該節點的無障礙功能資訊。AccessibilityEvent 傳回的 AccessibilityNodeInfo 物件會說明事件來源，而 AccessibilityRecord 的來源則說明事件來源的前身。

  3. 透過 AccessibilityNodeInfo，您可以查詢相關資訊、呼叫 getParent() 或 getChild() 來掃遍檢視區塊階層，甚至可以在節點中新增子檢視畫面。

為了讓應用程式以無障礙服務的形式將自身發布到系統，應用程式必須宣告與 AccessibilityServiceInfo 對應的 XML 設定檔。如要進一步瞭解如何建立無障礙服務，請參閱 AccessibilityService 和 SERVICE_META_DATA，瞭解 XML 設定的相關資訊。

其他無障礙 API

如要瞭解裝置的無障礙狀態，AccessibilityManager 具有一些新的 API，例如：

拼字檢查工具服務

新的拼字檢查工具架構可讓應用程式建立拼字檢查工具的方式，類似輸入方法架構 (適用於 IME)。如要建立新的拼字檢查工具，您必須實作擴充 SpellCheckerService 並擴充 SpellCheckerService.Session 類別的服務，以便根據介面回呼方法所提供的文字提供拼字建議。在 SpellCheckerService.Session 回呼方法中，您必須以 SuggestionsInfo 物件形式傳回拼寫建議。

具有拼字檢查工具服務的應用程式必須依服務要求宣告 BIND_TEXT_SERVICE 權限。服務也必須使用 <action android:name="android.service.textservice.SpellCheckerService" /> 宣告意圖篩選器做為意圖的動作，並納入 <meta-data> 元素，宣告拼字檢查工具的設定資訊。

如需程式碼範例，請參閱 拼字檢查工具服務應用程式範例，以及 拼字檢查工具用戶端應用程式範例。

文字轉語音引擎

Android 的文字轉語音 (TTS) API 經過大幅擴充，可讓應用程式更輕鬆地實作自訂 TTS 引擎，而想要使用 TTS 引擎的應用程式則提供數個新的 API，供您選取引擎。

使用文字轉語音引擎

在舊版 Android 中，您可以使用 TextToSpeech 類別，使用系統提供的 TTS 引擎執行文字轉語音 (TTS) 作業，或使用 setEngineByPackageName() 設定自訂搜尋引擎。在 Android 4.0 中，setEngineByPackageName() 方法已淘汰，您現在可以指定引擎，與新的 TextToSpeech 建構函式 (可接受 TTS 引擎的套件名稱) 搭配使用。

您也可以使用 getEngines() 查詢可用的 TTS 引擎。這個方法會傳回 TextToSpeech.EngineInfo 物件清單，其中包含引擎的圖示、標籤和套件名稱等中繼資料。

打造文字轉語音引擎

以往，引擎必須使用未記錄的原生標頭檔案建構引擎。Android 4.0 中有一組完整的架構 API，可用於建構 TTS 引擎。

基本設定需要實作回應 INTENT_ACTION_TTS_SERVICE 意圖的 TextToSpeechService。TTS 引擎的主要工作是在擴充 TextToSpeechService 的服務中的 onSynthesizeText() 回呼期間發生。系統會提供以下兩個物件：

  • SynthesisRequest：包含各種資料，包括要合成的文字、語言代碼、語音速率和語音音調。
  • SynthesisCallback：這是 TTS 引擎傳送產生的語音資料做為串流音訊的介面。首先，引擎必須呼叫 start() 來表示引擎已準備好傳送音訊，然後呼叫 audioAvailable()，並以位元組緩衝區內傳遞音訊資料。引擎透過緩衝區傳遞所有音訊後，請呼叫 done()。

現在該架構支援用來建立 TTS 引擎的真實 API，因此我們已移除原生程式碼實作的支援功能。請參閱有關相容性階層的網誌文章，該階層可用來將舊的 TTS 引擎轉換成新架構。

如需使用新 API 的 TTS 引擎範例，請參閱 Text to Speech Engine 範例應用程式。

網路用量

Android 4.0 可讓使用者精確掌握應用程式目前的網路數據用量。「設定」應用程式提供的控制項可讓使用者管理網路數據用量限制，甚至可以停用個別應用程式的背景資料使用功能。為了避免使用者禁止應用程式從背景存取資料，您應制定策略，有效使用數據連線，並根據可用的連線類型調整用量。

如果應用程式會執行大量網路交易，您應提供使用者設定，讓使用者控管應用程式處理資料的習慣，例如應用程式同步處理資料的頻率、是否只在連上 Wi-Fi 時上傳/下載資料，以及漫遊時是否使用資料等。有了這些控制項，使用者就幾乎不會停用應用程式數據用量上限，因為這樣使用者可能無法全面控制應用程式存取數據用量上限。如要為這些設定提供偏好設定活動，建議您在資訊清單宣告 ACTION_MANAGE_NETWORK_USAGE 動作的意圖篩選器。例如：

<activity android:name="DataPreferences" android:label="@string/title_preferences">
    <intent-filter>
       <action android:name="android.intent.action.MANAGE_NETWORK_USAGE" />
       <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

此意圖篩選器會向系統表明這是控制應用程式資料用量的活動。因此，當使用者透過「設定」應用程式檢查應用程式的數據用量時，系統會顯示「查看應用程式設定」按鈕，可啟動偏好設定活動，方便使用者調整應用程式使用的資料量。

另請注意，getBackgroundDataSetting() 現已淘汰，且一律會傳回 true，請改用 getActiveNetworkInfo()。在嘗試任何網路交易前，請務必一律呼叫 getActiveNetworkInfo() 取得代表目前網路的 NetworkInfo，並查詢 isConnected() 檢查裝置是否已連線。然後查看其他連線屬性，例如裝置是否處於漫遊狀態或已連上 Wi-Fi。

Enterprise

Android 4.0 擴充了企業應用程式的功能，並新增下列功能。

VPN 服務

新的 VpnService 可讓應用程式建構自己的 VPN (虛擬私人網路)，以 Service 形式執行。VPN 服務會為虛擬網路建立具有專屬位址和轉送規則的介面，並使用檔案描述元執行所有讀取和寫入作業。

如要建立 VPN 服務，請使用 VpnService.Builder 來指定網路位址、DNS 伺服器、網路路徑等。完成後，您可以呼叫 establish() 來傳回 ParcelFileDescriptor 來建立介面。

由於 VPN 服務可能會攔截封包，因此會對安全性造成安全性影響。因此，如果您實作 VpnService，則您的服務必須使用 BIND_VPN_SERVICE 以確保只有系統可以繫結 (只有系統獲得此權限，應用程式無法要求此權限)。如要使用 VPN 服務，使用者必須在系統設定中手動啟用。

裝置政策

管理裝置限制的應用程式現在可以使用 setCameraDisabled() 和 USES_POLICY_DISABLE_CAMERA 屬性 (套用於政策設定檔中 <disable-camera /> 元素) 停用相機。

憑證管理

新的 KeyChain 類別提供 API，可讓您匯入及存取系統金鑰儲存庫中的憑證。憑證能簡化安裝 (以驗證使用者身分) 和憑證授權單位憑證 (用來驗證伺服器身分) 這兩種用戶端憑證。網路瀏覽器或電子郵件用戶端等應用程式可存取已安裝的憑證，向伺服器驗證使用者。詳情請參閱 KeyChain 說明文件。

裝置感應器

Android 4.0 新增了兩種感應器類型：

如果裝置同時擁有 TYPE_AMBIENT_TEMPERATURE 和 TYPE_RELATIVE_HUMIDITY 感應器，您可以使用兩者來計算露點和絕對濕度。

先前的溫度感應器 TYPE_TEMPERATURE 已淘汰。請改用 TYPE_AMBIENT_TEMPERATURE 感應器。

此外，Android 的三個合成感應器已獲得大幅改善，現提供更短的延遲時間和更流暢的輸出內容。這些感應器包括重力感應器 (TYPE_GRAVITY)、旋轉向量感應器 (TYPE_ROTATION_VECTOR) 和線性加速感應器 (TYPE_LINEAR_ACCELERATION)。改良後的感應器仰賴陀螺儀感應器來改善輸出，因此感應器只會顯示在有陀螺儀的裝置上。

動作列

ActionBar 已更新，以支援多種新行為。最重要的是，在較小的螢幕上執行時，系統會妥善管理動作列的大小和設定，以便在所有螢幕大小上提供最佳使用者體驗。舉例來說，當螢幕變窄 (例如手機處於直向模式時)，動作列的導覽分頁就會顯示在主要動作列下方的「堆疊列」中。您也可以選擇使用「分割動作列」，在螢幕較窄時，將所有操作項目置於螢幕底部的獨立列中。

分割動作列

如果動作列包含多個操作項目，並非所有操作項目都會顯示在窄螢幕的動作列中，因此系統會將更多項目放入溢位選單。不過，Android 4.0 可讓您啟用「分割動作列」，即可在畫面底部的獨立列中顯示更多操作項目。如要啟用分割動作列，請將含有 "splitActionBarWhenNarrow" 的 android:uiOptions 新增至資訊清單檔案中的 <application> 標記或個別 <activity> 標記。啟用後，當螢幕縮小時，系統會在畫面底部額外新增一個列至所有操作項目，主要動作列中不會顯示任何操作項目。

如果想使用 ActionBar.Tab API 提供的導覽分頁，但不需要頂端主要動作列 (只想在頂端顯示分頁)，請按照上述方式啟用分割動作列，並呼叫 setDisplayShowHomeEnabled(false) 以停用動作列中的應用程式圖示。如果主要動作列中沒有任何其他內容，它就會消失，只剩下頂端的導覽分頁和畫面底部的動作項目。

動作列樣式

如要將自訂樣式套用至動作列，您可以使用新的樣式屬性 backgroundStacked 和 backgroundSplit，將背景可繪項目或顏色分別套用至堆疊列和分割列。您也可以在執行階段使用 setStackedBackgroundDrawable() 和 setSplitBackgroundDrawable() 設定這些樣式。

動作提供者

新的 ActionProvider 類別可讓您建立操作項目的特殊處理常式。動作供應者可以為相關聯的每個操作項目定義動作檢視畫面、預設動作行為和子選單。如果您想建立具有動態行為 (例如可變動作檢視畫面、預設動作或子選單) 的操作項目，想要建立可重複使用的元件，而非處理片段或活動中的各種操作項目轉換作業，建議您擴充 ActionProvider。

舉例來說，ShareActionProvider 是 ActionProvider 的擴充功能，可協助執行動作列的「分享」動作。您可以使用這個動作供應器，顯示含有處理 ACTION_SEND 意圖的應用程式下拉式清單的動作檢視畫面，而不必使用會叫用 ACTION_SEND 意圖的傳統操作項目。當使用者選取要執行動作的應用程式時，ShareActionProvider 會記住該選項，並在動作檢視畫面中提供該選項，以便快速存取與該應用程式共用的內容。

如要為操作項目宣告動作供應器，請在活動選項選單的 <item> 元素中加入 android:actionProviderClass 屬性，並將動作提供者的類別名稱做為值。例如：

<item android:id="@+id/menu_share"
      android:title="Share"
      android:showAsAction="ifRoom"
      android:actionProviderClass="android.widget.ShareActionProvider" />

在活動的 onCreateOptionsMenu() 回呼方法中，從選單項目擷取動作供應程式的執行個體，並設定意圖：

Kotlin

override fun onCreateOptionsMenu(menu: Menu): Boolean {
    menuInflater.inflate(R.menu.options, menu)
    val shareActionProvider = menu.findItem(R.id.menu_share)?.actionProvider as? ShareActionProvider
    // Set the share intent of the share action provider.
    shareActionProvider?.setShareIntent(createShareIntent())
    ...
    return super.onCreateOptionsMenu(menu)
}

Java

public boolean onCreateOptionsMenu(Menu menu) {
    getMenuInflater().inflate(R.menu.options, menu);
    ShareActionProvider shareActionProvider =
          (ShareActionProvider) menu.findItem(R.id.menu_share).getActionProvider();
    // Set the share intent of the share action provider.
    shareActionProvider.setShareIntent(createShareIntent());
    ...
    return super.onCreateOptionsMenu(menu);
}

如需使用 ShareActionProvider 的範例，請參閱 ApiDemos 中的 ActionBarShareActionProviderActivity。

可收合動作檢視畫面

提供動作檢視畫面的動作項目，現在可以在動作檢視狀態與傳統操作項目狀態之間切換。先前只有以 SearchView 做為動作檢視畫面時支援收合，但現在您可以為任何操作項目新增動作檢視畫面，並在展開狀態 (顯示操作檢視畫面) 和收合狀態 (顯示操作項目) 之間進行切換。

如要宣告含有動作檢視畫面的操作項目可收合，請在選單 XML 檔案中 <item> 元素的 android:showAsAction 屬性中加入 “collapseActionView" 旗標。

如要在動作檢視畫面切換展開和收合時接收回呼，請呼叫 setOnActionExpandListener()，以各自的 MenuItem 註冊 MenuItem.OnActionExpandListener 的執行個體。一般而言，您應該在 onCreateOptionsMenu() 回呼期間執行此操作。

如要控管可收合的動作檢視畫面，您可以在個別的 MenuItem 上呼叫 collapseActionView() 和 expandActionView()。

建立自訂動作檢視畫面時，您也可以實作新的 CollapsibleActionView 介面，以便在檢視畫面展開和收合時接收回呼。

動作列的其他 API

  • setHomeButtonEnabled() 可讓您指定圖示/標誌的行為是作為前往首頁的按鈕，還是「向上」(傳遞「true」讓其行為成為按鈕)。
  • setIcon() 和 setLogo() 可讓您定義執行階段的動作列圖示或標誌。
  • Fragment.setMenuVisibility() 可讓您啟用或停用片段宣告的選項選單項目顯示設定。如果片段已新增至活動但沒有顯示，這項功能就很實用，因此必須隱藏選單項目。
  • FragmentManager.invalidateOptionsMenu() 可讓您在片段生命週期的不同狀態中使活動選項選單失效，因而無法使用 Activity 中的對等方法。

使用者介面和檢視畫面

Android 4.0 推出了各種新的檢視畫面和其他 UI 元件。

GridLayout

GridLayout 是一個新的檢視區塊群組，會將子檢視區塊以矩形格線放置。與 TableLayout 不同，GridLayout 採用扁平的階層，而非使用資料表列等中繼檢視區塊來提供結構。子項改為指定應佔用哪些資料列和資料欄 (儲存格可橫跨多個資料列和/或資料欄)，而根據預設，網格的列與欄會依序排列。GridLayout 方向會決定依序排列的子項是否預設以水平或垂直方向排列。您可以使用新 Space 檢視畫面的例項，或針對子項設定相關邊界參數，來指定子項之間的空間。

如需使用 GridLayout 的範例，請參閱 ApiDemos。

TextureView

TextureView 是新的檢視畫面，可讓您顯示內容串流，例如影片或 OpenGL 場景。雖然 TextureView 與 SurfaceView 類似，但其運作方式與一般檢視畫面類似，而不是建立另一個視窗，因此您可以將其視為任何其他的 View 物件。舉例來說，您可以套用轉換作業、使用 ViewPropertyAnimator 製作動畫效果，或是使用 setAlpha() 調整不透明度。

請注意，TextureView 只適用於硬體加速視窗。

詳情請參閱 TextureView 說明文件。

切換小工具

新的 Switch 小工具是雙狀態切換鈕，使用者可以拖曳到其中一側或另一側 (或直接輕觸)，以便在兩個狀態間切換選項。

您可以使用 android:textOn 和 android:textOff 屬性指定開關時要顯示的文字。android:text 屬性也允許您在切換按鈕旁邊放置標籤。

如需使用切換按鈕的範例，請參閱 switches.xml 版面配置檔案和個別的切換鈕 活動。

Android 3.0 推出了 PopupMenu，可建立簡短的內容相關選單，會在您指定的錨點 (通常是在所選項目的時間點) 彈出。Android 4.0 擴充了 PopupMenu，並提供幾項實用功能：

偏好設定

新的 TwoStatePreference 抽象類別可做為提供兩個狀態選項選項的偏好設定依據。新的 SwitchPreference 是 TwoStatePreference 的擴充功能，可在偏好設定檢視畫面中提供 Switch 小工具，讓使用者不必開啟其他偏好設定畫面或對話方塊，即可開啟或關閉設定。舉例來說，「設定」應用程式會使用 SwitchPreference 進行 Wi-Fi 和藍牙設定。

系統主題

所有以 Android 4.0 為目標的應用程式 (透過將 targetSdkVersion 或 minSdkVersion 設為 “14" 以上版本) 的預設主題現已成為「裝置預設」主題：Theme.DeviceDefault。這可以是深色 Holo 主題，或是特定裝置定義的其他深色主題。

執行相同版本的 Android 時，Theme.Holo 主題系列保證不會在裝置間變更。如果明確將任何 Theme.Holo 主題套用至活動，就能放心，這些主題不會在相同平台版本內的不同裝置上變更字元。

如果想讓應用程式與整體裝置主題 (例如不同的原始設備製造商 (OEM) 為系統提供不同預設主題) 融入應用程式，請明確套用 Theme.DeviceDefault 系列的主題。

選項選單按鈕

從 Android 4.0 開始，您會注意到手機不再需要選單硬體按鈕。不過，如果現有的應用程式提供「選項選單」，並預期有「選單」按鈕，您就不用擔心。為確保現有應用程式能繼續正常運作，系統會針對為舊版 Android 設計的應用程式提供畫面上的選單按鈕。

為獲得最佳使用者體驗，新上架和更新後的應用程式應改用 ActionBar 來提供選單項目存取權，並將 targetSdkVersion 設為 "14"，以利用最新的架構預設行為。

系統 UI 瀏覽權限控制項

自 Android 推出初期，系統就代管了一個稱為「狀態列」的 UI 元件，這個元件位於手機頂端以提供資訊，例如電信業者訊號、時間和通知等等。Android 3.0 新增了平板電腦裝置的系統列，位於畫面底部，可提供系統導覽控制項 (主畫面、返回等)，以及傳統上由狀態列提供的元素介面。在 Android 4.0 中，系統會提供一種稱為「導覽列」的新型系統 UI。您可以考慮，導覽列是經過調整的系統列版本，專為手機設計，這可為沒有硬體對應系統的裝置提供導覽控制項，但不會顯示系統列的通知 UI 和設定控制項。因此，提供導覽列的裝置也會在頂端顯示狀態列。

今天，您可以使用 FLAG_FULLSCREEN 標記隱藏手機的狀態列。在 Android 4.0 中，已更新控制系統列顯示設定的 API，更準確地反映系統列和導覽列的行為：

  • SYSTEM_UI_FLAG_LOW_PROFILE 旗標會取代 STATUS_BAR_HIDDEN 旗標。設定後，此標記會為系統列或導覽列啟用「低設定檔」模式。導覽按鈕會變暗，並隱藏系統列中的其他元素。啟用此功能可以有效製作更多沉浸式遊戲，且不會因系統導覽按鈕而受到干擾。
  • SYSTEM_UI_FLAG_VISIBLE 旗標會取代 STATUS_BAR_VISIBLE 旗標，要求顯示系統列或導覽列。
  • SYSTEM_UI_FLAG_HIDE_NAVIGATION 是新旗標，可要求完全隱藏導覽列。請注意，這個方法僅適用於部分手機使用的導覽列 (「不會」隱藏平板電腦上的系統列)。系統收到使用者輸入內容後，導覽列會立即返回檢視畫面。因此，這個模式主要適用於影片播放，或其他需要整個螢幕，但不需要使用者輸入內容的情況。

您可以為活動中的任何檢視畫面呼叫 setSystemUiVisibility()，為系統列和導覽列設定每個標記。視窗管理員會結合 (OR 合併) 視窗中所有檢視畫面的所有標記，只要視窗有輸入焦點，就能將這些標記套用至系統 UI。如果視窗失去輸入焦點 (使用者離開應用程式，或顯示對話方塊)，標記就會停止運作。同樣地，如果您從檢視區塊階層中移除這些檢視區塊，就不會套用旗標。

如要將活動中的其他事件與系統 UI 的瀏覽權限變更同步處理 (例如在系統 UI 隱藏時隱藏動作列或其他 UI 控制項)，您必須註冊 View.OnSystemUiVisibilityChangeListener，以便在系統列或導覽列的顯示變更時收到通知。

如需不同系統 UI 選項的示範，請參閱「 OverscanActivity」類別。

輸入架構

Android 4.0 開始支援遊標懸停事件，以及新的觸控筆和滑鼠按鈕事件。

懸停事件

View 類別現已支援「懸停」事件，以便透過指標裝置 (例如滑鼠或其他驅動螢幕遊標的裝置) 進行更豐富的互動。

如要在檢視區塊上接收懸停事件，請實作 View.OnHoverListener 並使用 setOnHoverListener() 註冊。當檢視畫面上發生懸停事件時，事件監聽器會收到對 onHover() 的呼叫，並提供接收事件的 View 和說明已發生的懸停事件類型的 MotionEvent。懸停事件可以是下列任一項：

如果 View.OnHoverListener 處理懸停事件，應從 onHover() 傳回 true。如果事件監聽器傳回 false，則會照常將懸停事件分派給父項檢視畫面。

如果應用程式使用按鈕或其他小工具，根據目前狀態變更外觀，您現在可以在狀態清單可繪項目中使用 android:state_hovered 屬性，當遊標懸停在檢視區塊上時，提供不同的背景可繪項目。

如需新懸停事件的示範，請參閱 APIDemos 中的 Hover 類別。

觸控筆和滑鼠按鈕事件

Android 現在提供用於接收觸控筆輸入裝置輸入內容的 API，例如數位化平板電腦週邊裝置或支援觸控筆的觸控螢幕。

觸控筆輸入的運作方式與觸控或滑鼠輸入類似。當觸控筆與數位化工具接觸時，應用程式會收到觸控事件，就像使用手指觸碰螢幕時一樣。當觸控筆懸停在數位化工具上方時，應用程式會收到懸停事件，就像在未按下任何按鈕時，滑鼠遊標跨螢幕移動時一樣。

您的應用程式可以使用 getToolType() 查詢與 MotionEvent 中每個指標相關聯的「工具類型」，藉此區別手指、滑鼠、觸控筆和橡皮擦輸入。目前定義的工具類型為：TOOL_TYPE_UNKNOWN、TOOL_TYPE_FINGER、TOOL_TYPE_MOUSE、TOOL_TYPE_STYLUS 和 TOOL_TYPE_ERASER。透過查詢工具類型，應用程式可以選擇以不同的方式 (例如手指或滑鼠輸入) 處理觸控筆輸入作業。

應用程式也可以使用 getButtonState() 查詢 MotionEvent 的「按鈕狀態」，藉此查詢要按下哪個滑鼠或觸控筆按鈕。目前定義的按鈕狀態為：BUTTON_PRIMARY、BUTTON_SECONDARY、BUTTON_TERTIARY、BUTTON_BACK 和 BUTTON_FORWARD。為方便起見，系統會自動將返回和向前滑鼠按鈕對應至 KEYCODE_BACK 和 KEYCODE_FORWARD 鍵。您的應用程式可以處理這些鍵，以支援使用滑鼠按鈕的返回和向前導覽。

除了精確測量接觸的位置和壓力外，某些觸控筆輸入裝置還會報告觸控筆尖和數位化器、觸控筆傾斜角度和觸控筆方向角度的距離。應用程式可以使用 getAxisValue() 搭配 AXIS_DISTANCE、AXIS_TILT 和 AXIS_ORIENTATION 的軸代碼，查詢這項資訊。

如需工具類型、按鈕狀態和新軸代碼的示範，請參閱 ApiDemos 中的 TouchPaint 類別。

屬性

新的 Property 類別可讓您快速、安全又輕鬆地指定任何物件的屬性，讓呼叫端可以一般設定/取得目標物件的值。也可以傳遞欄位/方法參照的功能，並讓程式碼在不瞭解欄位/方法細節的情況下，設定/取得屬性的值。

舉例來說，如果您想針對物件 foo 設定 bar 欄位的值，先前需要執行以下操作：

Kotlin

foo.bar = value

Java

foo.bar = value;

如要呼叫基礎私人欄位 bar 的 setter，先前應執行此操作：

Kotlin

foo.setBar(value)

Java

foo.setBar(value);

不過，如果您想傳遞 foo 例項，並讓其他程式碼設定 bar 值，則在 Android 4.0 版之前完全無法執行這項操作。

透過 Property 類別，您可以在 Foo 類別上宣告 Property 物件 BAR，以便設定 Foo 類別例項 foo 上的欄位，如下所示：

Kotlin

BAR.set(foo, value)

Java

BAR.set(foo, value);

View 類別現在會運用 Property 類別來設定各種欄位，例如在 Android 3.0 中新增的轉換屬性 (ROTATION、ROTATION_X、TRANSLATION_X 等)。

ObjectAnimator 類別也會使用 Property 類別，因此您可以使用 Property 建立 ObjectAnimator，這比以字串為基礎的方法更快、更有效率，且更類型安全。

硬體加速

從 Android 4.0 開始，如果應用程式將 targetSdkVersion 或 minSdkVersion 設為 “14" 或以上版本，所有視窗的硬體加速功能都會預設為啟用。硬體加速通常可以使動畫更流暢、捲動更順暢，以及整體效能更佳，可回應使用者互動。

如有需要，您可以使用個別 <activity> 元素的 hardwareAccelerated 屬性或 <application> 元素，手動停用硬體加速。您也可以呼叫 setLayerType(LAYER_TYPE_SOFTWARE)，停用個別檢視畫面的硬體加速。

如要進一步瞭解硬體加速，包括不支援的繪圖作業清單，請參閱「硬體加速」文件。

JNI 變更

在舊版 Android 中，JNI 本機參照並非間接處理，Android 使用的是直接指標。只要垃圾收集器沒有移動物件，這並不是問題，但它似乎有作用，因為這樣可以編寫錯誤的程式碼。在 Android 4.0 中，系統現在會使用間接參照來偵測這些錯誤。

JNI 本機參照的細節說明，請參閱「JNI 提示」中的「本地和全域參考資料」。在 Android 4.0 中，已增強 CheckJNI 來偵測這些錯誤。請觀看 Android 開發人員網誌，瞭解 JNI 參照的常見錯誤及解決方法。

這項異動僅影響 JNI 實作項目，只會將 targetSdkVersion 或 minSdkVersion 設為 “14" 以上，以指定 Android 4.0 為目標的應用程式。如果您已將這些屬性設為任何較低的值，JNI 本機參照的運作方式會與先前的版本相同。

WebKit

  • WebKit 已更新至 534.30 版
  • 在 WebView 和內建瀏覽器中支援印度字型 (梵文、孟加拉文和泰米爾文，包括合併字符所需的複雜字元支援)
  • 在 WebView 和內建瀏覽器中支援衣索比亞、喬治亞文和亞美尼亞文字型
  • 支援 WebDriver，可讓您輕鬆測試使用 WebView 的應用程式

Android 瀏覽器

「瀏覽器」應用程式新增下列功能以支援網頁應用程式：

權限

下列是新的權限：

裝置功能

以下是新的裝置功能：

如需 Android 4.0 (API 級別 14) 所有 API 變更的詳細檢視畫面，請參閱 API 差異報表。

先前的 API

除了上述所有功能外，Android 4.0 自然也支援先前版本中的所有 API。由於 Android 3.x 平台僅適用於大螢幕裝置，所以如果您是開發主要手機，您可能不知道這些近期版本裡新增到 Android 的所有 API。

以下是一些您可能錯過的最知名 API，這些 API 現在也可用於手機：

Android 3.0 版
  • Fragment：這個架構元件可讓您將活動的不同元素分割成獨立模組，藉此定義自身的 UI 和生命週期。請參閱「片段」開發人員指南。
  • ActionBar：取代活動視窗頂端的傳統標題列。它的左側角落包括應用程式標誌，並提供選單項目的全新介面。請參閱「動作列」開發人員指南。
  • Loader：一種架構元件，可加速載入資料與 UI 元件，在不封鎖主執行緒的情況下動態載入資料。請參閱「載入器」開發人員指南。
  • 系統剪貼簿：應用程式可以將資料 (除了文字外) 複製及貼上整個系統的剪貼簿。裁剪的資料可以是純文字、URI 或意圖。請參閱複製及貼上開發人員指南。
  • 拖曳：一組內建於 View 架構的 API，可協助執行拖曳作業。請參閱「拖曳」開發人員指南。
  • 全新的彈性動畫架構可讓您為任何物件 (View、Drawable、Fragment、Object 或其他任何項目) 的任意屬性建立動畫，並定義時間長度、內插、重複等動畫元素。新的架構讓 Android 中的動畫比以往更加簡單。請參閱「屬性動畫」開發人員指南。
  • RenderScript 圖形和運算引擎：RenderScript 在原生層級提供高效能 3D 圖形轉譯和 Compute API，也就是您以 C (C99 標準) 編寫程式碼，提供您預期在原生環境中進行的效能類型，同時在各種 CPU 和 GPU 之間保有可攜性。請參閱 RenderScript 開發人員指南。
  • 硬體加速 2D 圖形：現在您可以在資訊清單元素的 <application> 元素或個別 <activity> 元素中設定 {android:hardwareAccelerated="true"}，藉此為應用程式啟用 OpenGL 轉譯器。進而讓動畫更流暢、捲動更順暢，整體效能更佳，更能回應使用者互動。

    注意：如果您將應用程式的 minSdkVersion 或 targetSdkVersion 設為 "14" 以上，系統預設會啟用硬體加速。

  • 還有許多實用功能。詳情請參閱 Android 3.0 平台注意事項。
Android 3.1
  • USB API：提供強大的新 API，可將已連線的周邊裝置與 Android 應用程式整合。API 以平台內建的 USB 堆疊與服務為基礎，包括支援 USB 主機和裝置互動。請參閱「USB 主機和配件」開發人員指南。
  • MTP/PTP API：應用程式可以直接與已連接的相機和其他 PTP 裝置互動，以便在裝置連接或移除時接收通知、管理裝置上的檔案和儲存空間，以及傳輸檔案和中繼資料。MTP API 會實作 MTP (媒體傳輸通訊協定) 規格的 PTP (圖片傳輸通訊協定) 子集。請參閱 android.mtp 說明文件。
  • RTP API：Android 將 API 提供給其內建的 RTP (即時傳輸通訊協定) 堆疊，供應用程式用來管理隨選或互動式資料串流。特別是，如果應用程式提供 VOIP、推送轉播、會議通訊和音訊串流功能，就能使用 API 啟動工作階段，並透過任何可用網路傳輸或接收資料串流。請參閱 android.net.rtp 說明文件。
  • 支援搖桿和其他一般動作輸入。
  • 如要瞭解更多新 API，請參閱 Android 3.1 平台注意事項。
Android 3.2
  • 新畫面支援 API，可讓您進一步控制應用程式在不同螢幕大小下的顯示方式。API 擴充現有的螢幕支援模型，能夠按照密度獨立像素單位 (例如 600dp 或 720dp 寬度) 精確指定特定螢幕大小範圍，而非依其概略螢幕大小 (例如大或特大尺寸) 進行精確指定。舉例來說，為協助您區分 5 吋和 7 吋裝置，而這兩種裝置在傳統上都會歸類為「大」螢幕，這點十分重要。請參閱《 New Tools for Managing Screen Sizes》(管理螢幕大小的新工具) 網誌文章。
  • 為 <uses-feature> 新增常數，可宣告橫向或直向螢幕方向要求。
  • 現在螢幕方向變更時，裝置「螢幕大小」設定也會變更。如果應用程式指定的 API 級別為 13 以上，則您必須一併處理 "screenSize" 設定變更，才能一併處理 "orientation" 設定變更。詳情請參閱 android:configChanges。
  • 如要瞭解其他新的 API，請參閱 Android 3.2 平台注意事項。

API 級別

Android 4.0 API 會獲派一個整數 ID (14)，這組 ID 儲存在系統本身中。這種 ID 稱為「API 級別」，可讓系統在安裝應用程式前，正確判斷應用程式是否與系統相容。

如要在應用程式中使用 Android 4.0 中導入的 API，您需要針對支援 API 級別 14 以上的 Android 平台編譯應用程式。視您的需求而定，您可能還需要在 <uses-sdk> 元素中加入 android:minSdkVersion="14" 屬性。

詳情請參閱「什麼是 API 級別？」一文。