限定:Android 11の最高の機能のうち3つがすべてのデバイスで利用できるわけではありません

スポンサーリンク
未分類

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

それがどのように可能であるかを理解するには、Android OSがGoogleからスマートフォンデバイスメーカーにどのように配布されるかを簡単に説明する必要があります。 Androidは、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月上旬まで公開されません。 ただし、開発者@ deletescapeは、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 –ハンドヘルドソフトウェアの要件に「必須」の要件を追加することで、CDDの組み込みを義務付けました。 ただし、2020年5月20日、Googleは提案された「MUST」を削除するためにテキストを更新しました。 新しいセクション3.8.16 –デバイスコントロールでは、機能を実装する方法の概要を説明していますが、実際に機能を実装する必要はありません。 OEMがこの気の利いた機能を無効にしないことを願っていますが、Android 11の上に構築された独自のAndroidフレーバーを発表する準備ができるまで、無効にしたかどうかを知る方法はありません。今から数ヶ月。

スポンサーリンク

通知の会話

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

IdentityCredential –モバイル運転免許証

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

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つは、デバイスにTrusted Execution Environment(TEE)または「信頼できるアプリケーション」が格納されたIDドキュメントとやり取りする専用の安全なプロセッサを搭載していることです。 Android 7.0 Nougat以降、Googleはすべての最新のAndroidデバイスに「分離された実行環境」をサポートするように要求しています( セクション2.2.5 – CDDのセキュリティモデルによる )。 ARMプロセッサを搭載したデバイスは通常ARMのTrustZone TEEを備えており、GoogleはTrustZoneで実行されるTrusty OSを提供しています。 TEEの存在はIdentityCredentialシステムをサポートするのに十分ですが、資格情報が組み込みのセキュアCPU( 一部のQualcomm Snapdragonプロセッサのセキュアプロセッシングユニットなど )または個別のセキュアCPU(など)に格納されている場合は、より安全です。 GoogleのTitan MやSamsungの新しいセキュリティチップなど )。 特に、ディスクリートセキュアCPUを搭載したデバイスは、IdentityCredentialシステムの「ダイレクトアクセスモード」機能もサポートできる可能性があります。これにより、デバイスに十分な電力が残っていない場合でも、ユーザーはIDドキュメントをプルして起動できます。メインOSをアップ。

GoogleはIdentityCredential Jetpackライブラリにも取り組んでおり、開発者がAndroidにIDドキュメントを安全に保存するためのサポートを簡単に追加できるようにしますが、実際の課題は、政府がこのAPIを使用してアプリを承認し、政府IDを安全に保存できるようにすることです。 Engadgetによると、韓国はモバイルアプリに運転免許証を保存するためのサポートを展開したばかりなので、このテクノロジーが受け入れられるようになっています。 私が1つは、これがどこに行くのかを見て興奮しています。これは、外に出るときに持ち運ぶ必要が1つ減ることになるからです。


私たちが入手した文書には、それらの変更が行われた日付までにCDDに対する変更がリストされています。 最新の変更は2020年6月10日に行われました。つまり、私たちが持っているドキュメントはかなり最新のものです。 Android 11の一般公開前に、Googleがこれらの変更を無視してすべての要件を再度作成する可能性はありますが、Googleが突然CDDをより厳格化することはないと思われます。 これらの変更は、OEMからのフィードバックが原因で緩和された可能性があります。OEMは、計画を立てていなかった場合に戻ってこれらの機能を実装する必要があります。 これには時間、労力、お金がかかり、Google以外のデバイス向けのAndroid 11のリリースがさらに遅れるだけです。 それでも、Googleがこれらの機能をもう一度必要とする場合は、XDAポータルにアップデートを投稿します。

タイトルとURLをコピーしました