[この記事は Dave Burke、エンジニアリング担当 VP による Android Developers Blog の記事 "Welcoming Android 7.1.1 Nougat" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

先週、Nougat のアップデートを公開しました。Pixel および Pixel XL 端末と、サポート対象となるすべての Nexus 端末向けの Android 7.1.1 です。また、端末メーカーが最新版の Android を入手できるように、Android 7.1.1 のソースコードが Android Open Source Project（AOSP）に登録されます。

Android 7.1.1 がユーザーに向けて公式にリリースされるこのタイミングで、ぜひアプリの対応を行ってください。

Android 7.1.1 の機能

Android 7.1.1 は、Pixel および Pixel XL 端末ですでに利用できるようになっている機能を土台として、ユーザー向けのさまざまな新機能の追加や、基盤となる Android 7.1 プラットフォーム（API レベル 25）に対する最適化やバグの修正が行われている増分リリースです。

デベロッパー機能の詳細については、アプリ ショートカット、円形アイコン リソース、イメージ キーボードのサポートなどをご覧ください。デベロッパー機能の完全なリストは、こちらで確認できます。API レベル 25 の詳細については、API の差分と API リファレンスをご覧ください。

Android 7.0 Nougat の主な動作変更の詳細やデベロッパー機能など、すべての Nougat デベロッパー リソースの概要はこちらから参照できます。

ユーザー端末にも順次展開

Android 7.1.1 は本日より公開され、今後数週間ですべての対象端末で利用できるようになる予定です。Pixel および Pixel XL 端末に加え、Nexus 5X、Nexus 6P、Nexus 6、Nexus 9、Nexus Player、Pixel C、General Mobile 4G（Android One）の各端末に、Over-the-air（OTA）アップデートが配信されます。Android ベータ版プログラムに登録している端末にも、この最終版が配信されます。通常どおり、このアップデートを手動でダウンロードして端末に書き込むこともできます。

また、数か月後にパートナーの端末メーカーが自社の端末を Android 7.1.1 にアップデートできるよう、その準備も進めています。

アプリを確実に対応させる

この機会にアプリの互換性をテストし、円形アイコンやアプリ ショートカットなどを追加して Android 7.1.1 でのアプリの外観を最適化してください。アプリは API 25 でコンパイルすることをお勧めします。できれば、ターゲットも API 25 に設定します。詳細については、最近の投稿をご覧ください。

最終版プラットフォームでは、Android Studio のプラットフォーム ツールやビルドツール、API レベル 25 エミュレータ システム イメージもアップデートされています。最新版のサポート ライブラリ（25.0.1）もリリースされ、API レベル 25 以前を実行している端末に、イメージ キーボードのサポート、ボトム ナビゲーションなどの機能を追加できます。

Pixel および Nexus 端末の最終テストをサポートするため、Nexus Images ページでダウンロード可能なファクトリー イメージや OTA イメージも提供しています。テスト対象端末を拡大するため、ぜひ Firebase Test Lab for Android を活用し、クラウドでテストを実行してください。12 月末までテストが無料になります。

最終テストの終了後には、Google Play Developer Console でアプリをアルファ版、ベータ版、さらに製品版のチャンネルに公開できます。

次のステップ

Developer Preview ビルドに対して報告されたバグのうち、未対応のものについてはまもなく対応が完了する予定ですが、フィードバックは今後も大歓迎です。Preview Tracker に記録した問題がまだ解消されていないという方は、AOSP Issue Tracker で Android 7.1 に対して新しく問題を送信してください。デベロッパー コミュニティでも、引き続きフィードバックや質問をお寄せいただけます。

8 月にお知らせしたように Android Nougat は定期メンテナンス サイクルに移っており、次の増分アップデートに向けた微調整やバグの修正作業もすでに始まっています。現在、対象端末をお持ちで Android ベータ版プログラムに登録している場合、その端末は次の Android Nougat リリースのプレビュー アップデートが利用可能になり次第、自動的に受信します。アップデートを自動で受信したくない場合は、ベータ版サイトで端末を登録解除してください。

デベロッパー プレビューに参加いただき、どうもありがとうございます。アンケートに回答し、今年のプレビューが皆さんのニーズをどの程度満たしていたかをお知らせください。いただいたフィードバックは、将来のリリース計画に反映いたします。



Posted by Yuichi Araki - Developer Relations Team

[この記事は Dave Burke、エンジニアリング担当 VP による Android Developers Blog の記事 "Final update to Android 7.1 Developer Preview" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]



本日（*原文公開当時）、Android 7.1 Developer Preview のアップデートが公開されました。最終的な Android 7.1.1 プラットフォームをエコシステムにリリースする前の最後のアップデートです。Android 7.1.1 には、Pixel および Pixel XL 端末ですでに利用できるようになっているデベロッパー機能に加え、基盤となる Android 7.1 プラットフォームに対する最適化やバグの修正も含まれています。Developer Preview 2 では、アプリが Android 7.1.1 や想定されるユーザーの端末に対応できているかを確認できます。

10 月にお知らせしたように、今回の Developer Preview アップデートの対象は、Nexus 5X、Nexus 6P、Nexus 9、Pixel C といった多くの端末に拡大されています。

Android ベータ版プログラムに登録しているサポート対象端末には、来週中に Developer Preview 2 へのアップデートが配布されます。まだ端末を登録していない場合は、サイトにアクセスして端末を登録し、アップデートを受信してください。

12 月初旬には、Pixel および Pixel XL 端末のほか、すべてのサポート対象端末に Android 7.1.1 がリリースされます。

今回のアップデートの内容

Developer Preview 2 は、Android 7.1.1 のリリース候補版で、今後予定されている最終リリースに向けた準備としてアプリの開発やテストに利用できます。システムの動作や UI はほぼ最終版となっており、システムや Google アプリ全般にわたって最新のバグの修正や最適化が行われています。

また、すでに Developer Preview 1 で導入されているデベロッパー機能や API（API レベル 25）も含まれています。デベロッパー機能の詳細については、アプリ ショートカット、円形アイコン リソース、イメージ キーボードのサポートなどをご覧ください。デベロッパー機能の完全なリストは、こちらで確認できます。

Developer Preview 2 では、Android Studio の SDK ビルドツールやプラットフォーム ツール、Android 7.1.1 プラットフォーム、API レベル 25 エミュレータ システム イメージもアップデートされています。最新版のサポート ライブラリ（25.0.1）もリリースされ、API レベル 25 以前の端末に、イメージ キーボードのサポート、ボトム ナビゲーションなどの機能を追加できます。

API レベル 25 の詳細については、デベロッパー プレビュー サイトの API の差分と最新の API リファレンスをご覧ください。

Android 7.1 リリースに向けたアプリの準備

このタイミングでアプリを最適化し、Android 7.1.1 で美しい外観を実現しましょう。それにはまず、Android Studio 2.2.2 にアップデートし、Android Studio の SDK Manager から API レベル 25 プラットフォームとエミュレータのシステム イメージやツールをダウンロードします。

API レベル 25 SDK をインストールすると、プロジェクトの compileSdkVersion を 25 にアップデートして新しい API を対象にビルドやテストができるようになります。互換性テストを行う場合は、アプリの targetSdkVersion を API 25 に更新し、互換動作を無効にしてアプリをテストすることをおすすめします。API レベル 25 SDK を使ってアプリをセットアップする方法の詳細については、プレビューのセットアップに関する記事をご覧ください。

アプリのショートカットやサークル ランチャー アイコンをご自分のアプリに追加する場合は、Android Studio のビルトイン Image Asset Studio を使うと、マテリアル デザイン ガイドラインを満たす異なるサイズのアイコンを短時間で作成できます。円形アイコンや新しい Google Pixel ランチャーをサポートする API レベル 25 対応の Google API エミュレータでは、円形アイコンをテストできます。



Android Studio と Google API エミュレータを使えば、短時間で円形アイコン アセットを作成してテストできる

イメージ キーボードのサポートを追加する場合は、Messenger と Google キーボード アプリを使ってテストします。これらのアプリは、プレビュー システム イメージに含まれており、新しい API をサポートしています。

Firebase Test Lab for Android でテスト対象端末を拡大

テスト対象端末を拡大するため、ぜひ Firebase Test Lab for Android を活用し、クラウドでテストを実行してください。プレビュー期間中は、Developer Preview 2（API 25）を含むすべての仮想端末を使ったテストが無料になります。自動クローラ（Robo テスト）を使って一切テスト スクリプトを書かずにアプリをテストすることも、独自のインストルメンテーション テスト（Espresso など）をアップロードすることもできます。テストのアップロードは、こちらから行います。

Google Play のアルファ版、ベータ版、または製品版チャンネルにアプリを公開する

最終テストが終わったら、API 25 でコンパイルしたアップデートを Google Play に公開できます（オプションで、API 25 をターゲットにすることもできます）。Google Play Developer Console では、アルファ版、ベータ版、さらに製品版のチャンネルに公開できます。これによって、Pixel や Android ベータ版端末などの Android 7.1 が実行されているユーザーの端末にアプリのアップデートをプッシュできます。

対象端末での Developer Preview 2 の入手方法

すでに Android ベータ版プログラムに登録しているサポート対象端末には、来週中に Developer Preview 2 へのアップデートが配布されます。特に操作は必要ありません。まだプログラムに登録していない方は、次の方法で簡単に利用を開始できます。android.com/beta にアクセスして、対象の Android スマートフォンまたはタブレットをオプトインするだけで、すぐに今回のプレビュー アップデートを OTA で受信できます。通常どおり、このアップデートを手動でダウンロードして端末に書き込むこともできます。

前述のように、Developer Preview アップデートは、Nexus 5X、Nexus 6P、Nexus 9、Pixel C 端末に対応しています。

Android 7.1.1 の最終リリースは、数週間以内に公開される予定です。12 月初旬には、最近発売された Pixel および Pixel XL 端末をはじめ、プレビュー版をサポートするすべての端末に Android 7.1.1 がリリースされます。同時に、ソースを AOSP にプッシュして、パートナーの端末メーカーがこの新しいプラットフォーム アップデートをユーザーの端末に配信できるようにします。

それまでの間、12 月に予定している最終の正式リリースに向けて努力してまいりますので、今後も Developer Preview Issue Tracker、N Preview デベロッパー コミュニティ、または Android ベータ版コミュニティを通じてフィードバックをお寄せください。


Posted by Takeshi Hagikura - Developer Relations Team

[この記事は Dave Burke、エンジニアリング部門副社長による Android Developers Blog の記事 "Now available: Android 7.1 Developer Preview" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]


先日、Android 7.1 Nougat の Developer Preview がまもなく登場することをお知らせしました。SDK とツールをダウンロードすることにより、本日（*原文公開当時）よりこの新しいリリースが使えるようになっています。対応端末で 7.1 リリースを使うには、お使いの端末を Android ベータ版プログラムに登録してください。既に端末が登録されている場合は、自動的にアップデートを受信します。

Developer Preview の内容

Android 7.1 Developer Preview には、新しいプラットフォームでアプリのテストを実施し、ショートカットやイメージ キーボードのサポートなどの新機能を用いてアプリを拡張するために必要なものがすべて備わっています。具体的には、アップデートされた SDK、ビルドツール、ドキュメント、サンプル、さらにエミュレータや端末のシステム イメージなど、サポート対象の端末でアプリを実行するために必要なものが含まれています。

N やそれ以前のリリースで使用しているモデルは継続しますが、追加リリースである Android 7.1 には、特筆すべきいくつかの相違点があります。

• 7.1 は既に Pixel に搭載されているため、Nexus ラインナップの端末向けの最初の Developer Preview はベータ版品質でお送りします。この目的は、端末固有の問題に対応することです。
• 新しい API は、API レベル 25 として確定しています。
• また、新しい API レベルを対象としたアプリの Google Play での公開を開始していますので、準備ができ次第、アプリをアップデートできます。

初期プレビュー リリースの次には、11 月にアップデートを提供する予定です。12 月には、Android Open Source Project（AOSP）への最終パブリック リリースを行います。まずは Nexus 5X、Nexus 6P、Pixel C 端末が対象になりますが、11 月には Developer Preview の対象端末が増える予定です。

Android 7.1 リリースに向けたアプリの準備

対応を始めるには、Android Studio 2.2.2 にアップデートし、API レベル 25 プラットフォームとエミュレータのシステム イメージやツールをダウンロードします。API レベル 25 に対応した最終版の SDK は、Android Studio の SDK Manager を使ってダウンロードできます。

API レベル 25 SDK をインストールすると、プロジェクトの compileSdkVersion を 25 に更新して新しい API のビルドやテストができるようになります。互換性テストを行う場合は、アプリの targetSdkVersion を API 25 に更新し、互換動作を無効にしてアプリをテストすることをおすすめします。API レベル 25 SDK を使ってアプリをセットアップする方法の詳細については、プレビューのセットアップに関する記事をご覧ください。

アプリのショートカットやサークル ランチャー アイコンをご自分のアプリに追加する場合は、Android Studio のビルトイン Image Asset Studio を使うと、マテリアル デザイン ガイドラインを満たす異なるサイズのアイコンを短時間で作成できます。

Android API レベル 25 SDK 対応の Google API のエミュレータ システム イメージには、円形アイコンや新しい Google Pixel ランチャーのサポートが含まれています。Google API システム イメージを使うと、円形アイコンをサポートしている端末でアプリの円形アイコンがどのように見えるかをテストできます。さらに、ライブ壁紙を開発している場合、新しいシステム イメージと Android Emulator を使うと、Android 7.1 で拡張されたプレビュー メタデータをテストできます。

イメージ キーボードのサポートを追加するには、Messenger と Google キーボード アプリを使ってテストします。これらのアプリは、プレビュー システム イメージに含まれており、新しい API をサポートしています。

API レベル 25 SDK とともに、Android Support Library も 25.0.0 にアップデートしました。新しいバージョンでは、API レベル 13 以降と互換性のあるイメージ キーボードのサポートを追加できます。また、マテリアル デザイン ガイドラインのボトム ナビゲーション パターンを実現する BottomNavigationView ウィジェットも追加されています。

API レベル 25 の詳細については、デベロッパー プレビュー サイトの API の差分と最新の API リファレンスをご覧ください。

[この記事は Dave Burke、エンジニアリング部門副社長による Android Developers Blog の記事 "Coming soon: Android 7.1 Developer Preview" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]


本記事では、最新版のプラットフォーム Android 7.1 Nougat の新情報をお伝えします。既に先日のイベントを見てご存知の方もいると思いますが、今回のリリースは Android 7.0 をベースとした追加アップデートで、ユーザーやデベロッパー向けに新機能が追加されています。たとえば、Daydream VR のサポート、A/B システムアップデート (Seamless Update)、アプリ ショートカット 、イメージ キーボードのサポートなどが含まれています。

これらの機能を Android 7.1 で提供するため、Google は端末メーカーと連携して準備を進めてきました。次の段階として、デベロッパーの皆さまが新バージョン向けに皆様のアプリを準備できるよう、このアップデートを公開いたします。

Android 7.0 と同様に、今月末には Android 7.1 を Developer Preview としてリリースします（現在既にリリースされています）。Developer Preview を利用すると、新しいプラットフォーム上でのアプリの作成、テストの実施、最新機能の試用が可能になります。

これまでと同じく、Android ベータ版プログラムを介して Developer Preview を提供しますので、手軽にご利用いただけます。

Android 7.1 の新機能

Android 7.1 では Android 7.0 の生産性、セキュリティ、パフォーマンスを維持しつつ、さまざまな最適化やバグ修正、新機能、新しい API（API レベル 25）が追加されています。

Android 7.1 には、デベロッパーがアプリ作成に専念し、より優れたユーザー エクスペリエンスを実現できるようにするため、次のような新機能が含まれています。

• アプリ ショートカット API - ランチャー上にキー操作に対応したショートカットを配置し、ユーザーが瞬時にアプリの深い階層まで移動できるようにします。最大 5 個までのショートカットを静的または動的に作成できます。
• 円形アイコンのサポート - Pixel や他のランチャーのデザインに合う円形の魅力的なアイコン リソースを利用できます。
• ライブ壁紙のメタデータに関する改善 - 自身のライブ壁紙のメタデータを提供することで、どのピッカーでも壁紙をプレビュー表示できるようになります。ラベル、説明、制作者、新しいコンテキスト URL、詳細情報へのリンクなど、既存のメタデータを表示できます。

Android 7.1 のプラットフォームには、デベロッパーからの要望が多かった次の機能も追加されています。

• イメージ キーボードのサポート - ユーザーがキーボードで入力できるコンテンツ種別を拡張することで、オリジナルのスタンプやアニメーション GIF などを利用したコミュニケーションを可能にしています。アプリが、対応するコンテンツ種別をキーボードに伝えると、キーボードはユーザー向けのすべて画像とその他のコンテンツを提供します。互換性向上のため、この API はサポート ライブラリでも提供されています。
• ストレージ マネージャー インテント - アプリから新しい設定画面を直接開いて、未使用のファイルを削除したり、端末上のストレージ領域を解放したりできるようになります。

携帯通信会社や電話アプリ向けに、マルチ エンドポイント通話と電話設定オプションもサポートされています。


（右）イメージ キーボードのサポート: ユーザーはキーボードから直接、画像やその他のコンテンツを入力できる。
（左）アプリ ショートカット: キー操作に対応したショートカットを配置すると、瞬時にアプリの深い階層まで移動できる。
アプリの準備

Android 7.1 は追加リリースですが、メジャー リリース同様に（特にユーザーの手に渡る端末上で）アプリが正しく表示され、機能することを確認する必要があります。

Android 7.1 Developer Preview には、アプリのテストを実施し、ショートカットやキーボード イメージなどの新機能を用いてアプリを拡張するために必要なものがすべて備わっています。具体的には、新しい API に対応した SDK、ビルドツール、ドキュメント、サンプル、さらにエミュレータや端末のシステム イメージなど、サポート対象の Nexus 端末でアプリを実行するために必要なものが含まれています。またアプリ ショートカット機能に対応したランチャーとアプリ、キーボード イメージ機能に対応したキーボードも提供されています。

Developer Preview を自動で受信したい場合は、Android ベータ版プログラムで端末を登録してください。以前に端末を登録済みで、登録解除を行っていない場合は、アップデートが端末に配信されます。登録済みで今回のアップデートは受信したくない場合は、Android ベータ版プログラムで、早めに端末の登録を解除してください。

まずは Nexus 5X、Nexus 6P、Pixel C 端末向けに Developer Preview を提供し、プレビュー終了時にサポート対象端末を増やす予定です。12 月初旬の Android 7.1.x の最終リリース時には、すべてのサポート対象端末（Nexus 6、Nexus 5X、Nexus 6P、Nexus 9、Nexus Player、Pixel C、対象の Android One 端末）にアップデートを展開します。

ユーザー端末にも順次展開

Google では Android 7.1 をエコシステム全体の端末に提供するため、パートナーと連携して何カ月も前倒しで準備を進めています。デベロッパーの皆さまには、できるだけ早めに Android 7.1 Developer Preview をダウンロードすることをお勧めします。円形のアプリアイコンやアイコン ショートカットを使用するなどして、アプリの互換性や最適化のテストを実施し、魅力的なアプリを作成してください。

Developer Preview の詳細については今後も情報を配信していきますので、期待してお待ちください。


Posted by Takeshi Hagikura - Developer Relations Team

[この記事は Xiaowen Xin、Android セキュリティ チームによる Android Developers Blog の記事 "Keeping Android safe: Security enhancements in Nougat" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

この夏を通して、Android 7.0 Nougat のさまざまなセキュリティ拡張のプレビューが行われてきました。具体的には、セキュリティを重視した脆弱性報奨金プログラム、新しいダイレクト ブート モード、メディアサーバーの再構築、メディア スタックの強化、意図しないクリアテキスト トラフィックに逆行するアプリの保護、Android が信頼される証明機関を取り扱う方法の更新、セキュアブートの厳格な適用とエラー訂正、攻撃対象領域を減らしてメモリ保護を強化するための Linux カーネルの更新などがあげられます。すばらしいですね！

Nougat の展開が始まった今、これらのアップデートの概要を振り返りつつ、いくつかの新しい改善点について重点的に紹介したいと思います。

ダイレクト ブートと暗号化

以前のバージョンの Android では、端末を暗号化しているユーザーは、デフォルトで PIN / パターン / パスワードのいずれかを使用する必要がありました。これは、ブートプロセスでストレージ領域を復号化してブートを完了するために必要な操作でした。Android 7.0 Nougat では、基礎となる暗号化スキームがアップデートされ、ブートプロセスが効率化されているため、スマートフォンを高速に再起動できるようになっています。スマートフォンの主な機能である電話アプリやアラーム クロックは、PIN を入力する前であっても即座に利用できるようになります。そのため、PIN を入力しなくても電話を受けたり目覚ましを鳴らしたりできます。この機能は、ダイレクト ブートと呼ばれています。

内部的には、このユーザー エクスペリエンスの改善はファイルベースの暗号化によって実現されています。この新しい暗号化スキームでは、システムのストレージ領域やユーザー プロファイルはすべて個別に暗号化されます。すべてのデータがひとまとめで暗号化されるディスク全体の暗号化とは異なり、プロファイルごとの暗号化では、端末キーを使うだけでシステムを再起動して機能する状態にすることができます。重要なアプリはオプトインして再起動後に限定的な状態で実行できます。ロック画面で資格情報を入力すると、アプリはユーザーデータにアクセスして完全に機能できるようになります。

ファイルベースの暗号化を使用すると、細かい粒度でデータを暗号化し、個々のユーザーや端末上のプロファイルを個別に保護できます。各プロファイルは一意のキーによって暗号化され、PIN またはパスワードでのみロック解除できます。そのため、データは本人しか復号化できません。
暗号化のサポートは、Android エコシステム全体でも強化されています。Marshmallow 以降、すべての対応端末は暗号化のサポートが必須になっています。Nexus 5X や 6P のような多くの端末でも、ARM TrustZone などの信頼できるハードウェアからのみアクセス可能な一意なキーが使われています。7.0 Nougat では、すべての新しい Android 対応端末でこういった種類のキー ストレージのハードウェア サポートが必須となっています。これによって、総当たり攻撃に対する保護を提供しつつ、キーが使用される前にロック画面で資格情報を検証するようになっています。以上のような仕組みによって、すべてのデータは自分の端末上で本人によってしか復号化できないようになっています。

メディア スタックとプラットフォームの強化

Android Nougat では、メディアサーバーの再構築と強化が行われています。メディアサーバーは、信頼されていない入力を処理する主要なシステム サービスの 1 つです。まず、Clang の UndefinedBehaviorSanitizer の一部である整数オーバーフローの無害化を取り入れることによって、報告されている libstagefright のバグの大半を占む、あらゆる種類の脆弱性を防止しました。整数オーバーフローを検知すると、攻撃を防ぐためにプロセスをシャットダウンします。さらに、メディア スタックをモジュール化して各コンポーネントを個々のサンドボックスに入れ、各サンドボックスの権限を厳格化して、ジョブの実行に最低限必要な権限のみを持たせるようにしました。この封じ込め技術によって、攻撃者がスタックの多くの部分の欠陥をついて取得できる権限は非常に小さなものになり、カーネルの攻撃対象領域も大幅に削減されています。

メディアサーバーの強化に加え、次のようなさまざまなプラットフォームの保護機能も追加されています。

• セキュアブート: セキュアブートが厳格に適用されるようになり、問題のある端末がブートできなくなります。さらに、エラー訂正によって、悪意のないデータの破損に対する信頼性が向上しています。
• SELinux: SELinux の設定がアップデートされ、Seccomp の対象範囲が増加しています。それによって、アプリケーション サンドボックスが厳重に保護され、攻撃対象領域がさらに少なくなります。
• ライブラリの読み込み順序のランダム化と ASLR の改善: ランダム性が増加することによって、ある種のコード再利用攻撃は難しくなります。
• カーネルの強化: カーネルメモリの一部を読み取り専用とマークすることで、新しいカーネルにメモリ保護を追加し、カーネルがユーザースペースのアドレスにアクセスすることを制限します。これによって、既存の攻撃対象領域がさらに減少します。
• APK 署名スキーム v2: 検証速度の改善と整合性の保証の強化を図るファイル全体の署名スキームが導入されました。

アプリのセキュリティ改善

Android Nougat は、アプリのデベロッパーにとって最も安全で最も簡単に使える Android のバージョンです。

• 別のアプリとデータを共有したいアプリは、FileProvider などのコンテンツ プロバイダを通してファイルを提供することにより、明示的にオプトインする必要があります。API レベル 24 以上を対象にしたアプリでは、アプリのプライベート ディレクトリ（通常は /data/data/）の Linux パーミッションが 0700 になります。
• アプリがセキュアなネットワーク トラフィックへのアクセスを簡単に制御できるように、API レベル 24 以上では、ユーザーがインストールした証明機関と Device Admin API によってインストールされた証明機関は、デフォルトで信頼されなくなります。さらに、すべての新しい Android 端末は、同じ信頼される証明機関を搭載した状態で出荷される必要があります。
• ネットワーク セキュリティ構成によって、デベロッパーは宣言型設定ファイルを使って今まで以上にネットワーク セキュリティ ポリシーを簡単に設定できます。これには、クリアテキスト トラフィックのブロック、信頼される証明機関や証明書の設定、個別のデバッグ設定が含まれます。

さらに、有害な可能性があるアプリからユーザーを保護するために、アプリのパーミッションや機能の改善が継続されています。

• 端末のプライバシー保護のため、MAC アドレスなどの永続的に端末を識別できる情報へのアクセスをさらに制限または廃止しています。
• パーミッション ダイアログ上にユーザー インターフェース オーバーレイを表示することはできなくなっています。この「クリックジャック」技術は、いくつかのアプリで不正にパーミッションを取得するために使われていました。
• ロック画面を設定している場合、そのロック画面を変更できないように端末管理アプリの能力を低下させました。また、端末管理者を無効化する際の onDisableRequested() による通知は受けられなくなります。これは、いくつかのランサムウェアが端末を制御するために使用した方法でした。

システム アップデート

また、OTA アップデート システムが大幅に拡張され、最新のシステム ソフトウェアとセキュリティ パッチによって端末を最新の状態に保つ方法がはるかに簡単になっています。OTA のインストール時間を大幅に短縮し、セキュリティ アップデートの OTA サイズも小さくなっています。アップデート プロセスの中でも特に時間がかかるアプリの最適化ステップを待つ必要はなくなりました。これは、インストールとアップデートを高速に行えるように新しい JIT コンパイラーが最適化されたためです。

ファームウェアがアップデートされた Nougat を実行している新しい Android 端末では、アップデートがさらに高速に行えるようになっています。Chromebook と同様に、アップデートは端末が通常どおり実行されている間にバックグラウンドで適用されます。アップデートは別のシステム パーティションに適用され、再起動した際に新しいバージョンのシステム ソフトウェアを実行しているパーティションにシームレスに切り替わります。
Google は Android のセキュリティ改善のための作業を続けており、Android Nougat はあらゆる面で大幅なセキュリティ改善が図られています。いつものように、作業に対するフィードバックや Android の改善提案は大歓迎です。security@android.com までご連絡ください。


Posted by Yuichi Araki - Developer Relations Team

[この記事は Dave Burke、エンジニアリング部門副社長による Android Developers Blog の記事 "Taking the final wrapper off of Android 7.0 Nougat | Android Developers Blog" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Android 7.0 Nougat

今週から Nexus 端末のユーザーへの Android 7.0 Nougat のロールアウトが開始されています。また、Android 7.0 のソースコードを Android オープンソース プロジェクト（AOSP）にプッシュして、この新バージョンの Android を幅広いエコシステムに公開いたします。

ここ数か月にわたり、今回のリリースに関して皆様からいただいたフィードバックをもとに、ユーザーが Nougat 端末で皆様のアプリをいつでも実行できるよう作業を進めてきました。

Nougat に含まれる機能

Android Nougat には、世界中のたくさんのファンや皆様のようなデベロッパーからの声が反映されています。Android Nougat には、Android での VR モードなど、250 以上の主要な機能が搭載されています。Nougat では、Android スタックのすべてのレベル、具体的には、オペレーティング システムによるセンサーデータの読み取りから、ディスプレイにピクセルを送る方法にまで手が加えられており、高品質モバイル端末 VR 体験の実現に特化した作りになっています。

さらに Nougat には、Android を今まで以上に強力にし、生産性やセキュリティを向上させる多数の新機能も追加されています。新しい JIT/AOT コンパイラを導入して、ソフトウェア パフォーマンスの向上、アプリ インストールの高速化、および消費ストレージの削減を図りました。また、低オーバーヘッド、高パフォーマンスの 3D グラフィック用クロス プラットフォーム API である Vulkan がプラットフォームでサポートされるようになっています。マルチ ウィンドウ サポートによって 2 つのアプリを同時に実行できるようになり、アプリを開かずに直接通知に応答できるダイレクト リプライも導入されました。今までと同様、Android は何層もの強力なセキュリティと暗号化によって作り上げられており、プライベートなデータをプライベートな状態で保つことができるようになっています。それによって、Nougat ではファイルベースの暗号化、シームレスなアップデート、ダイレクト ブートなどの新機能が実現できるようになっています。

詳細な動作の変更点や、アプリで使うことができる新機能など、すべての Nougat デベロッパー リソースはこちらから参照できます。デベロッパー向けの新機能の概要は、こちらからご覧いただけます。また、Nougat の新しいユーザー機能は、こちらからすべてご覧いただけます。

次にアップデートされるユーザー

本日（*原文公開当時）以降数週間をかけて、Nexus 6、Nexus 5X、Nexus 6P、Nexus 9、Nexus Player、Pixel C、General Mobile 4G（Android One）に Android 7.0 Nougat への OTA ソフトウェア アップデートがロールアウトされます。Android ベータ版プログラムに登録している端末も、この最終版を受信します。

また、Android Nougat を搭載したたくさんの魅力的な端末がパートナーから発売されます。Android Nougat をすぐに使うことができる最初の新しいスマートフォン LG V20 もその 1 つです。

このような新しい端末で Nougat が動き始めるため、今こそ Google Play でアプリのアップデートを公開する絶好のタイミングです。API 24 を対象にコンパイルを行うことをお勧めします。まだ最終的な変更に対するテストを行っている場合、Google Play のベータ版テスト機能を使うのがお勧めです。まずは Android 7.0 Nougat のユーザーを含む少人数のユーザーから初期段階におけるフィードバックを得て、その後、アップデートしたアプリを段階的にユーザー全員にリリースすることができます。

Nougat のこれから

Nougat は、これから数四半期にわたる新たな定期メンテナンス スケジュールに移行します。最初の Nougat メンテナンス リリースに向けた作業はすでに開始されています。このリリースには継続的に行われている調整や改善を反映する予定で、秋には Developer Preview を提供したいと考えています。ご期待ください。

Developer Preview ビルドに対して報告されたバグでまだ未対応のものは、まもなく対応が完了する予定です。しかし、フィードバックは今後も大歓迎です。Preview Tracker に記録した問題がまだ解消されていないという方は、AOSP Issue Tracker で Android 7.0 に対して新しく問題を送信してください。

プレビューに参加いただいた皆様、どうもありがとうございました。プレビュー版は、今回新たにリリースする Android バージョンを強化する機会をすべての皆様に提供したいと考え、今年の初めに公開いたしました。皆様の継続的なフィードバックは、ユーザーだけではなく、Android エコシステム全体にとっても非常に貴重なものであり、この最終リリースの仕上げを行う上でとても役立ちます。

Posted by Yuichi Araki - Developer Relations Team

5 月に行われた I/O で発表されたセッション ビデオの一部に日本語字幕が付きました。今日はそのなかで Firebase と Android 関連のビデオをご紹介します。

Firebase 概要（43 分 43 秒）
Firebase の 15 に及ぶ機能を紹介。うち、Analytics、Storage、Remote Config、Test Lab、Crash Reporting、Dynamic Links、Notifications に関してはデモを用いて紹介しています。


ゼロからアプリにする方法：Firebase を使った構築（33 分 54 秒）
Firebase を使うことで Android、iOS、Web という異なるプラットフォームのどれでも、簡単にアプリを作れることをデモをしながら説明します。Android アプリのビルドには Android Studio、iOS アプリには XCodes、Web アプリには Atom を用いています。


Android 最新情報（42 分 35 秒）
Constraint Layout、マルチ ウィンドウの分割画面モード、ピクチャ イン ピクチャ（PIP）、ドラッグ＆ドロップ、通知、Doze モードなど多くの機能について説明しています。



Android アプリを Chromebook に移行するには（26 分 47 秒）
Chrome OS は、44 か国において 13 OEM による 50 種類のデバイスがあります。2015年には 32 % 成長しました。Chromebook で Android アプリがどのように動くか、そのために必要な変更事項などを説明します。



Android デベロッパー ツールの最新情報（43 分 39 秒）
いま、トップ125 アプリのうち、 92 % が Android Studio を利用して作られています。約 25 分間を使い、Android Studio 2.2 の機能についてライブ デモを行い説明しています。


Android Instant Apps のご紹介（4 分 22 秒）
時間のかかるインストールが不要な Instant Apps を紹介するショートビデオです。


字幕は、動画右下の設定アイコン（歯車状のアイコン）から「Subtitles/CC」を開き、「Japanese」を選択することで日本語に変更できます。


Posted by Takuo Suzuki - Developer Relations Team

[この記事は Jeff Vander Stoep、Android セキュリティ チームによる Android Developers Blog の記事 "Protecting Android with more Linux kernel defenses" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Android はセキュリティ モデルを強制するために Linux カーネルを活用しており、カーネルの保護を強化するためにさまざまな仕組みが導入されています。大まかに、このような保護はメモリの保護と攻撃対象領域の削減という 2 つのカテゴリに分けることができます。

メモリの保護

カーネルが提供する主要なセキュリティ機能の 1 つが、アドレス空間を独立させることによって、ユーザー空間で動作するプロセスのメモリを保護する仕組みです。ユーザー空間のプロセスとは異なり、さまざまなカーネルのタスクは 1 つのアドレス空間の中に存在しています。そのため、カーネル内に脆弱性があると、システムメモリの別の部分にも影響する可能性があります。カーネルメモリ保護は、脆弱性があったとしてもカーネルの整合性が維持されるように設計されています。

メモリを読み取り専用/実行不可とマークする

この機能によって、カーネルメモリを論理的なセクションに分割し、それぞれのセクションに制限付きのページアクセス権限を設定できます。コードが格納されたメモリは、読み取り専用 + 実行とマークされます。データ セクションは実行不可とマークされ、さらに読み取り専用のセクションと読み書き可能なセクションに分割されます。この機能は、CONFIG_DEBUG_RODATA 設定オプションで有効になります。これは Kees Cook 氏がまとめたもので、Brad Spengler 氏による Grsecurity の KERNEXEC 機能と、Larry Bassel 氏と Laura Abbott 氏による Qualcomm の CONFIG_STRICT_MEMORY_RWX 機能のサブセットが基になっています。CONFIG_DEBUG_RODATA は、arm/arm64 のアップストリーム カーネルに追加され、Android の 3.18+ arm/arm64 標準カーネルに移植されています。

ユーザー空間へのカーネル アクセスの制限

この機能は、ユーザー空間のメモリへの直接アクセスを禁じることによって、カーネルの保護を強化します。これによって、攻撃者が実行可能な カーネル メモリを制御するのが大幅に難しくなり、さまざまな攻撃を行いにくくなります。特に CONFIG_DEBUG_RODATA が有効になっている場合はそれが該当します。これと同様の機能は既に存在しています。最も早く登場したのは、Grsecurity の UDEREF です。この機能は、Russell King 氏が ARMv7 用に実装した設定オプション CONFIG_CPU_SW_DOMAIN_PAN で有効になり、Kees Cook 氏によって Android の 4.1 カーネルに移植されました。

スタック バッファのオーバーフローに対する保護の強化

stack-protector-strong は、前身である stack-protector と同じように、スタック バッファのオーバーフローからの保護を行います。stack-protector では文字配列のみが保護されていたのに対し、多くの配列型の保護が提供されるようになっています。stack-protector-strong は Han Shan 氏が実装し、gcc 4.9 コンパイラーに追加されました。

攻撃対象領域の削減

攻撃対象領域の削減は、正規の機能を損なうことなく、公開するカーネルへのエントリ ポイントを減らす試みです。攻撃対象領域の削減には、コードの削除、エントリ ポイントへのアクセスの削除、公開する機能の限定などが含まれます。

デバッグ機能へのデフォルト アクセスの削除

カーネルの perf システムはパフォーマンス測定の基盤となっており、カーネルとユーザー空間アプリケーションの両方を解析することができます。perf はデベロッパーにとっては貴重なツールですが、大半の Android ユーザーにとっては、不要な攻撃対象領域を増やすものです。Android Nougat では、デフォルトで perf へのアクセスがブロックされます。デベロッパーは、デベロッパー設定を有効にし、adb を使用して "adb shell setprop security.perf_harden 0" プロパティを設定することによって、perf にアクセスすることができます。

perf へのアクセスをブロックするパッチセットは、カーネル部とユーザー空間部に分けて考えた方がよいかもしれません。カーネルパッチは Ben Hutchings 氏によるもので、Brad Spengler 氏による Grsecurity の CONFIG_GRKERNSEC_PERF_HARDEN から派生しています。ユーザー空間の変更は、Daniel Micay 氏によるものです。perf のセキュリティ脆弱性を責任を持って開示してくださった Wish Wu 氏をはじめとする方々にお礼を申し上げます。

アプリからの ioctl コマンドへのアクセスの制限

Android セキュリティ モデルの多くは、SELinux によって記述、強制されるものです。ioctl() システムコールには、SELinux によって強制される粒度との間に大きなギャップがあります。ioctl システムコールにコマンドごとの制御を提供する手段として、SELinux における ioctl コマンドのホワイトリスト登録が追加されました。

Android で報告されているカーネル脆弱性の大半は、ドライバで ioctl システムコールを使用することによって起きています。その例が、CVE-2016-0820 などです。サードパーティ アプリケーションの中には、いくつかの ioctl コマンドが必要なものもありますが、ほとんどのアプリケーションはそうではなく、ioctl コマンドへのアクセスは正規の機能を損なわずに制限できます。Android Nougat では、アプリケーションが利用できるのはごくわずかなソケット ioctl コマンドのホワイトリストのみとなっています。一部の端末では、アプリケーションからの GPU ioctl へのアクセスも同様に制限されています。

seccomp-bpf の強制

seccomp は、追加のサンドボックス化メカニズムを提供しています。これにより、プロセスは設定変更可能なフィルタを使って、利用できるシステムコールやシステムコールの引数を制限できるようになります。システムコールの利用が制限されることによって、公開されるカーネルの攻撃対象領域は劇的に減少します。Lollipop 搭載の Nexus 端末に seccomp が初めて導入されてから、Android エコシステム全体での seccomp の導入率は着実に増加しています。Android Nougat では、seccomp のサポートは全端末で必須となります。Android Nougat では、メディアのセキュリティ強化の一環として、メディア抽出やメディアコーデックの処理で seccomp を使用しています。

進行中の作業

他にもカーネル保護を目的としたプロジェクトが進行中です。

• Kernel Self Protection Project では、アップストリーム カーネルのランタイムやコンパイラを保護する仕組みが開発されています。
• AOSP では、SELinux によるさらなるサンドボックスの強化と攻撃対象領域の削減が進行中です。
• Minijail では、seccomp フィルタや名前空間など、カーネルが提供する多くの封じ込め機能やサンドボックス機能を便利に適用するための仕組みが提供されています。
• kasan や kcov などのプロジェクトは、ファジング ツールを使ったクラッシュの根本原因追求や、コードのカバレッジを増やすテストケースのスマートな作成を通して、究極的にバグ対応プロセスを効率化することを目指しています。

このような作業によって、カーネルのセキュリティはますます強化されていきます。いつものように、作業に対するフィードバックや Android の改善提案は大歓迎です。security@android.com までご連絡ください。


Posted by Yuichi Araki - Developer Relations Team

[この記事は Sami Tolvanen、ソフトウェア エンジニアによる Android Developers Blog の記事 "セキュアブートの厳格な適用とエラー訂正" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

概要

Android では、ユーザーの安全を保つために複数のレイヤにわたる保護機能が導入されています。そういったレイヤの 1 つがセキュアブートです。セキュアブートは、オペレーティング システムの変更を検知するために、暗号学に基づいた整合性チェックを行うことによってセキュリティを向上させます。Android では Marshmallow 以降からすでにシステムの整合性についてのアラートが表示されるようになっていましたが、Android 7.0 を搭載した端末からは、セキュアブートの厳格な適用が必須になります。ブートイメージや検証済みパーティションが破損している端末は、ブートしなくなるか、ユーザー コンテンツを扱う機能が制限された状態でブートするようになります。しかし、このような厳格なチェックを行うことで、今までほとんど問題にならなかった悪意のないデータ破損が処理機能などに影響を与える可能性がでてきます。

デフォルトで、Android は dm-verity カーネル ドライバを使用して大きなパーティションを検証します。このドライバは、パーティションを 4 KiB のブロックに分割し、各ブロックが読み込まれたときに署名されたハッシュツリーと照合して検証を行います。そのため、dm-verity が強制モードの場合、1 バイトの破損を検出しただけでもブロック全体がアクセスできなくなり、検証済みパーティションへのデータアクセスが発生すると、カーネルがユーザー空間に対して EIO エラーを返すことになります。

本記事では、前方エラー訂正（FEC）の導入による dm-verity の堅牢性向上の内容について説明します。また、これによって、オペレーティング システムのデータ破損への耐性がどのように強まったかについても説明します。この改善は、Android 7.0 が動作するすべての端末に導入されます。なお、本記事は、Nexus 端末に搭載するデフォルトの AOSP 実装について説明しています。

エラー訂正コード

前方エラー訂正とは、エラー訂正コードを使用して生成する冗長な符号化データを追加することで、ソースデータのエラーを検知して訂正できるようにする仕組みです。訂正できるエラーの厳密な数は、使用するコードや符号化データを割り当てる空間の広さによって異なります。

エラー訂正コードの中でよく使われるものの中に、リード ソロモンがあります。これは Linux カーネルですぐに使える状態になっているので、dm-verity で使用する候補としてはうってつけです。このコードを使って ⌊t/2⌋ 個までの未知のエラーと t 個までの既知のエラー（イレイジャー）を訂正できるのは、 t 個の符号化シンボルが追加された場合です。

一般的に使われる RS(255, 223) コードでは、ソースデータ 223 バイトごとに 32 バイトの符号化データを生成します。これは、255 バイトのブロックごとに 16 個までの未知のエラーを訂正できます。ただし、このコードを使用すると、最大 15% の空間オーバーヘッドが余計に消費されることになります。モバイル端末はストレージに制約があるため、これは現実的ではありません。そこで、エラー訂正機能を減らして空間オーバーヘッドを減らすことになります。RS(255, 253) コードは 1 個の未知のエラーしか訂正できませんが、オーバーヘッドはわずか 0.8% です。


ブロックベースのストレージ破損の難しいところは、ブロック全体が破損することが多く、破損が複数の連続するブロックにまたがることがある点です。リード ソロモンは、かなり短い符号化ブロック内の限られた数のバイトの破損の復旧しかできないため、ネイティブの実装では、巨大な空間オーバーヘッドなしに効率的なエラー訂正を行うことはできません。

連続した破損ブロックの復旧

Android 7.0 用の dm-verity に加えられた変更には、インターリービングと呼ばれる手法が利用されています。この手法を用いると、4 KiB のソースブロック全体が失われても復旧できるだけでなく、いくつかの連続したブロックが失われても復旧できます。さらに、実用的なエラー訂正を行うために必要な空間オーバーヘッドをネイティブ実装に比べて大幅に削減することもできます。

ブロックの各バイトを別々のリード ソロモン コードにマッピングすると、効率的なインターリービングを行うことができます。具体的には、N バイトをカバーするコードがそれぞれのバイトに対応する N 個のソースブロックにまたがるようにします。各コードが連続した N ブロックのシーケンスをカバーするという簡単なインターリービングでも、 (255 - N) / 2 ブロックまでの破損から復旧できます。たとえば、RS (255, 223) の場合、64 KiB の破損から復旧できます。

さらに優れたソリューションは、各コードをパーティション全体に分散させ、同じコードによってカバーされるバイト間の距離を最大にすることです。これによって、T ブロックで構成されるパーティションにおいて RS (255, N) コードで対応できる連続破損ブロックの数は、⌈T/N⌉ × (255 - N) / 2 まで増加します。



距離 D、ブロックサイズ B におけるインターリービング

dm-verity が既に実行している整合性チェックとインターリービングを組み合わせると、各コード内のどの位置でエラーが発生しているかを正確に突き止めることができるというメリットも生まれます。コードの各バイトが別々のソースブロックをカバーしており、既存の dm-verity メタデータを使用して各ブロックの整合性を検証できるので、どのバイトにエラーが含まれているかを知ることができます。イレイジャーの場所をピンポイントで指定できることによって、エラー訂正のパフォーマンスと効率が上がり、最大で連続 ⌈T/N⌉ × (255 - N) ブロックまでエラー訂正を行うことができるようになります。

524,256 個の 4 KiB ブロックと RS (255, 253) を使用する 2 GiB までのパーティションでは、1 つのコードのバイトは最大で 2073 ブロック離れることになります。各コードは 2 つのイレイジャーから復旧できるため、インターリービング手法を用いると最大で 4,146 個（最大 16 MiB）の連続した破損ブロックを復旧できます。もちろん、符号化データ自体が破損したり、1 つのコードがカバーしているブロックが 3 つ以上失われると、復旧はできなくなります。

エラー訂正をブロックベースのストレージで利用する限り、復号化が遅くなるというインターリービングの副作用は発生しません。というのも、エラーを復旧するためには、1 つのブロックを読み込むのではなく、複数のパーティションにまたがる複数のブロックを読み込む必要があるからです。幸運にも、dm-verity とソリッドステート ストレージを組み合わせる場合、これは大きな問題にはなりません。復号化の必要があるのは、ブロックが実際に破損している場合のみだからです。これはかなり珍しいケースであり、エラー訂正が必要になる場合でも、ランダム アクセスによる読み込みはかなり高速です。

まとめ

セキュアブートの厳格な適用によってセキュリティは改善されますが、ソフトウェアのバグやハードウェアの問題によって発生する可能性がある端末のディスク破損の影響が大きくなり、信頼性の低下につながることも考えられます。

dm-verity 用に開発された新しいエラー訂正機能では、わずか 0.8% の空間オーバーヘッドで通常 2～3 GiB のシステム パーティション内で最大 16～24 MiB の連続したブロックが失われても復旧できるようになっています。さらに、破損を検知した場合を除き、パフォーマンスの低下もありません。これによって、Android 7.0 を実行する端末のセキュリティと信頼性が向上することになります。


Posted by Yuichi Araki - Developer Relations Team

[この記事は Dave Burke、エンジニアリング部門副社長による Android Developers Blog の記事 "Final Developer Preview before Android 7.0 Nougat begins rolling out" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]



今年の夏後半に予定されている Android 7.0 Nougat 搭載端末の発売が近づいています。そして本日（原文公開当時）、プレビュー シリーズの最終マイルストーンとなる デベロッパー プレビュー 5 をリリースしました。先月のデベロッパー プレビューには、Nougat 向けの最終 API が含まれていました。今回のプレビューでは、サポートされているすべてのプレビュー端末向けにほぼ最終となるシステム アップデートを提供します。デベロッパーの皆様は、これを使ってアプリのリリースに向けた準備を行うことができます。

Nougat 向けの最終デベロッパー プレビューには、以下のものが含まれています。

• Nexus などのプレビュー端末向けのシステム イメージ
• アプリの準備ができたかどうかを確認する最終テストに使用できるエミュレータ
• 最終の N API（API レベル 24）、最新のシステム動作と UI を搭載したシステム
• 最新のバグ修正、システム全体やプレインストールされたアプリの最適化

この最新の Developer Preview で、どこでも機能する Doze、バックグラウンド処理の最適化、画面のズーム、パーミッションの変更など、Android N でのシステム動作の変更点のすべてに対応したアプリになっていることを確認してください。さらに、マルチ ウィンドウのサポート、ダイレクト リプライなどの通知の機能強化、ダイレクト ブート、新しい絵文字などの Android N の新しいデベロッパー向け機能を活用することができます。

Google Play のアルファ版、ベータ版、または製品版のチャネルにアプリを公開する

デベロッパー プレビュー 5 でのアプリのテストが完了したら、すぐにアップデートを Google Play に公開しましょう。API 24 でコンパイルし、必要に応じて API 24 をターゲットに指定して、Google Play デベロッパー コンソールのアルファ版、ベータ版、さらに製品版のチャネルに公開します。その際に便利な方法は、Google Play のベータ版テスト機能を使って、Developer Preview のユーザーを含む少人数のユーザーから初期段階でのフィードバックを入手し、その後、アップデートしたアプリを段階的にユーザー全員にリリースすることです。

Developer Preview 5 を入手する方法

既に Android ベータ版プログラムに登録している方には、すぐに デベロッパー プレビュー 5 のアップデートが配信されるはずです。ユーザー側の操作は必要ありません。まだ Android ベータ版プログラムに登録していない方は、次の方法で簡単に利用を開始できます。android.com/beta にアクセスして、対象の Android 携帯端末またはタブレットをオプトインするだけで、すぐに今回のプレビュー アップデートを OTA で受信できます。通常どおり、このアップデートを手動でダウンロードして書き込むこともできます。Nougat デベロッパー プレビューは、Nexus 6、Nexus 5X、Nexus 6P、Nexus 9、Pixel C 端末のほか、General Mobile 4G（Android One）端末に対応しています。

いつもフィードバックにご協力いただき、ありがとうございます。今夏の終わり頃に予定している正式リリースに向けて努力してまいりますので、今後も N デベロッパー プレビュー Issue Tracker、N プレビュー デベロッパー コミュニティ、または Android ベータ版コミュニティを通じてフィードバックやリクエストをお寄せください。Android Nougat のリリースは間近に迫っています。


Posted by Takeshi Hagikura - Developer Relations Team

[この記事は Chad Brubaker、 Android セキュリティ チームによる Android Developers Blog の記事 "Changes to Trusted Certificate Authorities in Android Nougat" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Android Nougat（7.0）では、さらに安全なデフォルトを提供してアプリのトラフィックを保護するため、Android が認証局（CA）を扱う方法が変更されています。ほとんどのアプリやユーザーはこの変更による影響は受けず、特にアクションは必要ありません。変更点は、以下のとおりです。

• カスタム CA を信頼するための安全で簡単な API
• 対象 API レベル 24 以上のアプリは、安全な接続を確保するため、デフォルトではユーザーや管理者が追加した CA を信頼しない。
• Android Nougat を実行しているすべての端末は、同じ標準システム CA を使用し、端末固有のカスタマイズは行わない。

これらの変更点の詳細や、これらによって影響を受ける場合は、以下をお読みください。

安全で簡単な API

アプリは、認証局をいつでもカスタマイズできます。ただし、Java TLS API は複雑なため、誤った設定をしているアプリも見受けられます。これに対処するため、信頼をカスタマイズするための API を改良しました。

ユーザーが追加した CA

Android アプリケーション サンドボックスの主な目的は、すべてのアプリケーション データを保護することです。Android Nougat では、アプリケーションがユーザーや管理者が提供した CA をどのように使用するかが変更されています。デフォルトでは、対象 API レベル 24 のアプリは意図的にこのような CA を信頼しないようになっています。信頼されるのは、アプリで明示的にオプトインされている場合のみです。この安全なデフォルト設定によって、アプリケーションの攻撃対象領域が減少し、ネットワークやファイルに基づくアプリケーション データに対し一貫性のある扱いができるようになります。

信頼できる CA のカスタマイズ

Android Nougat では、ネットワーク セキュリティ構成を使用して、アプリが信頼する CA のカスタマイズを簡単に行うことができます。必要に応じて、アプリ全体で信頼することも、あるドメインへの接続のみ信頼することも可能です。以下に、カスタムまたはユーザーが追加した CA やシステム CA を信頼するいくつかの例を示します。他の例や詳細については、詳細なドキュメントをご覧ください。

デバッグ用にカスタム CA を信頼する

ローカルでアプリのデバッグを行う場合のみカスタムの CA を信頼するには、ネットワーク セキュリティ構成に次のような内容を含めます。アプリがデバッグ可能と明示されている場合のみ、CA が信頼されます。

<network-security-config>  
      <debug-overrides>  
           <trust-anchors>  
                <!-- Trust user added CAs while debuggable only -->
                <certificates src="user" />  
           </trust-anchors>  
      </domain-config>  
 </network-security-config>

あるドメインに対してカスタム CA を信頼する

アプリが特定のドメインに接続する場合にカスタムの CA を信頼するには、ネットワーク セキュリティ構成に次のような内容を含めます。

<network-security-config>  
      <domain-config>  
           <domain includeSubdomains="true">internal.example.com</domain>  
           <trust-anchors>  
                <!-- Only trust the CAs included with the app  
                     for connections to internal.example.com -->  
                <certificates src="@raw/cas" />  
           </trust-anchors>  
      </domain-config>  
 </network-security-config>

複数のドメインに対してユーザーが追加した CA を信頼する

アプリが複数のドメインに接続する場合にユーザーが追加した CA を信頼するには、ネットワーク セキュリティ構成に次のような内容を含めます。

<network-security-config>  
      <domain-config>  
           <domain includeSubdomains="true">userCaDomain.com</domain>  
           <domain includeSubdomains="true">otherUserCaDomain.com</domain>  
           <trust-anchors>  
                  <!-- Trust preinstalled CAs -->  
                  <certificates src="system" />  
                  <!-- Additionally trust user added CAs -->  
                  <certificates src="user" />  
           </trust-anchors>  
      </domain-config>  
 </network-security-config>

一部を除くすべてのドメインに対してユーザーが追加した CA を信頼する

アプリが指定されたドメインを除くすべてのドメインに接続する場合にユーザーが追加した CA を信頼するには、ネットワーク セキュリティ構成に次のような内容を含めます。

<network-security-config>  
      <base-config>  
           <trust-anchors>  
                <!-- Trust preinstalled CAs -->  
                <certificates src="system" />  
                <!-- Additionally trust user added CAs -->  
                <certificates src="user" />  
           </trust-anchors>  
      </base-config>  
      <domain-config>  
           <domain includeSubdomains="true">sensitive.example.com</domain>  
           <trust-anchors>  
                <!-- Only allow sensitive content to be exchanged  
             with the real server and not any user or  
    admin configured MiTMs -->  
                <certificates src="system" />  
           <trust-anchors>  
      </domain-config>  
 </network-security-config>

保護された接続すべてでユーザーが追加した CA を信頼する

保護された接続すべてで、アプリにユーザーが追加した CA を信頼させるには、ネットワーク セキュリティ構成に次の内容を追加します。

<network-security-config>  
      <base-config>  
            <trust-anchors>  
                <!-- Trust preinstalled CAs -->  
                <certificates src="system" />  
                <!-- Additionally trust user added CAs -->  
                <certificates src="user" />  
           </trust-anchors>  
      </base-config>  
 </network-security-config>

システムが信頼する標準 CA

Android エコシステム全体での一貫性と安全性を向上するため、Android Nougat 以降では、互換性のある端末は AOSP でメンテナンスされている標準システム CA のみを信頼するようになります。

以前は、システムにバンドルされているプレインストール CA は端末によって異なりました。そのため、アプリの接続に必要な CA が端末に含まれていない場合に互換性の問題が生じたり、セキュリティ要件を満たさない CA が端末に含まれている場合にセキュリティの問題が生じる可能性がありました。

Android に含める必要があると思われる CA をお持ちの場合

まず、CA をシステムに含める必要があるかを確認してください。プレインストールされる CA は、端末上のほとんどのアプリの接続保護に影響するため、セキュリティ要件を満たす CA のみとなります。CA を必要とするホストに接続するために CA を追加する必要がある場合、CA の追加ではなく、そのホストに接続するアプリやサービスをカスタマイズするようにします。詳細については、上記の 信頼できる CA のカスタマイズ のセクションをご覧ください。

Android に含まれてしかるべき CA を扱う場合は、まず Mozilla CA Inclusion Process の手続きを完了し、Android に対してその CA を標準システム CA に追加する機能リクエストを提出してください。

Posted by Yuichi Araki - Developer Relations Team

[この記事は Dmitry Malykhanov、デベロッパー アドボケートによる Android Developers Blog の記事 "Android changes for NDK developers" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

他の Android プラットフォームの改善と合わせて、Android M と N のダイナミック リンカーのコード記述要件が厳しくなりました。これは、クロスプラットフォームでコンパイル可能なきれいなネイティブ コードをロードできるようにするためです。最新の Android リリースにスムーズに移行できるように、このルールや推奨事項に従ってアプリケーションのネイティブ コードを記述することが必要になります。

個別の変更点については、以下で詳しく説明します。いずれも、ネイティブ コードのロードに関する問題を回避した結果、あるいは問題を回避するステップに伴う変更です。

必須ツール: NDK の各アーキテクチャには、toolchains/ の下に <arch>-linux-android-readelf バイナリ（たとえば、arm-linux-androideabi-readelf や i686-linux-android-readelf）というファイルがありますが、ここで使用している基本的な検査だけであれば、readelf はどのアーキテクチャに対しても使用できます。Linux では、readelf を使うには「binutils」パッケージ、scanelf を使うには「pax-utils」パッケージのインストールが必要です。

プライベート API（API 24 以降で強制）

ネイティブ ライブラリは、パブリック API のみを使用しなければならず、NDK 以外のプラットフォーム ライブラリにリンクしてはいけません。このルールは API 24 以降で強制となり、アプリケーションは NDK 以外のプラットフォーム ライブラリをロードできなくなります。このルールを強制するのはダイナミック リンカーなので、コードがどのような手段でロードしようとしても、パブリックでないライブラリにアクセスすることはできません。System.loadLibrary(...)、DT_NEEDED エントリ、dlopen(...) の直接呼び出しは、いずれも同じように失敗します。

アプリをアップデートしても、ユーザーは一貫した操作性を提供されるべきです。また、プラットフォームの変更に対応するために、デベロッパーが緊急アップデートを行なわなければならないのは適切ではありません。その理由から、プライベートな C/C++ シンボルの利用を控えることをおすすめします。プライベート シンボルのテストは、すべての Android 端末が合格する必要のある互換性テストスイート（CTS）に含まれていません。プライベート シンボルが存在しない可能性や、動作が異なる可能性があります。そのため、プライベート シンボルを使用するアプリは、特定の端末や将来のリリースで動作しなくなる可能性が高くなります。Android 6.0 Marshmallow で OpenSSL が BoringSSL に切り替えられた際に、多くのデベロッパーがこれを経験しました。

この変更によるユーザーへの影響を軽減するために、Google Play でインストール率の高いアプリで多く使われており、しばらくの間サポートが可能ないくつかのライブラリを特定しました。これには、libandroid_runtime.so、libcutils.so、libcrypto.so、libssl.so などが含まれています。また、移行に当てられる時間を長くとれるように、これらのライブラリは一時的にサポートいたします。ただし、将来のリリースでコードが動作しなくなるという警告を見かけたら、すぐに修正をしていただくようお願いいたします。

$ readelf --dynamic libBroken.so | grep NEEDED
 0x00000001 (NEEDED)                     Shared library: [libnativehelper.so]
 0x00000001 (NEEDED)                     Shared library: [libutils.so]
 0x00000001 (NEEDED)                     Shared library: [libstagefright_foundation.so]
 0x00000001 (NEEDED)                     Shared library: [libmedia_jni.so]
 0x00000001 (NEEDED)                     Shared library: [liblog.so]
 0x00000001 (NEEDED)                     Shared library: [libdl.so]
 0x00000001 (NEEDED)                     Shared library: [libz.so]
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so]
 0x00000001 (NEEDED)                     Shared library: [libm.so]
 0x00000001 (NEEDED)                     Shared library: [libc.so]

発生する恐れのある問題: API 24 以降、ダイナミック リンカーはプライベート ライブラリをロードしないため、アプリケーションがロードできなくなります。

解決策: パブリック API のみを使うようにネイティブ コードを書き直します。短期的な回避策として、複雑な依存性のないプラットフォーム ライブラリ（libcutils.so）をプロジェクトにコピーすることができます。長期的な解決策としては、関連するコードをプロジェクト ツリーにコピーする必要があります。SSL / Media / JNI 内部 / バインダ API には、ネイティブ コードからアクセスするべきではありません。必要な場合は、ネイティブ コードから適切なパブリック Java API のメソッドを呼び出します。

パブリック ライブラリの完全なリストは、NDK 内で参照できます。platforms/android-API/usr/lib 以下をご覧ください。

注: SSL/crypto は特殊なケースです。アプリケーションは、プラットフォームの libcrypto および libssl ライブラリを直接使用してはいけません。これは古いプラットフォームにも該当します。既知の脆弱性から保護されるよう、すべてのアプリケーションで GMS セキュリティ プロバイダを使用してください。

セクション ヘッダーの欠落（API 24 以降で強制）

各 ELF ファイルのセクション ヘッダーには、追加情報が含まれています。ダイナミック リンカーがサニティ チェックを行う際にこのヘッダーを使うため、ヘッダーの存在が必須となります。バイナリを難読化してリバース エンジニアリングを防ぐために、このヘッダーを取り除こうとするデベロッパーもいます（取り除いた情報は広く入手できるツールを使って再構築できるため、この方法は実際にはあまり役に立ちません）。

$ readelf --header libBroken.so | grep 'section headers'
  Start of section headers:          0 (bytes into file)
  Size of section headers:           0 (bytes)
  Number of section headers:         0
$

解決策: ビルド時にセクション ヘッダーを取り除くステップを行わないようにします。

テキストの再配置（API 23 以降で強制）

API 23 以降、共有オブジェクトにテキストの再配置を含めることはできません。つまり、コードはそのままロードし、変更せずに使用する必要があります。このようなアプローチによって、ロード時間が短くなり、セキュリティも向上します。

テキストの再配置を行う一般的な理由は、位置に依存した手書きのアセンブラの存在です。これは一般的ではありません。さらに詳しい診断を行うには、ドキュメントに記載されている scanelf ツールを使用してください。

$ scanelf -qT libTextRel.so
  libTextRel.so: (memory/data?) [0x15E0E2] in (optimized out: previous simd_broken_op1) [0x15E0E0]
  libTextRel.so: (memory/data?) [0x15E3B2] in (optimized out: previous simd_broken_op2) [0x15E3B0]
[skipped the rest]

scanelf ツールを利用できない場合は、代わりに readelf を使用して基本的なチェックを行うことも可能です。その場合、TEXTREL エントリか TEXTREL フラグを探します。どちらかが見つかれば十分です（TEXTREL エントリに対応する値は関係なく、通常は 0 です。TEXTREL エントリが存在するだけで、.so にテキストの再配置が含まれていることがわかります）。次の例では、両方が存在しています。

$ readelf --dynamic libTextRel.so | grep TEXTREL
 0x00000016 (TEXTREL)                    0x0
 0x0000001e (FLAGS)                      SYMBOLIC TEXTREL BIND_NOW
$

注: 技術的には、共有オブジェクトに TEXTREL エントリ / フラグがあっても、実際のテキストの再配置は含まれていない場合も考えられます。これは NDK では発生しませんが、Android のダイナミック リンカーはこのエントリ / フラグに基づいて判断しているため、独自に ELF ファイルを生成している場合は、テキストの再配置を含むことを宣言している ELF ファイルを生成していないことを確認してください。

発生する恐れのある問題: 再配置は、強制的にコードページを書き込み可能にし、メモリ内のダーティー ページ数を無駄に増加させます。Android K（API 19）以降、ダイナミック リンカーはテキストの再配置について警告してきましたが、API 23 以降では、テキストの再配置を含むコードをロードできなくなります。

解決策: アセンブラを位置に依存しないように書き直し、テキストの再配置が不要になるようにします。詳しい説明は、Gentoo のドキュメントをご覧ください。

無効な DT_NEEDED エントリ（API 23 以降で強制）

ライブラリの依存性（ELF ヘッダーの DT_NEEDED エントリ）は絶対パスでも構いませんが、ライブラリがシステムのどこにインストールされるかを制御できない Android では、絶対パスは意味をなしません。DT_NEEDED エントリは必要となるライブラリの SONAME と同じである必要があり、実行時にライブラリを探す作業はダイナミック リンカーに委ねられます。

API 23 より前は、Android のダイナミック リンカーが必要なライブラリを探す際に、フルパスを無視してベース名（最後の「/」以降）だけを使用していました。API 23 以降では、実行時リンカーが DT_NEEDED を正確に解釈するため、端末上の正確な場所にライブラリが存在しない場合、ライブラリをロードできません。

さらに悪いことに、ビルド ホスト上のファイルを指す DT_NEEDED エントリを挿入するバグがあるビルドシステムも存在します。その場合、端末上でライブラリを見つけることはできません。

$ readelf --dynamic libSample.so | grep NEEDED
 0x00000001 (NEEDED)                     Shared library: [libm.so]
 0x00000001 (NEEDED)                     Shared library: [libc.so]
 0x00000001 (NEEDED)                     Shared library: [libdl.so]
 0x00000001 (NEEDED)                     Shared library:
[C:\Users\build\Android\ci\jni\libBroken.so]
$

発生する恐れのある問題: API 23 より前では、DT_NEEDED エントリのベース名が使われました。API 23 以降では、Android ランタイムは指定されたパスを使用してライブラリをロードしようとしますので、パスが端末上に見つかりません。SONAME ではなく、ビルド ホスト上のパスを使用するという問題があるサードパーティ製のツールチェーンやビルドシステムも存在します。

解決策: 必要なすべてのライブラリが SONAME だけによって参照されていることを確認してください。端末によって場所が異なる可能性があるため、ライブラリは実行時リンカーに探させてロードさせるようにします。

SONAME の欠落（API 23 以降で使用）

すべての ELF 共有オブジェクト（「ネイティブ ライブラリ」）に、SONAME（共有オブジェクト名）属性が必要です。デフォルトで NDK ツールチェーンはこの属性を追加します。そのため、この属性が存在しないということは、誤って別のツールチェーンを設定しているか、ビルドシステムの設定が誤っているかのどちらかです。SONAME がない場合、代わりにファイル名が利用されるので、実行時に誤ったライブラリがロードされるなどの問題が発生する可能性があります。

$ readelf --dynamic libWithSoName.so | grep SONAME
 0x0000000e (SONAME)                     Library soname: [libWithSoName.so]
$

発生する恐れのある問題: 名前空間の衝突により、実行時に誤ったライブラリがロードされる可能性があります。その場合、必要なシンボルが見つからない、または利用しようとしているライブラリとは違う ABI 非互換のライブラリが使われるため、クラッシュが発生します。

解決策: 最新の NDK は、デフォルトで正しい SONAME を生成します。最新の NDK を利用していることと、（-soname リンカー オプションによって）不適切な SONAME エントリを生成するようにビルドシステムを設定していないことを確認します。

最新の NDK で正しくビルドしたクロスプラットフォームのコードは、Android N で問題なく動作します。正しいバイナリを生成できるように、ネイティブ コード ビルドを見直してみることをおすすめします。


Posted by Yuichi Araki - Developer Relations Team

[この記事は Ian Lake、デベロッパー アドボケートによる Android Developers Blog の記事 "Notifications in Android N" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Android の通知の多くは、Android 向けアプリとユーザーとの間の成功の保証がないインタラクションであると言えます。快適なユーザー エクスペリエンスを実現するために、Android N では、通知の外観の変更、カスタムビューのサポート強化、ダイレクト リプライの機能拡張、新しい MessagingStyle、バンドル通知といった機能が追加されています。

新しい外観で同じ通知

最初にあげるべき最もわかりやすい変更点は、通知のデフォルトのルック アンド フィールが大きく変更されたことです。通知内に広がっていたさまざまなフィールドは、アプリのアイコンと名前が表示された新しいヘッダー行に格納されるようになります。この変更で、スペース内にタイトル、テキスト、大きなアイコンができるだけ目立つように表示されるようになっています。その結果、通知が少しだけ大きくなり、読みやすくなりました。



ヘッダーが 1 行になったことで、そこに表示される情報の重要性が増します。Android N では、デフォルトで時間が表示されなくなります。メッセージング アプリのように時間が重要になる通知の場合では、setShowWhen(true) で時間の表示を有効化できます。さらに、コンテンツ情報や番号よりもサブテキストが優先されるようになります。Android N デバイスでは番号は表示されなくなり、以前のバージョンの Android でサブテキストがない場合に限り、コンテンツ情報が表示されます。いずれの場合でも、サブテキストには意味のある便利な情報を使用してください。たとえば、ユーザーが 1 つしかアカウントを持っていない場合は、サブテキストにアカウントのメールアドレスを表示しないようにします。

また、通知アクションのデザインも見直されており、通知の下に別のバーが表示されるようになっています。



新しい通知には、アイコンが表示されていないことにお気づきかもしれません。通知シェードの限られたスペースにアイコンを入れるのではなく、ラベルが大きくなっています。ただし、通知アクション アイコンは必須のままであり、古いバージョンの Android や Android Wear などのデバイスでは引き続き使用されます。

NotificationCompat.Builder やそこで提供されている標準スタイルを使って通知を構築している場合、コードを変更することなく、デフォルトで新しいルック アンド フィールが反映されます。

カスタムビューのサポート強化

上記の方法ではなく、カスタムの RemoteViews を使って通知を作成している場合、新しいスタイルに適応させるのは困難な場合があります。新しいヘッダー、展開動作、アクション、大きなアイコンは、通知のメインのテキストとタイトルとは別々の要素として配置されるため、すべての要素を提供できる新しい DecoratedCustomViewStyle と DecoratedMediaCustomViewStyle が導入されています。これによって、新しく追加された setCustomContentView() メソッドを利用してコンテンツ部分のみを作成すればいいようになっています。



また、今後ルック アンド フィールが変更されても、スタイルのアップデートはプラットフォーム側で行われ、アプリ側ではコードの変更が必要なくなるため、対応するのが簡単になります。

ダイレクト リプライ

通知アクションからは、既に Activity の起動に加え、Service や BroadcastReceiver によるバックグラウンドでの作業を行うことができるようになっています。今回はさらに、ダイレクト リプライを使って通知アクション内でインライン テキスト入力が可能なアクションを作成できるようになりました。



ダイレクト リプライでは、もともと Android Wear 向けに導入されたものと同じ RemoteInput API を使用して、Action がユーザーから直接入力を受け取れるようになっています。

RemoteInput 自体には、キーなどの情報が含まれています。後ほど、このキーを使用して入力やユーザーが入力を開始する前に表示されるヒントのテキストを取得できます。

// Where should direct replies be put in the intent bundle (can be any string)
private static final String KEY_TEXT_REPLY = "key_text_reply";

// Create the RemoteInput specifying this key
String replyLabel = getString(R.string.reply_label);
RemoteInput remoteInput = new RemoteInput.Builder(KEY_TEXT_REPLY)
        .setLabel(replyLabel)
        .build();

構築した RemoteInput は、addRemoteInput() メソッドでアクションにアタッチすることができます。Android Wear 2.0 用にスマート リプライの選択肢を生成する setAllowGeneratedReplies(true) を呼び出し、ユーザーがすばやく簡単に応答できるようにすることも検討するとよいでしょう。

// Add to your action, enabling Direct Reply for it
NotificationCompat.Action action =
    new NotificationCompat.Action.Builder(R.drawable.reply, replyLabel, pendingIntent)
        .addRemoteInput(remoteInput)
        .setAllowGeneratedReplies(true)
        .build();

なお、ダイレクト リプライをサポートしていない Marshmallow 以前のデバイスでは、Action に渡す pendingIntent は Activity である必要があります（ユーザーに応答を入力してもらうために、ロック画面を解除して Activity を開始し、入力フィールドにフォーカスを当てるためです）。Android N デバイスの場合は、ロック画面からでもバックグラウンドでテキスト入力を処理できるように、Service（別のスレッドで処理する必要がある場合）または BroadcastReceiver（UI スレッドで動作する場合）である必要があります（システム設定からは、ロックされたデバイスでのダイレクト リプライの有効、無効を制御することができます）。

その後、Service や BroadcastReceiver で RemoteInput.getResultsFromIntent() メソッドを使い、入力されたテキストを抽出できます。

private CharSequence getMessageText(Intent intent) {
    Bundle remoteInput = RemoteInput.getResultsFromIntent(intent);
    if (remoteInput != null) {
        return remoteInput.getCharSequence(KEY_TEXT_REPLY);
    }
    return null;
 }

テキストを処理した後は、通知を更新する必要があります。これがトリガーとなって、ダイレクト リプライの UI が非表示になります。この際に、リプライが正常に受信され、処理されたことをユーザーが確認できるようにする必要があります。

ほとんどのテンプレートでは、この処理に新しく追加された setRemoteInputHistory() メソッドを使用しています。このメソッドは、通知の下部にリプライを追加します。他のユーザーのリプライなどによってメイン コンテンツが更新されるまでは、履歴にリプライを追加するようにします。



ただし、会話をやり取りするようなメッセージング アプリを開発している場合は、MessagingStyle を使用してメッセージを追加するとよいでしょう。

MessagingStyle

ダイレクト リプライと新しく追加された MessagingStyle は、継続的にやり取りされる会話の表示に最適です。



このスタイルは、addMessage() メソッドで追加できる複数のメッセージ用の組み込みフォーマットです。各メッセージには、テキスト本文、タイムスタンプ、メッセージの送信者を渡すことができます（これによってグループでの会話がしやすくなります）。

builder.setStyle(new NotificationCompat.MessagingStyle("Me")
    .setConversationTitle("Team lunch")
    .addMessage("Hi", timestampMillis1, null) // Pass in null for user.
    .addMessage("What's up?", timestampMillis2, "Coworker")
    .addMessage("Not much", timestampMillis3, null)
    .addMessage("How about lunch?", timestampMillis4, "Coworker"));

このスタイルは、現在のユーザーのメッセージを区別して示し、その名前も表示（このケースでは「Me」を表示）することに特化しています。オプションで会話のタイトルも設定できます。BigTextStyle を使ってこれを手動で実現することもできますが、このスタイルを Android Wear 2.0 で使用すると、ユーザーは即座にインラインで応答を受信できます。展開した通知ビューを処理する手間が省けるため、Wear に完全対応したアプリを構築しなくてもシームレスな操作を提供できます。

バンドル通知

新しい外観、ダイレクト リプライ、MessagingStyle と、今までのあらゆるベスト プラクティスを活用して通知を作成した後は、全般的な通知の操作性について検討します。とりわけ、複数の通知を送信する（たとえば、継続する会話の 1 件ごとや、新しいメールのスレッドごとに通知する）場合はこれが重要になります。

バンドル通知は、ユーザーが別の通知を参照している際に 1 件だけサマリーを表示したい場合にも、あるいはすべての通知を同時に処理したり、まとめられた通知を展開して個々の通知を処理したい場合にも最適です（これには、アクションやダイレクト リプライも含まれます）。

Android Wear で通知のスタックを開発したことがある場合、それとまったく同じ API を使うことができ、各通知に setGroup() を追加するだけで、通知を 1 つにまとめることができます。グループは 1 つに限る必要はないので、通知は好きなようにまとめることができます。たとえば、メールアプリではアカウントごとに通知をまとめるとよいかもしれません。

また、サマリー通知を作成することも重要です。サマリー通知は、setGroupSummary(true) で指定できます。Marshmallow 以前のデバイスで表示される通知はサマリー通知のみなので、（おわかりと思いますが）個々の通知をすべてまとめる必要があります。その際には、InboxStyle を使うとよいでしょう。ただしこれは必須ではありません。Android N 以上のデバイスでは、サマリー通知から一部の情報（サブテキスト、コンテンツ インテント、削除インテント）が抽出され、バンドル通知用の折りたたまれた通知になります。そのため、すべての API レベルでサマリー通知を作成する必要があります。

Android N デバイスでは、全般的なユーザー エクスペリエンスを改善するために、グループのない通知を 4 つ以上送信すると、自動的に通知がまとめられます。

N は Notification（通知）の N

Android の通知は常に進化し続けています。Gingerbread のころのシングルタップ ターゲットから、展開可能な通知、アクション、MediaStyle、最新のダイレクト リプライやバンドル通知などの機能に至るまで、通知は Android の総合的なユーザー エクスペリエンスにおいて重要な役割を果たしています。

ぜひ、多くの新しいツール（と下方互換性を維持するための NotificationCompat）をご活用ください。#BuildBetterApps での皆様からの報告を楽しみにしています。

さらに情報を得るには、Android Development Patterns Collection をフォローしてください。



Posted by Yuichi Araki - Developer Relations Team

[この記事は Sergio Giro、ソフトウェア エンジニアによる Android Developers Blog の記事 "Security "Crypto" provider deprecated in Android N" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Android アプリで SHA1PRNG アルゴリズムを利用して Crypto プロバイダからキーを導出している場合は、本物のキー導出関数を使うように変更する必要があります。既存のデータも暗号化し直す必要があるかもしれません。

Java 暗号化アーキテクチャを使用すると、次のような呼び出しによって暗号や疑似乱数ジェネレータのようなクラスのインスタンスを作成できます。
SomeClass.getInstance("SomeAlgorithm", "SomeProvider");
もっと単純に、次のように書くこともできます。
SomeClass.getInstance("SomeAlgorithm");
たとえば、次のような使い方が可能です。
Cipher.getInstance(“AES/CBC/PKCS5PADDING”);
SecureRandom.getInstance(“SHA1PRNG”);
Android でプロバイダを指定することは推奨されていません。通常、プロバイダを指定した Java Cryptography Extension（JCE）API の呼び出しを行うのは、プロバイダがアプリケーションに含まれている場合や、ProviderNotFoundException が発生した場合にアプリケーションで対応できる場合に限る必要があります。

残念なことに、多くのアプリは削除される「Crypto」プロバイダに依存しています。これはキー導出のアンチパターンです。

このプロバイダは、SecureRandom のインスタンス用の「SHA1PRNG」アルゴリズムの実装のみを提供するものでした。ここで問題になるのは、SHA1PRNG アルゴリズムは暗号学的に安全ではないことです。詳細に興味がある読者の方は、Yongge Want 氏と Tony Nicol 氏の『On statistical distance based testing of pseudo random sequences and experiments with PHP and Debian OpenSSL』のセクション 8.1 をご覧ください。バイナリ形式で考えた場合、「ランダム」シーケンスは 0 を返す可能性が高く、シードによってはさらにその傾向が強くなることが説明されています。

そのため、Android N では SHA1PRNG アルゴリズムと Crypto プロバイダの実装が廃止されます。数年前に公開された資格情報を安全に保存する暗号の使用という記事では、キー導出に SecureRandom を使用する際の問題が取り上げられています。しかし、この方法が継続的に使用されていることを考慮し、この問題を再検討することになりました。

このプロバイダは、パスワードをシードとして暗号化キーを導出するという誤った使われ方が一般的になっています。SHA1PRNG の実装には、出力を得る前に setSeed() を呼び出すとそれが固定されてしまうというバグがあります。パスワードをシードとし、「ランダム」な出力バイトを使用してキーを導出すると、このバグが発生します（この文で、カッコつきの「ランダム」は「予測可能で暗号学的に脆弱」という意味です）。そのようなキーがデータの暗号化や復号化に使われることになります。

次に、正しくキーを導出する方法と、安全ではないキーで暗号化されたデータを復号化する方法について説明します。廃止される SHA1PRNG 機能を使用するためのヘルパークラスを含む完全な例も掲載しています。これは、この方法を用いて復号化しなければ使うことができないデータを復号化することのみを目的としたものです。

キーは、次のように導出することができます。

• ディスク上の AES キーを読み出す場合は、ただ実際のキーを格納するだけで構いません。余計なことをする必要はまったくありません。AES 用の SecretKey は、次のようにしてバイト列から取得できます。
  SecretKey key = new SecretKeySpec(keyBytes, "AES");
  
• キーを導出するためにパスワードを使用している場合は、Nikolay Elenkov のすばらしいチュートリアルに従います。経験上、ソルトのサイズは出力されるキーのサイズとそろえておくとよいと言われていることに注意しましょう。以下は、一例です。

   /* User types in their password: */  
   String password = "password";  

   /* Store these things on disk used to derive key later: */  
   int iterationCount = 1000;  
   int saltLength = 32; // bytes; should be the same size
              as the output (256 / 8 = 32)  
   int keyLength = 256; // 256-bits for AES-256, 128-bits for AES-128, etc  
   byte[] salt; // Should be of saltLength  

   /* When first creating the key, obtain a salt with this: */  
   SecureRandom random = new SecureRandom();  
   byte[] salt = new byte[saltLength];  
   random.nextBytes(salt);  

   /* Use this to derive the key from the password: */  
   KeySpec keySpec = new PBEKeySpec(password.toCharArray(), salt,  
              iterationCount, keyLength);  
   SecretKeyFactory keyFactory = SecretKeyFactory  
              .getInstance("PBKDF2WithHmacSHA1");  
   byte[] keyBytes = keyFactory.generateSecret(keySpec).getEncoded();  
   SecretKey key = new SecretKeySpec(keyBytes, "AES");  

これだけです。他には何もする必要はありません。

データ移行を簡単にするために、毎回パスワードから導出される安全でないキーで暗号化されているデータへの対応方法も紹介します。キーは、サンプルアプリのヘルパークラス InsecureSHA1PRNGKeyDerivator を使って導出できます。

 private static SecretKey deriveKeyInsecurely(String password, int
 keySizeInBytes) {  
    byte[] passwordBytes = password.getBytes(StandardCharsets.US_ASCII);  
    return new SecretKeySpec(  
            InsecureSHA1PRNGKeyDerivator.deriveInsecureKey(  
                     passwordBytes, keySizeInBytes),  
            "AES");  
 }  

その後、先ほどの説明にあった安全に導出したキーを使ってデータを再暗号化すれば、あとはもう安心です。

注 1: アプリを動作させるための一時措置として、SDK バージョン 23（Marshmallow 用の SDK バージョン）以下を対象としたアプリでは、インスタンスを作成できるようになっています。Android SDK では、Crypto プロバイダの存在に依存しないようにしてください。これは今後完全に削除される予定となっています。

注 2: 多くのシステムで SHA1PRNG アルゴリズムの存在が前提とされているため、プロバイダを指定せずに SHA1PRNG インスタンスをリクエストした場合、OpenSSLRandom のインスタンスが返されるようになっています。これは OpenSSL に由来する安全な乱数ソースです。


Posted by Yuichi Araki - Developer Relations Team