Android 17 の 2 回目のベータ版で、Google は、多くの開発者や上級ユーザーが不安を持ちながらも注目していたセキュリティ対策を実装し始めました。
今日私たちが言及しているイノベーションは、いわゆる高度な保護モードに関するものです。これは、サイバー攻撃や有害なアプリに対するより強固な障壁を必要とするユーザー向けに Android 16 で導入された高度な保護モードであり、これにより、特定のアプリがシステム上で動作する方法が大幅に変更されます。
AccessibilityService API とは何ですか、またなぜそれが激戦区になっているのか
何が変化しているのかを理解するために、まず AccessibilityService API が障害を持つ人々がスマートフォンを操作できるようにすることを目的として作成されたことを思い出してください。したがって、たとえば、画面を読み上げるための代替入力システムやツールは、このインターフェイスに依存して、表示されたコンテンツを読み取って、ユーザーに代わってアクションを実行します。
問題は、この API をアクセシビリティにとって価値あるものにするのと同じ機能が、意図しない用途に対しても同様に魅力的なものにしてしまうことです。アクセシビリティ サービスにアクセスできるアプリは、画面に表示されるすべてのものを監視し、ユーザー インタラクションを記録し、ジェスチャを自動的に実行できます。
長年にわたり、多くの開発者はこの抜け穴を悪用し、自動化ツール、代替ランチャー、カスタマイズ アプリ、さらにはシステムへのこの特権アクセス ルートを広範囲に使用する一部の監視ユーティリティを通じて Android によって課せられた制限を回避してきました。
Beta 2 での変更点
ただし、ベータ 2 では状況が変わっているようです。高度な保護モードがアクティブな場合、実際、システムは、アクセシビリティ ツールとして正式に分類されていないアプリが関連するアクセス許可を取得することを防ぎます。アプリケーションが以前にそれらをすでに受信していた場合、Android はそれらを自動的に取り消します。また、モードが有効なままである限り、それらを再度付与することはできません。
この選択の影響を検証するために、Android 17 Beta 2 を搭載した Google Pixel 9a でいくつかのテストが実施されました。その結果、dynamicSpot のようなアプリは、フローティング ポップアップを表示するために必要なアクセシビリティ権限を取得できなくなっていることがわかりました。引き続き使用するための唯一の解決策は、高度な保護を無効にすることです。 Android 16 の安定バージョンを実行している同じデバイスでは、この問題は発生しませんでした。
いずれにせよ、Google はこの制限を自主的なものとして設定することを決定したことをお知らせします。したがって、高度な保護モードをアクティブにする人は、より制限の厳しいセキュリティ プロファイルを選択していることがわかります。悪意のあるアプリに対する保護を強化する代わりに、障害に関連しない機能にアクセシビリティ サービスを使用する一部のアプリケーションとの互換性を放棄することに同意するものとします。