Android 11 AMA: スクリーンショットのスクロールなし、アプリの起動の高速化など

click fraud protection

Google の Android エンジニアリング チームは、Android 11 に関する質問に答えるために Reddit で AMA を主催しました。 次の Android OS バージョンについてわかったことは次のとおりです。

昨日、Googleがリリースした Android 11 ベータ 2、完成した SDK、NDK、アプリ向けサーフェス、プラットフォームの動作、および非 SDK インターフェイスの制限を開発者に提供します。 本日、Google は Reddit の /r/AndroidDev コミュニティで Android 11 に関連する質問に回答しています 先週の質問対応後. Google の AMA (Ask Me Anything) から学んだすべての概要を以下に示します。

Android 11 の最も期待されている機能の 1 つは、OS が次の場合には利用できなくなります。 ベータ版は 9 月 8 日に終了します: スクリーンショットをスクロールします。 最初は Android 11でリリース予定, Googleは現在、この機能が「Rには適していなかった」ことを認めた。 Android 11 開発者プレビュー 1 および 後続のすべての DP およびベータ リリースには、スクロール スクリーンショットを撮るためのプレースホルダー ボタンがあります。 隠し開発者コマンドを使用して手動で表示される, ただし、ボタンをタップすると、機能が「実装されていない」ことを示すトースト メッセージが表示されるだけです。

Android 11 の未実装のスクロール スクリーンショット ボタン。

私たちはこの機能がベータ版、あるいは安定版リリースに移行することを期待していましたが、どうやらそれは実現しないようです。

コメント 議論から。 私たちは Android エンジニアリング チームに所属しています。 Android プラットフォームの Android 11 アップデートについて何でもお問い合わせください。 (7月9日スタート).

このニュースは当然、一部のユーザーを動揺させるでしょう。 結局のところ、多くの OEM は何年も自社のソフトウェアにこの機能を搭載してきたのに、Google がこの機能を Pixel スマートフォンに追加するのになぜそんなに時間がかかったのでしょうか? Google のシステム UI チームの Dan Sandler 氏が説明したように、問題は Google が正しくやりたいと考えていることです。 一部のスクロール スクリーンショットの実装では、単純にスクロールをエミュレートし、画面の移動に合わせて複数のスクリーンショットをつなぎ合わせます。 Android で UI オートメーションを扱ったことがある人なら、これが常に機能するとは限らないことをご存知でしょう。サンドラー氏が言及したように、アプリは 「沼地標準の RecyclerView を使用するか、独自の OpenGL アクセラレーション スクロール エンジンを実装している」ことができます。 Google が計画しているので、 この機能を Pixel スマートフォンだけでなく、AOSP の一部として Android エコシステム全体に実装するには、次のことを確認する必要があります。 それはうまくいきます 

全て 「特定のデバイス上で厳選された 1 つまたは 2 つのアプリ」だけではありません。

特にもたらされた課題のために、チームは「限られたリソースを集中」する必要があったため 新型コロナウイルス感染症の影響で、チームは将来の Android リリースに備えてスクロール スクリーンショットを後回しにすることにしました。

バックグラウンド制限をユーザーに通知するための新しい CDD 要件

多くの Android OEM、特に中国の OEM が、バックグラウンドで実行されるアプリに対して厳しい制限を設けていることは周知の事実です。 一部の開発者は、アプリがバックグラウンドで強制終了されることに非常に不満を感じ、団結して「」という Web サイトを作成しました。私のアプリを殺さないでください」は、バックグラウンド アプリ プロセスの処理能力に基づいて OEM をランク付けします。 同じ開発者 最近でもベンチマークを作成しました そのため、ユーザーはデバイスがバックグラウンドでアプリをどれだけ積極的に強制終了するかをテストできます。 多くの OEM がバックグラウンド アプリ プロセスを強制終了することを好む理由は複雑ですが、Redditor /u/ によるこのコメントが最もよく説明されていると思います。おそらく疑わしい. このコメントは、中国における Android アプリ開発の複雑な状況、中国のテクノロジー企業がどのように開発しているかを概説しています。 事態がさら​​に複雑化していることや、Google サービスの欠如が進行中の問題にどのように寄与しているか 混乱。

いずれにせよ、多くのアプリ開発者が Android プラットフォームの動作に対するこうした調整に不満を感じているのは当然であり、開発者がコメントをプッシュする結果となっています。 Googleにそれについて何をしているのか尋ねる Reddit AMAのトップに。 Google の返答は次のとおりです。

コメント 議論から。 私たちは Android エンジニアリング チームに所属しています。 Android プラットフォームの Android 11 アップデートについて何でもお問い合わせください。 (7月9日スタート).

この回答から得られることがいくつかあります。 まず Google は、OEM が適用しているバックグラウンド アプリの制限について、ユーザーに対してより透明性を高めることを望んでいます。 (未リリースの) Android 11 互換性定義ドキュメント (CDD) を確認したところ、セクション 3.5 - API 動作の互換性への次の追加案が見つかりました。

デバイス実装がアプリを制限する独自のメカニズムを実装しており、そのメカニズムが AOSP の「レア」スタンバイ バケットよりも制限が厳しい場合、デバイス実装は:

[C-1-5] アプリ制限がアプリに自動的に適用される場合は、ユーザーに通知しなければなりません。 (新規) かかる情報は、かかる制限が適用される 24 時間より前に提供してはなりません。

(注) 強制停止は「レア」よりも制限が厳しいと考えられており、新しい 3.5.1/C-1-5 を含む 3.5.1 に基づくすべての要件に準拠する必要があります。

基本的に、Google は OEM が独自の制限的なアプリ強制終了機能を実装するのを阻止するつもりはありません。 OEM がアプリの制限が自動的に適用されるかどうかをユーザーに通知することだけを要求しています。 OEM は、バッテリーを消費するバックグラウンド アプリの実行を停止するというダイアログを表示する可能性があります。 バックグラウンドで実行したいアプリもユーザーがバックグラウンドで実行したいと気付かずに同意する可能性があります。 影響を受ける! Googleは、アプリがバックグラウンドで予期せず終了した場合に対処する責任を開発者に課している。 実際、Reddit のコメントでは、新しい「」を強調しています。アプリプロセスの終了理由" アプリがユーザーによって強制終了されたのか、OS によって強制終了されたのか、それとも単にクラッシュしたのかを開発者に伝えることができる API。

その一方で、Googleはついに、OEMが特定の特権アプリケーションにバックグラウンドアプリの制限を回避することを許可する不公平な慣行に対処しようとしている。 開発者によるこのメディア投稿 ティモシー・アシムウェ WhatsApp、Facebook、その他のアプリが一部の OEM ソフトウェアの厳しいバックグラウンド制限から自動的に免除されることについて詳しく説明します。 Googleは「デバイスメーカーに対し、上位アプリの許可リストを作成しないことを要求している」としている。 これがどのように施行されるかはわかりませんが、 OEM は最終的に、アプリの大小に関係なく、サードパーティの開発者を同等の立場で扱うことを余儀なくされることを知るのは良いことです。 は。

最後に、Google は Android 11 が「不正な動作をするアプリによる不正行為を防止するための追加の対策を追加」したことで、OEM がバックグラウンド プロセスを積極的に強制終了する魅力を減らしたことにも言及しています。 しかし同社は、これらの「追加措置」が何を意味するかについては詳しく述べなかった。

デバイス間のバックアップの改善

先月、Android 11 のドキュメントに対する変更を発見しました。 より優れたローカル データ バックアップのサポートを示唆. Android 11 では、ユーザーがアプリ ファイルの「デバイス間」移行を開始すると、システムは API レベル 30 をターゲットとするアプリのallowBackup マニフェスト属性を無視します。 Google社員のエリオット・ストック氏は、この機能は「サムスンの優れたスマートスイッチ製品」などの「携帯電話メーカーがデバイス間の移行ツールを構築することをはるかに容易にする」ことを目的としていると述べた。 「ユーザーの観点から、アプリがデバイス間でより確実に転送できるようにする」のに役立ちます。 残念ながら、これはクラウドベースのバックアップには当てはまらない。Googleは「ソフトウェア開発者に何を制御できるようにしたい」と考えているからだ。 そのため、Android 11 では、Google Play サービスの組み込み Google ドライブなどを介したクラウドベースのバックアップと復元については、引き続きallowBackup 属性が尊重されます。 バックアップ。 最後に、Google は、一部の開発者にとって、アプリあたり 25MB のバックアップ上限では十分ではない可能性があることを認めており、それを解決する方法を検討しているとのことです。 ただし、PC へのローカル バックアップは検討されておらず、Google は次の計画を繰り返しています。 adbバックアップを段階的に廃止する 将来の Android リリースで。

コメント 議論から。 私たちは Android エンジニアリング チームに所属しています。 Android プラットフォームの Android 11 アップデートについて何でもお問い合わせください。 (7月9日スタート).

開発者は、スムーズなデータ移行方法を実装することが推奨されます。 の 新しいブロックストアライブラリは、Google Identity Services Library の一部であり、復元されたアプリへのログインを容易にするように設計されています。 新しいデバイスではクラウドから実行できますが、これを実装するかどうかは開発者が選択します。 図書館。

I/O 先読みプロセス (IORap) によるアプリの起動速度の高速化

Google は常に Android のパフォーマンスを向上させる方法を実験しています。 Android 10 で追加されたあまり知られていない機能の 1 つは、Unspecialized App Process Pool (USAP) と呼ばれます。 この機能により、アプリの起動プロセス中に Zygote をフォークすることがなくなり、Pixel 2 デバイスでのアプリの平均起動速度が約 5 ミリ秒短縮されます。 この機能は現在、 AOSP ではデフォルトで無効になっていますとGoogleは、追加されたメモリ使用量についてはまだテストが必要であると説明している。 ただし、さらに興味深いのは、Android 11 に導入される I/O 先読みプロセス (I/O Read Ahead Process) と呼ばれる新機能です。IORap). Googleによると, この機能により、「コールド スタートアップが 5% 以上高速になり、ヒーロー ケースでは 20% の高速化」が実現します。 この機能 アプリの起動を促進するために、「起動プロセス中にアプリケーションのアーティファクト (コードやリソースなど) をプリフェッチします」 スピード。

Googleはまた、「ブートクラスパスとシステムイメージを最適化するために使用されるプロファイルを改善しました」 これにより、アプリのパフォーマンスが向上し、システムに関連するメモリとストレージのコストが削減されます。 人工物。 これらの変更は主に、より多くの RAM を搭載したデバイスに恩恵をもたらしますが、Google は最大のメリットが得られる限界値については明らかにしていません。

Android 11 の対象範囲付きストレージの変更 - /Downloads へのアクセスが制限されているのはなぜですか?

Android 11 をターゲットとし、ACTION_OPEN_DOCUMENT_TREE インテントを使用して外部の特定のディレクトリへのアクセスを要求するアプリ ストレージはユーザーに外部ストレージのルート ディレクトリ (/data/media/{user}) へのアクセスを要求できなくなります。 ディレクトリ (/data/media{user}/Download)、または外部ストレージ上のアプリ固有のデータ ディレクトリ (/Android/data または /Android/obb). ダウンロード ディレクトリへのアクセスが制限されているのはなぜですか? Googleによると ロクサーナ・アリアバディ, それは、ダウンロードフォルダーが「個人情報が含まれる危険性が最も高い」からです。 例として、税金をダウンロードするユーザーは、 返品や銀行取引明細書では、アプリが継続的な読み取りアクセスを悪用する可能性を心配する必要はありません。 ディレクトリ。 Google によると、ドキュメント ピッカーには「Android が特定のフォルダーを制限していることを示す更新されたテキスト」が表示される予定です これにより、アプリに特定のディレクトリへのアクセスを許可できない理由についての混乱が軽減されることが期待されます。 もう。

今後の対象範囲付きストレージと再生ポリシーの変更の詳細については、以下をご覧ください。 この記事を参照してください.

その他のトピック

  • root化/改造に対するGoogleのスタンス
    • Google の AOSP チームの Jeff Bailey 氏は、選択をサポートするという同社のスタンスを繰り返し述べています。 Googleは「Pixelシリーズのデバイスの改造/root化が可能であることを保証し続ける」が、「自社のデバイスを許可しないというOEMの選択もサポートする」としている。 さらに、Google は、最近の変更点を考慮して、ソフトウェア開発者に「ソフトウェアを root 化されたデバイスで実行させない」という選択肢を与えています。 SafetyNet Attestation APIのソフトウェア改ざん検出.
  • 「開いてデフォルトに設定」はどうなったのでしょうか?
    • Android10になりました アプリをデフォルトのハンドラーとして設定するのは少し面倒です 特定のリンクについては、これはユーザーを「搾取的なアプリ」から保護するために行われたとGoogleは述べている。 Googleは撤退した この変更については再考した上で、ユーザーを保護するために「舞台裏で多数の変更」を加えました。
  • Vulkan Graphics API を使用して UI をレンダリングしますか?
    • Googleは最終的には使用する予定 UI をレンダリングするための Vulkan Graphics APIこれにより、パフォーマンスがいくらか向上します。 これは まだ評価中です、しかし、同社は共有する詳細を持っていませんでした。
  • 多くのデバイスで CallScreeningService が欠落している
    • Android アプリで実装できるのは、 CallScreeningService API 新しい着信および発信通話を傍受し、発信者を識別して通話を受け入れるか拒否できるようにします。 これは公式に文書化された API ですが、開発者 /u/ によると、これを適切に実装していない OEM が多数あるようです。_ゼロモッド_. グーグル 確認します この API は、Android 互換性があるとみなされるためにすべてのデバイスが合格する必要がある自動テスト スイートである互換性テスト スイート (CTS) によって検証されていることを確認します。 何らかの理由で、この API は、Huawei、Vivo、Xiaomi、Samsung などの OEM のデバイスで呼び出されると null を返すため、これらの OEM のソフトウェアにバグがある可能性があります。
  • オーディオプラグインフレームワークの予定はない
    • 開発者は Google に、Apple の Audio Units のようなオーディオ プラグイン フレームワークを実装する予定があるかどうか尋ねましたが、 答え それは近い将来に起こる可能性は低いということです。

Android エンジニアリング チームからのすべての回答を読むことができます ここ。 チームは、いくつかのコメントで Java、Kotlin、Android ビルド システム、CameraX API、およびその他のトピックについて少し話しています。 Wear OS、Android TV、Android Auto に関するコメントもいくつかありますが、Google は主に次のことを繰り返しています。 これらのプラットフォームでの既存の作業について説明し、開発者に対し、開発期間中はさらなる情報に注目するよう伝えています。 "電話を超えた Android8月10日から始まる「ウィーク」。