Android KitKat

Android 4.4 KitKat をご紹介します。

Android KitKat によって、Android の最も革新的で、最も美しく、最も便利な機能のすべてを、世界中のより多くの端末でお楽しみいただけるようになりました。

このドキュメントでは、デベロッパー向けの最新情報について簡単に紹介します。

KitKat のユーザー向けの新機能については、www.android.com をご覧ください。

Android をだれでも利用できるように

Android 4.4 は、かつてないほど幅広い端末で高速、スムーズ、レスポンシブに実行できるように設計されています。たとえば世界で数百万台も使われている、わずか 512MB の RAM を搭載したエントリーレベルの端末も対象となっています。

KitKat は、すべての主要コンポーネントを合理化してメモリ消費量を削減し、革新的でメモリ効率の高いレスポンシブなアプリを作成するための新しい API とツールを導入しました。

次世代の Android 端末を構築している OEM は、対象となる推奨事項とオプションを活用して、メモリの少ない端末でも Android 4.4 を効率的に実行できます。Dalvik JIT コード キャッシュ チューニング、Kernel Samepage Merging（KSM）、zRAM へのスワップ、その他の最適化により、メモリを管理できます。新しい構成オプションを使用して、OEM はプロセスのメモリ不足レベルの調整、グラフィックのキャッシュ サイズの設定、メモリの再要求の制御などを行えます。

Android 自体も、システム全体にわたってメモリ管理を改善し、メモリ消費量を削減しました。コア システムのプロセスはヒープの使用を削減し、RAM を大量に消費するアプリからより積極的にシステム メモリを保護するようになりました。ネットワーク接続の変更などに伴い複数のサービスを同時に開始するとき、Android は少数のグループに分けたサービスを順次起動し、メモリ需要のピークを避けるようになっています。

デベロッパーは、 Android 4.4 によって、すべての端末で効率良くレスポンシブに動作するアプリを配信できます。新しい API、 ActivityManager.isLowRamDevice()を使用すると、端末のメモリ設定に合わせてアプリの動作を調整できます。エントリーレベルの端末でサポートするユースケースを考慮し、必要に応じてメモリ消費量の多い機能を修正または無効にすることができます。メモリの少ない端末向けのアプリの最適化については、こちらをご覧ください。

新しいツールを使用すると、アプリのメモリ消費量に関する詳細な情報を得ることができます。procstats ツールでは、時間の経過に伴うメモリ消費量のほか、実行時間、フォアグラウンド アプリとバックグラウンド サービスのメモリ消費量の詳細を確認できます。端末上のビューも新しいデベロッパー オプションとして利用できます。meminfo ツールは、メモリの使用傾向と問題を特定しやすくするために機能が強化され、これまで表示されていなかった追加のメモリ オーバーヘッドもわかるようになりました。

ホスト カード エミュレーションによる新しい NFC 機能

Android 4.4 では、ホスト カード エミュレーション（HCE）を使用した安全な NFC ベースのトランザクションのサポートが導入され、決済、ロイヤルティ プログラム、カード アクセス、乗車パス、その他のカスタム サービスに利用できます。HCE を使用すると、Android 端末上のどのアプリでも NFC スマートカードをエミュレートでき、タップして選択したアプリでトランザクションを開始できます。端末に セキュア エレメント（SE）をプロビジョニングする必要はありません。新しい リーダーモード を使用して、HCE カードやその他の NFC ベースのトランザクションのリーダーとしてアプリを動作させることもできます。

Android HCE は、トランザクションで非接触式 ISO/IEC 14443-4（ISO-DEP）プロトコルを使用する ISO/IEC 7816 ベースのスマートカードをエミュレートします。これらのカードは、既存の EMVCO NFC 決済インフラストラクチャなど、多くのシステムで現在使用されています。Android は ISO/IEC 7816-4 で定義されたアプリケーション識別子（AID）を使用して、適切な Android アプリケーションにトランザクションをルーティングします。

アプリは、マニフェスト ファイルで、サポートする AID と利用可能なサポートの種類（「決済」など）を示すカテゴリ識別子を宣言します。複数のアプリが同じカテゴリ、同じ AID をサポートしている場合、Android は使用するアプリをユーザーが選択できるダイアログを表示します。

ユーザーが POS 端末で決済するためにタップすると、システムが優先される AID を抽出し、適切なアプリにルーティングします。アプリはトランザクション データを読み取り、ローカルまたはネットワークベースのサービスを使用して確認し、トランザクションを完了します。

Android HCE を使用するには、端末に NFC コントローラーが必要です。HCE のサポートは既にほとんどの NFC コントローラーで幅広く対応しており、HCE と SE の両方のトランザクションの動的サポートも提供しています。 Android 4.4 端末は、HCE を使用して簡単に決済できるタップ＆ペイも搭載する予定です。

印刷フレームワーク

Wi-Fi またはクラウドホスティング型サービス（Google クラウド プリントなど）を介して、Android アプリであらゆる種類のコンテンツを印刷できるようになりました。印刷対応アプリでは、利用可能なプリンターを検出し、用紙のサイズを変更し、印刷する特定のページを選び、ドキュメント、画像、ファイルなどほぼ種類を問わず印刷できます。

Android 4.4 では、印刷用のネイティブ プラットフォームのサポートが追加され、印刷およびプリンターの新機種のサポートの追加を管理する API も含まれています。このプラットフォームでは、印刷をリクエストするアプリと、印刷リクエストを処理するインストール済みの印刷サービスの間を仲介する Print Manager が提供されます。Print Manager は印刷用の共有サービスとシステム UI を提供し、どのアプリからでも一貫した方法で印刷を制御できます。Print Manager は、アプリから印刷サービスまでのプロセス全体にわたり、受け渡されるコンテンツのセキュリティも確保します。

プリンターのメーカーは、新しい API を使用して、独自の印刷サービスを開発できます。これは、特定の種類のプリンターと通信するためにベンダー固有のロジックとサービスを追加する交換可能なコンポーネントです。印刷サービスを作成して Google Play で配布すると、ユーザーが簡単にそのサービスを見つけて自分の端末にインストールできます。その他のアプリと同様に、印刷サービスはいつでも OTA で更新できます。

クライアント アプリは新しい API を使用して、最小限のコードの変更で印刷機能をアプリに追加できます。ほとんどの場合、アクションバーおよび印刷するアイテムを選ぶ UI に、印刷アクションを追加します。API を実装して、印刷ジョブの作成、Print Manager へのステータスの照会、ジョブのキャンセルも行えます。これにより、ローカルにある画像やドキュメントから、ネットワーク データ、キャンバスにレンダリングされたビューまで、ほぼあらゆる種類のコンテンツを印刷できます。

互換性を最大限に確保するため、Android では印刷の主なファイル形式として PDF を使用します。印刷の前に、アプリは適切にページ分割された PDF 版のコンテンツを生成する必要があります。利便性を高めるため、Print API はネイティブ クラスと WebView ヘルパー クラスを提供しており、標準の Android 描画 API を使用して PDF を作成できます。アプリがコンテンツの描画に対応していれば、速やかに印刷用の PDF を作成できます。

Android 4.4 を実行するほとんどの端末には Google クラウド プリントのほか、印刷をサポートする Google アプリ（Chrome, ドライブ、ギャラリー、QuickOffice など）があらかじめインストールされています。

ストレージ アクセス フレームワーク

新しいストレージ アクセス フレームワークを利用することで、ユーザーは設定したドキュメント ストレージ プロバイダ全体から簡単にドキュメント、画像、その他のファイルを参照して開くことができます。標準の使いやすい UI により、アプリやプロバイダを通じて一貫性のある方法でファイルを参照したり、最近使用したファイルにアクセスしたりできます。

サービスをカプセル化する新しいドキュメント プロバイダ クラスを実装することで、クラウドやローカル ストレージ サービスをエコシステムに参加させることができます。provider クラスには、プロバイダをシステムに登録し、プロバイダでのドキュメントの閲覧、読み取り、書き込みを管理するために必要なすべての API が含まれています。ドキュメント プロバイダは、テキスト、写真、壁紙、動画、オーディオなど、ファイルとして表示できるすべてのリモートまたはローカル データへのアクセスをユーザーに提供します。

クラウドまたはローカル サービス向けにドキュメント プロバイダを作成する場合、既存の Android アプリの一部としてユーザーに配信できます。そのアプリをダウンロードしてインストールすると、フレームワークに参加しているアプリからすぐにサービスを利用できます。これにより、ユーザーがサービスを見つけやすくなるため、関心とユーザー エンゲージメントが高まります。

ファイルまたはドキュメントを管理するクライアント アプリを開発する場合は、新しい CREATE_DOCUMENT インテントまたは OPEN_DOCUMENT インテントを使用してファイルを開く、または作成するだけで、ストレージ アクセス フレームワークと統合できます。

1 回だけでクライアント アプリをすべてのプロバイダ向けに統合できます。ベンダー固有のコードは不要です。ユーザーがプロバイダを追加または削除すると、設定したサービスにアプリから引き続きアクセスできます。コードの変更やアップデートは必要ありません。

ストレージ アクセス フレームワークは既存の GET_CONTENT インテントと統合されているため、ブラウジング用の新しいシステム UI から以前のコンテンツやデータ ソースにもすべてアクセスできます。アプリは引き続き GET_CONTENT をデータのインポート手段として使用できます。ストレージ アクセス フレームワークとブラウジング用のシステム UI によって、ユーザーは容易に幅広いソースからデータを検索およびインポートできます。

Android 4.4 を実行するほとんどの端末には、あらかじめドキュメント プロバイダとして統合された Google Drive とローカル ストレージが含まれており、ファイルを使って作業する Google アプリもこの新しいフレームワークを使用します。

省電力センサー

センサーのバッチ処理

Android 4.4 では、ハードウェア センターのバッチ処理のプラットフォーム サポートが導入されました。この新たな最適化によって、実行中のセンサー アクティビティによる消費電力を大幅に削減できます。

センサーのバッチ処理によって、Android は端末のハードウェアと連携して、センサーイベントが検出されるたびに個別に処理するのではなく、バッチ処理で効率的にセンサーイベントを収集および配信します。これにより、端末のアプリケーション プロセッサはバッチ処理されたイベントが配信されるまで、低電力のアイドル状態を維持します。標準のイベント リスナーを使用すると、どのセンサーのバッチ処理されたイベントでもリクエストできます。また、バッチを受け取る間隔を制御できます。また、バッチサイクル間にイベントの即時配信をリクエストすることもできます。

センサーのバッチ処理は、フィットネス、位置情報のトラッキング、監視など、低電力で長時間実行するユースケースに理想的です。画面がオフでシステムがスリープ状態でもアプリの効率を高めることができ、センサーイベントを継続的に追跡できます。

センサーのバッチ処理は現在、Nexus 5 で利用できます。Google では、できるだけ早く、より多くの端末でこの機能を利用できるようにチップセット パートナーとともに取り組んでいます。

Step Detector と Step Counter

Android 4.4 では、Step Detector と Step Counter という 2 つの新しいコンポーネント センサーのプラットフォーム サポートが追加されています。この機能により、アプリはユーザーが歩いたり、走ったり、階段を上ったりしたときの歩数を追跡できます。これらの新しいセンサーは、消費電力を抑えるためにハードウェアに実装されています。

Step Detector は、加速度計の入力を分析し、ユーザーの歩行を認識し、1 歩ごとにイベントをトリガーします。Step Counter は、最後に端末が再起動されてからの歩数を追跡し、歩数が変わるたびにイベントをトリガーします。ロジックとセンサーの管理機能はプラットフォームおよび基盤となるハードウェアに組み込まれているため、アプリで独自の検出アルゴリズムをメンテナンスする必要はありません。

Step Detector と Step Counter の各センサーは Nexus 5 で利用できます。Google では、できるだけ早く、新しい端末でこの機能を利用できるようにチップセット パートナーとともに取り組んでいます。

SMS プロバイダ

SMS または MMS を使用するメッセージング アプリを開発する場合、共有の SMS プロバイダと新しい API を使用して、アプリにおけるメッセージの保管と取得を管理できます。新しい SMS プロバイダと API は、SMS または MMS メッセージを処理するすべてのアプリ向けに標準化されたインタラクション モデルを定義します。

新しいプロバイダと API に加えて、 Android 4.4 では、メッセージを受信し、プロバイダに書き込むための新しいセマンティックを導入しました。メッセージを受信すると、システムは新しい SMS_DELIVER インテントを使用して、ユーザーの既定のメッセージ アプリに直接ルーティングします。既定ではないアプリも、 SMS_RECEIVED インテントを使用して、受信メッセージをリッスンできます。また、システムは、メッセージ データをプロバイダに書き込むことを既定のアプリのみに許可していますが、それ以外のアプリでも読み取りはいつでも可能です。ユーザーの既定ではないアプリは、引き続きメッセージを送信できます。その場合はシステムがアプリに代わってプロバイダへのメッセージの書き込みを処理するため、ユーザーは既定のアプリでメッセージを表示できます。

新しいプロバイダとセマンティックによって、複数のメッセージ アプリがインストールされている場合のユーザー エクスペリエンスが向上します。また、完全にサポートされた上位互換性のある API を使用して、新しいメッセージ機能を構築するためにも役立ちます。

美しいアプリを作成する新しい方法

フルスクリーン没入モード

アプリは端末の画面上のすべてのピクセルを使用してコンテンツを表示し、タップイベントを取得できるようになりました。 Android 4.4 では新たにフスクリーン没入モードが追加され、スマートフォンやタブレットの端から端まで余白のない UI を作成できるようになりました。このモードではステータスバーやナビゲーション バーなど、すべてのシステム UI が非表示になります。このモードは、写真、動画、地図、書籍、ゲームなど、視覚的に魅力的なコンテンツに最適です。

この新しいモードでは、ユーザーがアプリやゲームを操作してもシステム UI が非表示のままになります。画面のどの場所でも、つまり本来はシステムバーで占められている領域でも、タップイベントを取得できます。これは、アプリやゲームでより大きく、魅力的で、没入できる UI を作成でき、視覚的に注意をそらすものを削減できるすばらしい仕組みです。

常に一貫した方法で容易にフルスクリーン没入モードからシステム UI に戻れるように、 Android 4.4 は新しい操作をサポートしています。没入モードでは、上部または下部からのエッジのスワイプによって、システム UI が表示されるようになりました。

没入モードに戻るには、バーの範囲外の画面をタップするか、バーが自動的に非表示になるまでしばらく待ちます。一貫した操作を実現するため、この新しい操作はステータスバーを非表示にする以前のメソッドでも動作します。

シーンをアニメーション化する遷移フレームワーク

アプリのフローはほとんどの場合、さまざまなアクションを提供する複数の UI の状態を考慮した構成になっています。多くのアプリはアニメーションを使用して、進行状況から状態、そのとき利用できるアクションなどをユーザーが理解できるようにしています。アプリで高品質のアニメーションを容易に作成できるように、 Android 4.4 では新しい遷移フレームワークが導入されています。

この遷移フレームワークでは、シーン、通常はビューの階層、遷移を定義でき、ユーザーがシーンを開始または終了したときにシーンをアニメーション化または変換する方法を記述します。複数の定義済み遷移タイプを使用して、レイアウト境界、可視性などのプロパティに基づいてシーンをアニメーション化できます。また、シーンの変更中に自動的にビューのフェード、移動、サイズ変更を行う自動遷移タイプもあります。アプリとの関連性が高いプロパティをアニメーション化するカスタム遷移も定義できます。必要に応じて、独自のアニメーション スタイルで拡張することもできます。

さらに、遷移フレームワークを使えば、シーンを定義しなくても UI の変更をすぐにアニメーション化できます。たとえば、ビュー階層に対する一連の変更を作成して、TransitionManager で自動的にこれらの変更の遅延遷移を実行できます。

遷移を設定すると、アプリから起動するのは簡単です。たとえば、遷移を開始する 1 つのメソッドを呼び出すと、ビュー階層でさまざまな変更が行われ、次のフレームのアニメーションが自動的に開始されます。このように指定した変更がアニメーション化されます。

アプリのフローにおいて特定のシーン間で実行する遷移を個別に制御するには、TransitionManager を使用します。TransitionManager を使用すると、シーン間の関係と、特定のシーンの変更時に実行する遷移を定義できます。

半透明のシステム UI のスタイル設定

コンテンツの魅力を最大限に高めるため、新しいウィンドウ スタイルとテーマを使用して、ステータスバーとナビゲーション バーの両方について半透明のシステム UI をリクエストできます。ナビゲーション バーのボタンやステータスバーの視認性を高めるため、システムバーの背後に薄いグラデーションが表示されます。一般的なユースケースとして、壁紙が透けて見える必要があるアプリが考えられます。

通知アクセスの機能強化

通知リスナー サービスで、 Notification Builder API を使用して作成した受信通知について、より多くの情報を表示できるようになりました。リスナー サービスは通知のアクションのほか、テキスト、アイコン、写真、クロノメーターなど、新しい多くの追加フィールドにアクセスして、通知に関するよりクリーンな情報を抽出し、さまざまな方法で情報を提示できます。

Chromium WebView

Android 4.4 には、Chromium をベースにした、まったく新しい WebView が実装されました。この新しい Chromium WebView は、ウェブベースのコンテンツを構築および表示するための最新の標準サポート、パフォーマンス、互換性を提供します。

Chromium WebView は、HTML5、CSS3、JavaScript を幅広くサポートしており、Chrome for Android 30 で利用できるほとんどの HTML5 機能に対応しています。また、JavaScript のパフォーマンスを大幅に向上する最新版の JavaScript Engine（V8）も含まれています。

さらに、新しい Chromium WebView は Chrome DevTools によるリモート デバッグをサポートしています。たとえば、開発マシンで Chrome DevTools を使用して、モバイル端末上で動作する WebView コンテンツを検査、デバッグ、分析できます。

新しい Chromium WebView には、 Android 4.4 以上を実行する互換性のある端末がすべて含まれています。新しい WebView は、既存のアプリやコンテンツに最小限の変更を加えるだけですぐに活用できます。ほとんどの場合、コンテンツは新しい実装にシームレスに移行できます。

新しいメディア機能

画面の録画

アプリの高画質の動画を Android 端末から直接、簡単に作成できるようになりました。 Android 4.4 では画面の録画機能のサポートが追加され、USB で Android SDK 環境に接続された端末の録画を開始および停止できる Screen Recording Utility が提供されています。この新しい機能は、アプリのガイドやチュートリアル、テスト用マテリアル、マーケティング動画などを作成するのに最適です。

Screen Recording Utility では、端末画面のコンテンツを録画して、MP4 ファイルとして動画を端末に保存できます。端末がサポートしているどの解像度とビットレートでも録画でき、出力結果はディスプレイと同じアスペクト比を維持します。デフォルトでは、ユーティリティは現在の向きで、端末のディスプレイの解像度と同じまたはそれに近い解像度を選びます。録画を完了すると、動画を端末から直接共有したり、MP4 ファイルをホスト コンピューターに転送して編集したりできます。

アプリで、画面の録画機能で録画されたくない動画やその他の保護対象コンテンツを再生している場合、 SurfaceView.setSecure() を使用してマークを付けて、コンテンツを保護することができます。

画面の録画機能にアクセスするには、Android SDK に含まれている adb ツールで、コマンド adb shell screenrecord を使用します。Android Studio で DDMS パネルからこのツールを起動することもできます。

Adaptive Playback による解像度の切り替え

Android 4.4 では、Adaptive Playback のサポートが Android メディア フレームワークにも導入されました。Adaptive Playback は MPEG-DASH やその他の形式に対応した動画デコーダのオプションの機能で、再生中に解像度をシームレスに変更できます。クライアントはデコーダへの新しい解像度の入力動画フレームのフィードを開始して、自動的に出力バッファの解像度をスムーズに変更します。

Android 4.4 の解像度の切り替え機能によって、アプリは動画のストリーミング体験を大幅に改善できます。既存の API を使用すると、アプリは Adaptive Playback のサポートを実行時に確認でき、 Android 4.4 で導入された新しい API を使用すると、解像度の切り替え機能を実装できます。

DASH 向けの Common Encryption

Android は、MPEG-DASH 向けの Common Encryption（CENC）をサポートするようになりました。MPEG-DASH は、コンテンツの保護を管理するための標準のマルチプラットフォーム DRM スキームを提供します。アプリは Android のモジュラー DRM フレームワークと、DASH をサポートするためのプラットフォーム API を通じて CENC を利用できます。

HTTP Live Streaming

Android 4.4 はプラットフォームの HTTP Live Streaming（HLS）サポートを更新し、HLS 仕様（プロトコルのバージョン 4）のバージョン 7 のスーパーセットに対応しました。詳細については、IETF のドラフトをご覧ください。

DSP へのオーディオ トンネリング

高パフォーマンスで省電力のオーディオ再生を実現するため、 Android 4.4 では、デバイス チップセットに搭載された Digital Signal Processor（DSP）へのオーディオ トンネリングのプラットフォーム サポートが追加されました。トンネリングによって、オーディオのデコードと出力エフェクトが DSP にまかされるため、アプリケーション プロセッサの起動回数が減り、電池の消費が抑えられます。

オーディオ トンネリングは、画面をオフにしてヘッドセットで音楽を聴くなどのユースケースで、電池の寿命を大幅に改善できます。たとえば、オーディオ トンネリングを使うと、Nexus 5 はオフラインでのオーディオ再生時間が最長 60 時間となり、オーディオ トンネリングなしの場合よりも 50% 増加します。

メディアアプリは、サポート対象端末でオーディオ トンネリングを活用でき、コードの変更は不要です。システムはトンネリングを適用して、端末で利用できるときは常にオーディオ再生を最適化します。

オーディオ トンネリングは、端末のハードウェアが対応している必要があります。現在、オーディオ トンネリングは Nexus 5 で利用できます。Google では、できるだけ早く、より多くの端末でこの機能を利用できるようにチップセット パートナーとともに取り組んでいます。

オーディオ監視

アプリは、Visualizer エフェクトの新しい監視ツールを使用して、端末で現在再生しているオーディオのピークと RMS のレベルについて最新情報を得ることができます。たとえば、この機能をミュージック ビジュアライザーでクリエイティブに活用したり、メディア プレイヤーで再生の調節機能を実装したりできます。

ラウドネス エンハンサー

メディア再生アプリは新しい LoudnessEnhancer エフェクトを使用して、音声コンテンツの音量を上げることができます。このエフェクトは、音声に特化してチューニングされた時定数を使用し、コンプレッサとして機能します。

AV 同期を改善するためのオーディオ タイムスタンプ

オーディオ フレームワークは、音声と動画の同期を改善するため、オーディオ出力の HAL からアプリにプレゼンテーション タイムスタンプを報告できるようになりました。オーディオ タイムスタンプを使用すると、特定のオーディオ フレームを別の端末でユーザーに提供する（または提供していた）タイミングをアプリが判断できます。タイムスタンプ情報を使用して、オーディオと動画フレームをより正確に同期させることができます。

Wi-Fi CERTIFIED Miracast™

Android 4.4 端末は、Miracast 互換として Wi-Fi Alliance Wi-Fi Display Specification 認定を受けられるようになりました。テストをサポートするため、ワイヤレスディスプレイ認定用に、新しいワイヤレスディスプレイ デベロッパー オプションで高度な構成制御と設定を公開しています。[Settings] > [Developer options] > [Wireless display certification] のオプションにアクセスできます。Nexus 5 は、Miracast 認定ワイヤレスディスプレイ端末です。

RenderScript の計算

実行中のパフォーマンスの改善

アプリで RenderScript を使うと、RenderScript の実行時に、実行中のパフォーマンス チューニングのメリットを享受できます。再コンパイルは不要です。右のグラフは、2 つの主要なチップセットで Android 4.4 によるパフォーマンスの向上を示しています。

GPU アクセラレーション

サポート対象端末で RenderScript を使用しているアプリは、コード変更や再コンパイルを行わなくても、GPU アクセラレーションのメリットを享受できます。Nexus 10 での初登場以来、RenderScript GPU アクセラレーションは、ハードウェア パートナー各社がサポートを追加しています。

現在 Android 4.4 で GPU アクセラレーションが利用できるのは、Nexus 5、Nexus 4、Nexus 7（2013）、Nexus 10 です。Google では、できるだけ早く、より多くの端末でこの機能を利用できるようにパートナーとともに取り組んでいます。

Android NDK の RenderScript

RenderScript をネイティブ コードから直接活用できるようになりました。Android Native Development Kit（NDK）の新しい C++ API を使用すると、フレームワーク API によって同じ RenderScript 機能（Script Intrinsic、カスタム カーネルなど）を利用できます。

パフォーマンスに負荷のかかる大きなタスクをネイティブ コードで処理する場合、RenderScript を使用してそのようなタスクを実行し、ネイティブ コードと統合できます。RenderScript は、マルチコア CPU、GPU、その他のプロセッサを自動的にサポートして、幅広い端末で大幅にパフォーマンスを向上します。

NDK を使用して RenderScript を使用するアプリを構築すると、フレームワーク API で利用できるサポート ライブラリと同様に、Android 2.2 以上を搭載するすべての端末に配布できます。

グラフィック

GLES2.0 SurfaceFlinger

Android 4.4 では、SurfaceFlinger を OpenGL ES 1.0 から OpenGL ES 2.0 にアップグレードしました。

仮想ディスプレイに対応した新しい Hardware Composer のサポート

最新バージョンの Android Hardware Composer である HWComposer 1.3 では、プライマリの外部ディスプレイ（HDMI など）に加えて仮想ディスプレイのハードウェア コンポジションをサポートし、OpenGL ES の相互運用性が改善されました。

新しい接続タイプ

新しい Bluetooth プロファイル

Android 4.4 は、新たに 2 つの Bluetooth プロファイルをサポートし、アプリが低電力やメディア操作を幅広くサポートできるようになりました。Bluetooth HID over GATT（HOGP）: アプリがマウス、ジョイスティック、キーボードなど低電力の周辺機器と低レイテンシのリンクを使用できます。Bluetooth MAP: アプリが付近の端末（ハンズフリーの自動車用ターミナルや別のモバイル端末など）とメッセージを交換できます。Bluetooth AVRCP 1.3 の拡張機能として、Bluetooth 端末からシステムの絶対ボリュームを設定できるようになりました。

HOGP、MAP、AVRCP のプラットフォーム サポートは、Android 4.2 で Google と Broadcom によって導入された Bluedroid Bluetooth スタックを元に構築されています。サポートは、Nexus 端末のほか、Bluetooth 機能と互換性のあるすべての Android 互換端末ですぐに利用できます。

IR ブラスター

Android 4.4 では、組み込みの IR ブラスターのプラットフォーム サポートと、これを活用するアプリを作成するための API とシステム サービスを導入しました。

新しい API によって、付近の TV、チューナー、スイッチ、その他の電子機器をリモート制御可能なアプリを作成できます。アプリでこの API を使うと、スマートフォンまたはタブレットの赤外線通信機能の有無のチェック、携帯通信会社の周波数の照会、赤外線信号の送信ができます。

この API は、 Android 4.4 以上を搭載している Android 端末の標準であるため、アプリでカスタムの統合コードを記述しなくても、可能な限り幅広いベンダーをサポートできます。

Wi-Fi TDLS のサポート

Android 4.4 では、Wi-Fi Tunneled Direct Link Setup（TDLS）のサポートによって、既に同じ Wi-Fi ネットワーク上に存在する端末間で、メディアやその他のデータを高速にストリーミングできるシームレスな方法が導入されました。

ユーザー補助機能

システム全体のクローズド キャプションの設定

Android 4.4 ではシステム全体のクローズド キャプションの設定を追加し、どのアプリでも改善されたユーザー補助機能を利用できるようになりました。[Settings] > [Accessibility] > [Captions] にアクセスして、字幕の表示 / 非表示、使用する言語、テキストサイズ、テキストのスタイルなど、字幕のグローバル プリファレンスを設定できます。

動画を使用するアプリは、ユーザーの字幕設定にアクセスして、ユーザーのプリファレンスに合わせて表示を調整できます。新しい Captioning Manager API を使用すると、ユーザーの字幕のプリファレンスを確認および監視できます。Captioning Manager では、ユーザーの好みの字幕の状態のほか、ロケール、スケーリング係数、テキスト スタイルを取得できます。テキスト スタイルには、前景色と背景色、エッジのプロパティ、書体などが含まれます。

また、VideoView を使用するアプリは新しい API を使用して、レンダリングする動画ストリームと共に字幕ストリームを渡すことができます。システムは自動的に、ユーザーのシステム全体の設定に合わせて、動画フレーム上の字幕の表示を処理します。現在、VideoView は WebVTT 形式のみで字幕の自動表示をサポートしています。

字幕を表示するすべてのアプリは必ず、ユーザーのシステム全体の字幕プリファレンスを確認し、できるだけプリファレンスに合わせて字幕をレンダリングする必要があります。特定の設定の組み合わせでどう表示されるかについては、さまざまな言語、サイズ、スタイルでの字幕のプレビューを設定アプリで確認できます。

Accessibility API の機能強化

Android 4.4 では Accessibility API を拡張し、より正確な構成のセマンティックな説明と画面上の要素の監視をサポートしています。新しい API を使用して、ユーザー補助機能サービスを提供して画面上の要素に関する情報を増やすことで、デベロッパーは利用しやすさに関するフィードバックの質を改善できます。

accessibility ノードで、デベロッパーはノードがポップアップかどうかを判断したり、入力タイプを取得したりできるようになりました。新しい API を使用して、リストや表など、グリッド状の情報を含むノードを処理することもできます。たとえば、新しいサポート対象のアクション、コレクション情報、Live Region モードなどを指定できるようになりました。

新しい accessibility イベントを使用して、デベロッパーはウィンドウのコンテンツで実行された変更をより細かくフォローできるようになりました。また、端末のタッチガイド モードで変更をリッスンできるようになりました。

全世界のユーザーのサポート

RTL レイアウト向けのドローアブル ミラーリング

アプリが RTL スクリプトを使用するユーザーを対象にしている場合、新しい API を使用して、ユーザーの言語 / 地域設定に RTL 言語が含まれているときはドローアブルを自動的にミラーリングする必要があることを宣言できます。

ドローアブルの自動ミラーリングを宣言すると、アプリのアセットの重複を防ぐことができ、APK のサイズを削減できます。LTR と RTL のプレゼンテーションで再利用可能なドローアブルが存在する場合、既定のバージョンを自動ミラーリングとして宣言し、RTL リソースからそのドローアブルを省くことができます。

アプリのコードで、ビットマップ、9-patch、レイヤー、状態リストなどの各種ドローアブルを自動ミラーリングとして宣言できます。新しい属性を使用して、リソース ファイルでドローアブルを自動ミラーリングとして宣言することもできます。

RTL レイアウト方向を使用

RTL 言語に切り替えなくてもレイアウトのミラーリングの問題を簡単にテストおよびデバッグするために、Android には新しいデベロッパー オプションとして、すべてのアプリで RTL レイアウト方向を使用するオプションが用意されています。

[Force RTL layout] オプションは、端末のすべての言語 / 地域を RTL レイアウトに切り替えて、現在の言語でテキストを表示します。これにより、アプリ全体のレイアウトの問題を見つけやすくなり、アプリを RTL 言語で表示する必要がなくなります。[Settings] > [Developer options] > [Force RTL layout direction] で、このオプションにアクセスできます。

セキュリティの機能強化

SELinux（enforcing モード）

Android 4.4 では、SELinux の構成を [permissive] から [enforcing] に更新しました。これにより、ポリシーが適用されている SELinux ドメイン内の潜在的なポリシー違反は、ブロックされます。

暗号化アルゴリズムの改善

Android はさらに 2 つの暗号化アルゴリズムに対応し、セキュリティを強化しました。Elliptic Curve Digital Signature Algorithm（ECDSA）がキーストア プロバイダに追加され、デジタル署名のセキュリティが向上し、アプリの署名やデータ接続が必要な状況に適用できるようになりました。フルディスク暗号化に使用される暗号化の鍵を保護するため、Scrypt 鍵導出関数が実装されました。

その他の機能強化

マルチユーザー端末で、VPN がユーザーごとに適用されるようになりました。これにより、端末上の他のユーザーに影響を与えることなく、VPN を介してすべてのネットワーク トラフィックをルーティングできるようになりました。さらに、Android は FORTIFY_SOURCE レベル 2 に対応し、すべてのコードがこれらの保護を適用してコンパイルされます。FORTIFY_SOURCE は機能が強化され、clang で動作するようになりました。

メモリ使用量の分析ツール

Procstats

新しい procstats というツールでは、アプリが使用するメモリリソースのほか、システムで実行中の他のアプリやサービスによって使用されるリソースを分析できます。

Procstats は、時間経過に伴うアプリの状況を追跡し、実行期間とメモリ消費量に関するデータを提供し、実行しているアプリの効率性を判断するのに役立ちます。アプリの実行時間と実行中のメモリ消費量を監視できるため、バックグラウンドで実行するサービスを開始するアプリには、この機能は最も重要です。Procstats は、フォアグラウンド アプリの時間経過に伴うメモリ消費量データも収集するため、アプリの全体的なメモリのプロファイルを判断できます。

Procstats は、アプリで開始されたバックグラウンド サービスを特定する場合に役立ちます。これらのサービスの実行継続時間と実行中のメモリ消費量を追跡できます。Procstats は、フォアグラウンドにあるアプリもプロファイリングできます。時間経過に伴うメモリ消費量から、アプリの全体的なメモリのプロファイルを判断できます。

procstats にアクセスでするには、Android SDK に含まれる adb ツールで、コマンド adb shell dumpsys procstatsで導入された新しい API を使用すると、解像度の切り替え機能を実装できます。また、オンデバイス プロファイリングについては、以下の [Process Stats] デベロッパー オプションをご覧ください。

オンデバイス メモリのステータスとプロファイリング

Android 4.4 には新しいデベロッパー オプションが含まれており、端末またはエミュレータで実行中のアプリのメモリ プロファイルを容易に分析できます。特に、メモリが少ない端末で、アプリのメモリ消費量と実行状況について把握できるため便利です。[Settings] > [Developer options] > [Process stats] でオプションにアクセスできます。

[Process Stats] オプションには、新しい procstats サービスを使用して収集されたデータに基づき、アプリのメモリ消費量について各種のメトリクスの概要が表示されます。メイン画面では、システムメモリのステータスの概要が表示されます。RAM の消費量について緑は低い、黄色は中程度、赤（クリティカル）は高いことを示します。

概要の下には、各アプリのシステム上のメモリの負荷をまとめたリストが表示されています。アプリごとに、青のバーは相対的に計算されたそのプロセスのメモリの負荷（runtime x avg_pss）を示し、割合の数値はバックグラウンドで費やされている相対時間を示します。リストをフィルタリングしてフォアグラウンド、バックグラウンド、キャッシュ プロセスのみを表示したり、システム プロセスを含めたり除外したりできます。また、データの収集期間を 3、6、12、24 時間に変更したり、専有（USS）メモリを含めたり除外したりできます。

特定のアプリのメモリ消費量を個別に詳しく調べるには、アプリをタップします。アプリごとに、メモリ消費量と収集期間における実行時間の割合の概要が表示されます。さらに、収集期間における平均消費量と最大消費量があり、その下にはアプリのサービスと実行時間の割合も表示されます。

Process Stats のデータを使用してアプリを分析すると、問題が明らかになり、アプリで可能な最適化が示唆されます。たとえば、アプリの実行時間が想定よりも長すぎたり、アプリの一時期のメモリ消費量があまりにも多い場合、コード内にバグがあり、それを解決すればアプリのパフォーマンスが改善される可能性があります。これは特に、メモリの少ない端末で実行しているときにあてはまります。