独占: Android 11 の最高の機能のうち 3 つはすべてのデバイスに搭載されるわけではありません

Xda限定Nov 09, 2023
click fraud protection

Android 11 の 3 つの優れた機能は、すべてのスマートフォンやタブレットに表示されるわけではありません。 Google がこれらの機能を義務付けているわけではないからです。

Google は毎年、Android オペレーティング システムの新しいバージョンをリリースします。 Google は 2 月に最初の Android 11 開発者プレビューをリリースし、その後、過去数か月間で 2 回目、3 回目、4 回目の開発者プレビューをリリースしました。 今月初め、Google は 最初の Android 11 ベータ版 ユーザーが楽しみ、開発者が実装するのに最適な機能について詳しく話し合いました。 ただし、Android 11 の主要な 3 つの機能がすべての Android デバイスで利用できるわけではないことがわかりました。

それがどのようにして可能なのかを理解するには、Android OS がどのようにして Google からスマートフォン デバイス メーカーに配布されるのかを簡単に説明する必要があります。 アンドロイドは、 オープンソースのオペレーティングシステム Apache 2.0 に基づいてライセンスされているため、インディーズ開発者から大企業に至るまで、誰でも自由に OS を変更して自分のデバイスに配布できます。 Google が Android 11 向けに発表した新しい OS 機能のほとんどは、Android オープンソース プロジェクト (AOSP) の一部になります。 デバイス メーカーは独自のソフトウェアをベースにしていますが、前に述べたように、Apache 2.0 ライセンスにより、誰でもソフトウェアを自由に変更できます。 フィット。 Android デバイス間で API とプラットフォームの動作の一貫性を維持するために、Google は Google モバイル サービスの配布をバンドルしています (これには、 Google Play ストアや Google Play サービスなどのアプリケーションやフレームワーク）と、デバイスが Google のルールに従うことを義務付けるライセンス契約 "Android 互換性プログラム」（他の要件の中でも特に）。 Android 互換性プログラムは、複数の自動テスト スイートと、Android で列挙された一連のルールで構成されます。 互換性定義文書 (CDD)。

CDD では、Google はデバイス メーカーが実装する必要がある、実装することが「強く推奨」される、または実装すべきではないソフトウェアとハ​​ードウェアの機能をリストしています。 機能が「実装しなければならない」とリストされている場合、デバイス メーカーはその機能を追加する必要があり、そうしないとデバイスに Google アプリを出荷できなくなります。 機能が「実装すべきではない」とリストされている場合、デバイス メーカーはその機能を追加できないか、Google アプリをバンドルできません。 最後に、機能が「強く推奨」としてリストされている場合、その機能を実装するかどうかはデバイス メーカーの判断になります。 CDD は、新しい Android バージョンの公開後に毎年公開される前であっても、常に変更されるドキュメントです。 Google は、パートナーからのフィードバックに基づいて機能を削除し、文言をより明確に変更し、要件を緩和するためにドキュメントを頻繁に更新します。 ただし、Google が特定の Android バージョンの CDD を公開すると、その Android OS バージョンを実行する Google 認定デバイスに対してこれらの要件が設定されることになります。

Android 11 CDD は今年後半、おそらく 9 月初旬まで公開されません。 ただし、開発者@削除スケープ CDD に加えられる変更の詳細を記載したドキュメントのプレリリース コピーを共有し、Google がエコシステム全体で Android 11 をどのように形成しているかを初期段階で確認できました。 CDD に対する 60 を超える変更の大部分は、ユーザーにとってあまり興味深いものではありません。 デバイス メーカーは、特定の API を実装し、特定の機能を宣言し、特定のカーネルを実装する必要があります 特徴。 ただし、CDD に対する 3 つの変更は、Android 11 の最も興味深い機能のいくつかに関連しているため、私たちの注目を集めました。 私たちが明らかにしたのは次のとおりです。

デバイスコントロール

デバイス コントロールは、スマート ホーム オートメーション コントロールを電源メニューに表示できるようにする Android 11 の機能です。 十数種類のスマート ホーム アプリを開かなくても、照明を消したり、ガレージのドアを開けたり、掃除機を動かしたり、家の温度を変更したりすることができます。 Google は、スマート ホーム アプリの開発者が電源メニューのコントロールを表示するために使用できる API を追加しました。 これは素晴らしい機能だと思います。 ついにスマートフォンをスマートホームに導入. 残念ながら、OEM が実際に実装する必要はありません。 OEM がその機能が不十分であると考えている場合、または別のルート (スマートのみを許可するなど) を進めたい場合 独自のエコシステム内のデバイスからのホーム コントロール)、デバイスのサポートを無効にするだけで済みます。 コントロール。

Google が 2020 年 2 月 25 日に初めてデバイス コントロールを CDD に追加したとき、セクション 2.2.3 - ハンドヘルド ソフトウェア要件に「MUST」要件を追加することでデバイス コントロールを含めることを義務付けました。 ただし、2020 年 5 月 20 日に Google は本文を更新し、提案されている「MUST」を削除しました。 新しいセクション 3.8.16 - デバイス コントロールでは、この機能の実装方法について概要が説明されていますが、実際には最初から実装する必要はありません。 OEM がこの気の利いた機能を無効にしないことを願っていますが、OEM が無効にしているかどうかは、OEM が無効にするまで知る方法がありません。 Android 11 上に構築された独自の Android を発表する準備ができています。発表は数か月後になります。 今。

提案されたセクション 3.8.16 (新規) - デバイス制御 (2020 年 5 月 20 日更新)

3.8.16 デバイスコントロール

Android には、ControlsProviderService と Control API が含まれており、開発者がデバイス コントロールを公開して、ユーザーに迅速なステータスとアクションを提供できるようにします。

3.8.16.1 デバイスによるユーザー アフォーダンスの制御

デバイスがデバイス コントロールを実装する場合、次のことが行われます。

  • [C-1-1] android.software.controls.feature フラグが TRUE であることを報告しなければなりません
  • [C-1-2] android.service.controls を通じてサードパーティ アプリによって登録されたコントロールからユーザーのお気に入りを追加、編集、選択、操作する機能をユーザー アフォーダンスに提供しなければなりません。 ControlsProviderService と android.service.controls。 制御 API。
  • [C-1-3] ランチャーから 3 回のインタラクション以内にこのユーザー アフォーダンスへのアクセスを提供しなければなりません
  • [C-1-4] このユーザー アフォーダンスでは、android.service.controls 経由でコントロールを提供する各サードパーティ アプリの名前とアイコンを正確にレンダリングしなければなりません。 ControlsProviderService API と、android.service.controls によって提供される指定されたアイコン、ステータス テキスト、デバイス タイプ、名前、構造、ゾーン、カスタム カラー、およびサブタイトル。 制御API

逆に、デバイス実装がそのようなコントロールを実装していない場合は、

  • [C-2-1] ControlsProviderService および Control API については Null を報告しなければなりません。

続きを読む

通知内の会話

Android 11 での会話。 出典: Google

iOS と比較した Android の最大の利点の 1 つは、前者が通知を処理する方法です。 Android 11では「会話」の導入により、その使いやすさの差はさらに広がることになる。 Android 11 では、通知 メッセージング アプリからのメッセージはグループ化され、通知パネルの別のセクションに他のほとんどのアプリの上に表示されます。 通知。 これにより、他のすべての保留中の通知をスクロールすることなく、メッセージをすばやく確認して応答できるようになります。 残念ながら、通知に対するこの気の利いた変更は、すべてのデバイスで利用できるわけではありません。 Google は OEM に対し、「事前に会話通知をグループ化して表示するかどうか」を選択するオプションを提供しています。 OEM は通知パネルを頻繁にカスタマイズしているため、Google が OEM に通知を提供するのは驚くことではありません。 ここでの選択。 それでも、Google が Android 11 で通知の一貫性を強化することを選択しないのは残念です。

セクション 3.8.3.1 に対する変更案 - 通知の表示 (2020 年 4 月 8 日更新)

デバイス実装でサードパーティ アプリが注目すべきイベントをユーザーに通知できるようにする場合、サードパーティ アプリは次のことを行います。

...

Android R では、NotificationManager を使用する通知である会話通知のサポートが導入されています。 MessageStyle を使用して、公開されたユーザー ショートカット ID を提供します。

デバイスの実装は次のとおりです。

  • [H-SR] 非会話の前に会話通知をグループ化して表示することが強く推奨されます。 進行中のフォアグラウンド サービス通知を除く通知と重要性: 高 通知。

会話通知が別のセクションにグループ化されている場合、デバイス実装

  • [H-1-8] 進行中のフォアグラウンド サービス通知と重要性が高い通知を除き、非会話通知よりも先に会話通知を表示しなければなりません。

デバイスの実装は次のとおりです。

  • [H-SR] 会話通知から次のアクションへのアクセスを提供することが強く推奨されます。アプリがバブルに必要なデータを提供する場合、この会話をバブルとして表示します。

AOSP 実装は、デフォルトのシステム UI、設定、ランチャーでこれらの要件を満たしています。

続きを読む

IdentityCredential - モバイル運転免許証

最後に、私が最も楽しみにしている機能の 1 つは、IdentityCredential API です。 昨年詳しく説明したように、IdentityCredential API は、アプリケーションがモバイル運転免許証などの身分証明書をデバイスに保存できるように設計されています。 世界中のいくつかの国 (および米国の一部の州) では、国民が運転免許証をモバイル アプリに保存することをすでに許可しています。 ただし、Google は、データを安全な環境にオフラインで保存することで、これをより安全にするよう取り組んでいます。

LA ウォレット アプリを通じてアクセスしたデジタル運転免許証のサンプル画像。 出典: エンヴォック

Android 11 のソース コードには、IdentityCredential API (開発者が電話機に ID ドキュメントを保存するために呼び出す) が含まれています。 セキュアな環境）と IdentityCredential HAL（電話のセキュアな環境とインターフェイスします）が含まれますが、OEM はこれを行う必要はありません。 それらを実装します。 Google が 2020 年 1 月 10 日に IdentityCredential を CDD に含めることを最初に提案したとき、それを要件としてリストしました。 ただし、2020 年 3 月 18 日にこの要件が緩和され、現在は OEM がこの機能をサポートすることのみを強く推奨しています。 Google がこの要件を緩和したことには驚きません。信頼された実行環境に影響を与える変更を追加するには、OEM による実装の努力が必要になります。 OEM がこの変更に対応するための準備にさらに時間が必要なだけである可能性があります。 ただし、ユーザーにとって、これは、特定の Android 11 スマートフォンが、携帯電話の安全な環境でのモバイル運転免許証の安全な保存をサポートする保証がないことを意味します。

Android 11 デバイス間での IdentityCredential システムの広範な採用を妨げる技術的な制限がないことに注意してください。 IdentityCredential システムを実装するための要件の 1 つは、デバイスに信頼できる実行機能があることです。 「信頼できるアプリケーション」が保存された ID と対話する環境 (TEE) または専用の安全なプロセッサ 書類。 Android 7.0 Nougat 以降、Google はすべての最新の Android デバイスに「分離実行環境」をサポートすることを要求しています（ セクション 2.2.5 - CDD のセキュリティ モデル). ARM プロセッサを搭載したデバイスには通常、ARM が搭載されています トラストゾーン TEE と Google が提供する 信頼できるOS TrustZone 上で実行されます。 TEE の存在は IdentityCredential システムをサポートするのに十分ですが、資格情報が組み込みのセキュア CPU (たとえば、 一部の Qualcomm Snapdragon プロセッサのセキュア プロセッシング ユニット) または個別のセキュア CPU (例: GoogleのTitan M または サムスンの新しいセキュリティチップ). 特に、個別のセキュア CPU を備えたデバイスは、IdentityCredential システムの「ダイレクト アクセス モード」機能もサポートできる場合があります。 これにより、メイン OS を起動するのに十分な電力がデバイスに残っていない場合でも、ユーザーは身分証明書を取得できるようになります。

提案されたセクション 9.11.3 (新規) - ID 認証情報 (2020 年 3 月 18 日更新)

ID 認証情報システムを使用すると、アプリ開発者はユーザー ID ドキュメントを保存および取得できます。

デバイスの実装:

  • [C-SR] ID 認証システムを実装することが強く推奨されます。

デバイス実装が ID 認証情報システムを実装する場合、次のことが行われます。

  • [C-0-1] に対して null 以外を返さなければなりません。 IdentityCredentialStore#getInstance() 方法。
  • [C-0-2] 信頼できるネットワークと通信するコードを使用して `android.security.identity.*` API を実装しなければなりません 信頼できる実行環境 (TEE) または専用のセキュアな環境で実行されるアプリケーション プロセッサー。 信頼できるアプリケーションは、次のように実装する必要があります。 トラステッド コンピューティング ベース ID 認証情報システムには Android オペレーティング システムは含まれません。

続きを読む

Google は、開発者が ID を安全に保存するためのサポートを簡単に追加できるようにする IdentityCredential Jetpack ライブラリにも取り組んでいます。 Android 上でドキュメントを保存できますが、本当の課題は、この API を使用して政府 ID を安全に保存するアプリを政府に承認させることです。 によると エンガジェット, 韓国は、モバイルアプリに運転免許証を保存するサポートを開始したばかりなので、このテクノロジーの受け入れが増え始めています。 私自身、外出時に持ち歩くものが一つ減るので、これがどうなるのか楽しみです。

私たちが入手した文書には、CDD への変更が変更が加えられた日付までにリストされていました。 最新の変更は 2020 年 6 月 10 日に行われたため、私たちが所有するドキュメントはかなり最新のものであることになります。 Google がこれらの変更を無視して、Android 11 の一般リリース前にすべての要件を再度作成する可能性はありますが、Google が突然 CDD を作成するとは思えません。 もっと 厳しい。 これらの変更は、予定されていなかった機能を元に戻して実装する必要がある OEM からのフィードバックにより緩和された可能性があります。 それには時間、労力、費用がかかり、Google 以外のデバイス向けの Android 11 のリリースがさらに遅れるだけです。 ただし、Google がこれらの機能を再度必須にする場合は、XDA ポータルに更新情報を投稿する予定です。