Android13でも再現 …低いかもしれません。なぜなら、もし完全に画像化されているのであれば、タップして… UberEats掲示板 TIM掲示板

UberEats掲示板

No.1400 2025-08-17 18:28:03
タイトル	Android13でも再現
名前	ゆっくりしてってね
ド素人ですが、geminiに原因を聞いてみました --- 承知いたしました。Androidアプリ開発のパートナーとして、ご提示いただいた問題の根本原因の特定をサポートします。まず結論から申し上げますと、最も可能性が高い原因は「対象アプリのUI更新ロジックが変更され、ユーザー補助サービス（Accessibility Service）が変更を自動検知するためのイベント(AccessibilityEvent)が適切に発行されなくなった」ことだと考えられます。タップ時に読み上げが開始されるという事実は、この仮説を強く裏付ける重要な手がかりです。以下に、その理由と背景、そしてご推察の点も含めた他の可能性について、設計思想を交えながら体系的に解説します。なぜ「UI更新イベントの問題」が最有力なのか？ (Why) ユーザー補助サービスは、アプリの画面上で何かが起こったことをAccessibilityEventという通知を受け取ることで知覚し、動作を開始します。例えば、「ウィンドウの状態が変わった(TYPEWINDOWSTATECHANGED)」や「画面のコンテンツが変わった(TYPEWINDOWCONTENTCHANGED)」といったイベントです。以前のバージョンでは、配達依頼が表示された際に、対象アプリがこのイベントをシステムに発行していたため、貴社のアプリはそれを検知して自動的に読み上げを開始できていたのでしょう。しかし、今回のアップデートで、このイベントが発行されない、あるいは遅延して発行されるように変更された可能性が非常に高いです。【タップ時に動作する理由】ユーザーが画面をタップすると、その操作自体がTYPEVIEWCLICKEDやTYPEVIEWFOCUSEDといった、非常に強いトリガーとなるAccessibilityEventを発生させます。貴社のサービスがそのイベントをきっかけに改めて画面情報を走査するため、その時点で見えているテキスト情報を読み取ることができるのです。つまり、「情報自体は画面に存在しているが、その出現を自動で知る術が失われた状態」になっていると推測されます。この種の変更は、アプリのパフォーマンス最適化（不要なイベント発行の抑制）や、UI描画ライブラリの変更（例えば、標準ViewからCanvasへの直接描画への切り替えなど）によって発生することがあります。その他の可能性と原因の切り分けご推察の2点も、この問題を引き起こす要因として十分に考えられます。それぞれの可能性と、本質的な原因との関連性を解説します。 1. システムオーバーレイからBubblesへの移行これは非常に有力なシナリオの一つです。 * 設計思想 (Why): Android 11以降、GoogleはバックグラウンドからのUI表示に関して、よりOSが管理しやすく、ユーザー体験も統一されるBubbles APIを強く推奨しています。従来のシステムオーバーレイ (SYSTEMALERTWINDOW権限) は自由度が高い反面、他のアプリを完全に覆い隠してしまう「なりすまし」などのセキュリティリスクがありました。Bubblesは、通知と連携し、表示形式が統一されているため、より安全とされています。 * 技術的な影響 (How): Bubblesで表示されるUIは、独立した特殊なウィンドウとして扱われます。このウィンドウの状態変化やコンテンツ更新が、従来のオーバーレイ表示とは異なるAccessibilityEventを発行する、あるいはイベント発行のタイミングが異なる可能性があります。特に、ご提示の「最前面でない（アイコンのみ）」状態は、まさにBubbleが展開される前の状態であり、この状態遷移の管理方法が変更されたことが、イベント不発行の原因となっている可能性があります。 2. 文字から画像への変更これも可能性としては考えられます。 * 設計思想 (Why): アプリのブランディングを強化するために独自のフォントを使用したい場合や、動的なエフェクトを加えたい場合、あるいは情報のコピー＆ペーストを簡易的に防ぎたい場合に、テキストを画像（Bitmap）としてImageViewなどに描画することがあります。 * 技術的な影響 (How): ユーザー補助サービスは、TextViewなどのウィジェットが持つテキスト情報を直接取得します。もしこれが画像に変更された場合、原理的に文字を読み取ることはできません。 * ただし、この仮説の可能性はやや低いかもしれません。なぜなら、もし完全に画像化されているのであれば、タップしても読み上げは開始されないはずだからです（例外として、開発者がアクセシビリティ向上のためにcontentDescription属性に読み上げ用のテキストを設定している場合は読み上げられますが、その場合は最初から読み上げができる可能性が高いです）。 3. その他の技術的要因 * WebViewへの変更: アプリの一部がネイティブUIではなく、WebView（Webページを表示するコンポーネント）で描画されるように変更された可能性も考えられます。WebView内のコンテンツは、ネイティブUIとは異なるアクセシビリティのツリー構造を持つため、従来の方法では情報が取得できなくなることがあります。 * ウィンドウフラグの変更: パフォーマンス向上のため、フローティング表示されているウィンドウのフラグ（WindowManager.LayoutParams）が変更され、FLAGNOTFOCUSABLE（フォーカスを受け付けない）などが設定された可能性があります。これにより、ユーザー補助サービスがそのウィンドウをアクティブなものとして認識しづらくなっているのかもしれません。今後の具体的な調査・切り分け方法 (How to Investigate) 原因を特定するために、以下のステップで調査を進めることを提案します。これは、私たちが協力して問題の解像度を高めていくための共同作業です。 * UI構造の解析（最も確実な方法） * ツール: Android Studio の Layout Inspector * 目的: 問題が発生している画面のUIが、実際にどのようなコンポーネント（TextView, ImageView, WebViewなど）で構成されているかを確認します。 * 手順: * 実機をPCに接続し、問題の画面を表示させます。 * Android Studioで Layout Inspector を起動し、対象のプロセスにアタッチします。 * 表示されたUIツリーから、単価や店舗名が表示されている部分を選択し、そのプロパティ（text, contentDescription, class名など）を詳細に確認します。 <!-- end list --> * * 判断基準: * TextViewで、textプロパティに文字が入っている → UI更新イベントの問題が濃厚です。 * ImageViewになっている → 画像化が原因です。 * WebViewの中に表示されている → WebView対応の処理が必要です。 * アクセシビリティイベントの監視 * ツール: ご自身のユーザー補助サービスアプリ * 目的: 問題の画面が表示された際に、どのようなAccessibilityEventが、どのくらいの頻度で発生しているかを監視します。 * 手順: @Override public void onAccessibilityEvent(AccessibilityEvent event) { // イベントの種類を文字列に変換してログ出力 String eventType = AccessibilityEvent.eventTypeToString(event.getEventType()); Log.d("AccessibilityLog", "Event Received: " + eventType + ", Source: " + event.getSource()); // 本来の処理... } このコードをサービスに埋め込み、Logcatでログを監視します。配達依頼が表示された瞬間にTYPEWINDOWCONTENT_CHANGEDなどのイベントが発生しているかを確認してください。もし何も発生せず、タップした瞬間に多数のイベントが発生する場合は、仮説が正しいことの裏付けになります。これらの調査結果に応じて、具体的な対策（例えば、定期的に画面情報をポーリングする処理を追加する、特定のイベントを待たずに特定の条件下で能動的に情報を取得しにいくなど）を検討していくことになります。まずは上記の方法で情報収集を行ってみてください。その結果を教えていただければ、さらに具体的な次のステップを一緒に考えさせていただきます。