トリアージのガイドライン
アプリに関連する問題とOSに関連する問題を切り分けるには、外部ビルドで問題をテストすることが不可欠です。さまざまなビルドでアプリの動作を調べることで、根本原因がアプリコードにあるか、それともオペレーティングシステム自体にあるかを効果的に特定できます。この体系的なアプローチにより、問題の正確な特定と的を絞った解決が可能になり、トラブルシューティングとデバッグのプロセスの効率を高めることができます。
アプリの問題のトラブルシューティングを行う場合、開発者は、効果的な診断方法としてバージョンの比較を使用できます。同じアプリビルドを実行しているとき、複数のOSで一貫して問題が発生する場合は、アプリコードかその依存関係に根本的な原因があることが一般的です。反対に、特定のOSバージョンでのみ問題が発生し、ほかのバージョンでは正常に動作する場合は、OSの互換性の問題が存在すると考えられ、アプリ側で特定の処理が必要になることがあります。この比較テスト方法により、開発者は、アプリコードのデバッグに焦点を当てるべきか、OS固有の互換性要件を調査すべるべきかを効率的に判断でき、最終的により的確な問題解決につなげることができます。
以下では、アプリ側の問題と呼ばれるシナリオについて説明します。
ANRクラッシュ
アプリ応答なし（ANR）でのクラッシュは通常、アプリに関連する問題であり、アプリがライフサイクルマネージャー（LCM）またはシステムコールに応答しない場合に発生します。この場合、LCMは応答しないアプリを強制的に終了します。ANRをトリガーし、アプリの終了を引き起こすような特定のシナリオはいくつかあります。
ANRレポートの解釈
アプリプロセスでANRが発生した場合、まず確認するべきフィールドは「LCM_ANR_REASON」フィールドです。名前から推測されるとおり、このフィールドはプロセスがANRになった理由を示します。以下に、返される可能性のある理由を詳しく説明します。
| LCM_ANR_REASON | 説明 | 追加のメタデータ | 出力の例 |
|---|---|---|---|
| Lifecycle Callback | アプリの状態が変更されると、LCMは、新しい状態についてアプリに通知するコールバックをトリガーします（「onForeground」など）。アプリには、新しいコールバックの受信を妨げないように、これらの遷移から即座に戻ることが求められます。 | "LCM_APP_TRANSITION" - どのコンポーネントのライフサイクル遷移がANRを引き起こしたかと、どのような遷移だったかを示します。 | LCM_APP_TRANSITION: appInst[20]: FOREGROUND transition |
| Display Input Event | 対話型コンポーネントは、タッチイベント、ポインターイベント、キーボードイベントなど、ユーザーからの入力イベントを処理するように登録できます。これらのイベントを非同期的に処理する場合は、イベントの処理時に確認を送信する必要があります。アプリが一定時間内に確認を返さなかった場合、そのアプリは応答していないと見なされ、終了されることになります。一部のグラフィックユーティリティは、アプリに代わって入力の確認を処理する場合があることに注意してください。 | 該当なし | |
| Thread Monitor | LCMには、登録されたスレッドをモニタリングし、いずれかのスレッドが応答しなくなった場合にアプリを終了する「スレッドモニター」というユーティリティが用意されています。デフォルトではすべてのアプリのメインスレッドがモニタリングされますが、「スレッドウォッチドッグ」を使用して追加のスレッドをモニタリングすることもできます。 | "LCM_ANR_THREAD_NAME" - ANRになったスレッドが名前付きで登録されていた場合、このフィールドに登録名が示されます。 | LCM_ANR_THREAD_NAME: MyThread |
| Task Execution Limits Exceeded | タスクがタスクマネージャーによって起動された場合、そのタスクには、バックグラウンドで処理を完了するまでに10分の時間が与えられます。このしきい値を超えたタスクは強制終了されます。これはタスクマネージャーによって起動されたタスクにのみ適用されます。 | "TASK_MANAGER_COMPONENT_ID" - 強制終了されたタスクのコンポーネントID。 "TASK_MANAGER_TASK_ID" - 強制終了されたタスクのワークID。 "TASK_MANAGER_TASK_NAME" - 強制終了されたタスクのオプションの名前。 |
TASK_MANAGER_COMPONENT_ID: com.amazon.appfwk.test.tm.task TASK_MANAGER_TASK_ID: 1047 TASK_MANAGER_TASK_NAME: triggerExecutionLimits |
アプリが応答なし（ANR）で強制終了された場合
システムで実行されているすべてのアプリが正常に動作していて、アクティブにコントラクトに従っていることを確認するために、システムのさまざまなサービスがアプリの応答性を追跡しています。これらのサービスは、アプリが無応答になったと判断すると、プロセスを強制終了するようにLCMに要求します。以下は、ANRにつながる可能性のあるイベントの一覧です。デフォルトのタイムアウト時間は、プロファイル、プラットフォーム、製品の構成によってオーバーライドされる可能性があるため、アプリが従う必要のあるタイムアウト時間と同じになるとは限らないことに注意してください。
| ANRの原因 | ソース | ANRへの遷移の説明 | デフォルトのタイムアウト時間 |
|---|---|---|---|
| アプリが遷移コールバックから戻らない | LCM | アプリの状態が変更されると、LCMは、新しい状態についてアプリに通知するコールバックをトリガーします（「onForeground」など）。アプリには、新しいコールバックの受信を妨げないように、これらの遷移から即座に戻ることが求められます。 | 8秒 |
| 対話型アプリがフォアグラウンドでサーフェスを作成しない | LCM/DisplayServer | すべての対話型アプリは、フォアグラウンドにあるときにサーフェスを作成するものと想定されています。DisplayStackにコンポーネントが追加されると、DisplayServerからLCMに通知が送信され、そのコンポーネントはユーザーに表示されているとマークされます。 | 12秒 |
| アプリが時間内に入力に応答しない | DisplayServer | フォアグラウンドにあるアプリがタッチ入力に応答しない場合、GWSIはタッチANRをモニタリングし、LCMを通じて報告します。 | GWSIにより決定 |
| アプリのメインスレッドが上記以外の理由で応答しない | アプリスレッドモニター | メインスレッドが過剰にブロッキングしているか、メインスレッドでデッドロックが発生しています。これはデバイスごとに条件に応じて有効になります。 | 45秒 |
| アプリのJSスレッドが応答しない | アプリスレッドモニター | JSスレッドが過剰にブロッキングしているか、JSスレッドでデッドロックが発生しています。 | VSにより決定（8秒） |
これらのデータを使用して、上記の情報をアプリチームに説明し、LCM_ANR_REASONに従ってアプリチームに解決策を推奨する必要があります。
JS例外
通常、JavaScript（JS）例外はアプリから発生し、journaldログに記録されます。問題を調査するときは、JS例外を、報告された問題のタイムスタンプと再現手順に関連付けることが重要です。JS例外の中には、さまざまな要因によってランダムにログに表示されるものもありますが、特定の問題の発生期間と同じタイミングで例外が見つかる場合は、OSレベルの問題ではなくアプリ側の問題であることを強く示唆しています。致命的な例外に伴ってJSErrorが発生していて、その後クラッシュする場合は、アプリのメソッドが例外をスローしています。
メディアコントロールボタンが機能しない
ビデオの再生中にリモコンのメディアコントロールキー（再生、一時停止、早送り／早戻しなど）が機能しない場合は、ログの分析が重要になります。詳しい調査では通常、2つの側面に焦点を当てます。つまり、リモコンのキー押下イベントがアプリに正しく届いているかどうかを検証し、これらのイベントに対してアプリが正常に確認を返しているかどうかを確かめます。この系統的なチェックにより、通信チェーンがどこで遮断されているかを特定できます。
ただし、アプリ開発者が参照できるのはアプリの確認のログだけです。
入力ログ
~~Jul 14 12:50:38.950438 firestick-3193544e8fbc4619 inputd[1702]: I Inputd:accept:189: Display Power Resource Acquired in response to Key Event [KEY_FASTFORWARD]: Took 0.010ms
Jul 14 12:50:38.950856 firestick-3193544e8fbc4619 inputd[1702]: I Inputd:sendKeyToClient:2300: sending key to passthrough-capable client: id=17 pid=2564 prio=HIGHEST_PRIORITY_OBSERVER: TimeStamp=1752497438.950153 : keyType=EV_KEY : keyCode=[KEY_FASTFORWARD] : state=down
Jul 14 12:50:38.950978 firestick-3193544e8fbc4619 inputd[1702]: I Inputd:sendKeyToClient:2300: sending key to passthrough-capable client: id=5 pid=1231 prio=TIMEOUT_MANAGER_PRIORITY: TimeStamp=1752497438.950153 : keyType=EV_KEY : keyCode=[KEY_FASTFORWARD] : state=down
Jul 14 12:50:38.951094 firestick-3193544e8fbc4619 inputd[1702]: I Inputd:sendKeyToClient:2300: sending key to passthrough-capable client: id=22 pid=2440 prio=USAGE_STATS_PRIORITY: TimeStamp=1752497438.950153 : keyType=EV_KEY : keyCode=[KEY_FASTFORWARD] : state=down
Jul 14 12:50:38.951206 firestick-3193544e8fbc4619 inputd[1702]: I Inputd:sendKeyToClient:2300: sending key to passthrough-capable client: id=19 pid=2008 prio=PUFFIN_OBSERVER_PRIORITY: TimeStamp=1752497438.950153 : keyType=EV_KEY : keyCode=[KEY_FASTFORWARD] : state=down
Jul 14 12:50:38.951306 firestick-3193544e8fbc4619 inputd[1702]: I Inputd:sendKeyEvent:2389: id 65 is registered for key event device injection intercept, injecting [KEY_FASTFORWARD] to the original input device
Jul 14 12:50:38.951508 firestick-3193544e8fbc4619 inputd[1702]: I Inputd:~~~~inject_ke~~y:385: Input event successfully written to udev: TimeStamp=1752497438.950153 : keyType=EV_KEY : keyCode=[KEY_FASTFORWARD] : state=down
アプリの確認ログ
Jul 14 12:50:38.951859 firestick-3193544e8fbc4619 layer.androidtv[22766]: I GWSI_LOG:KB key:XF86AudioForward state:1 evtId:42
Jul 14 12:50:39.211834 firestick-3193544e8fbc4619 layer.androidtv[22766]: I GWSI_LOG:KB key:XF86AudioForward state:0 evtId:43
アプリの確認ログでリモコンからの入力を受信していることが確認されても、想定されたアクションが実行されない場合は、アプリ側に問題があると考えられます。アプリはこれらのキーイベントを受信していますが、正しく処理していません。また、アプリがVegaMediaControl（KMC）を実装している場合は、KMCハンドラーのログにさらなる根拠が示される可能性があります。必要なKMCメソッドがアプリに正しく実装されていないと、ボタンが押されるたびにログに「未定義のキーイベント」が記録されます。
KMCの呼び出し時にAlexaが一時停止／再生／早送り／早戻しに関連する処理を行っている場合、KMCに情報を渡すには、KSM（VegaSpeechModule）が確認を行う必要があります。
KMCの未定義のボタンイベントのログ
Jul 11 09:29:20.821184 firestick-82bf81af994b24a7 local0.info layer.androidtv[10448]: 20 I Volta:[KeplerScript-JavaScript] mitxp[KIKAPLAYER][KMC-handler] - handlePlayPause (undefined)
Jul 11 09:29:10.117873 firestick-82bf81af994b24a7 local0.info layer.androidtv[10448]: 20 I Volta:[KeplerScript-JavaScript] mitxp[KIKAPLAYER][KMC-handler] - handleRewind (undefined)
Jul 11 09:29:10.663667 firestick-82bf81af994b24a7 local0.info layer.androidtv[10448]: 20 I Volta:[KeplerScript-JavaScript] mitxp[KIKAPLAYER][KMC-handler] - handleFastForward (undefined)
ナビゲーションが機能しない
これは、上で説明したメディアコントロールボタンの問題と同じです。調査では、リモコンのキー押下イベントがアプリに正しく届いているかどうかを検証し、これらのイベントに対してアプリが正常に確認を返しているかどうかを確かめるという、2つの側面に焦点を当てる必要があります。この系統的なチェックにより、通信チェーンがどこで遮断されているかを特定できます。アプリ開発者は入力ログにはアクセスできませんが、ボタンイベントに対するアプリの確認を調べることはできます。アプリがボタンイベントの確認を受け取っている場合、リモコンからのナビゲーションイベントは届いていると考えられます。アプリ側で第1レベルのトリアージを実行して、アプリの実装に問題がないかどうかを確認する必要があります。
VoiceViewが機能しない
VoiceViewが機能せず、ユーザーレポートの値が読み上げられない場合は、UCCツリーを調べて、ユーザー補助機能で読み上げる説明がラベルに設定されているかどうかを確認することをお勧めします。VegaスクリプトとWebViewアプリ向けのリンクを以下に示します。
UIの切り詰め／UIフォーカスの問題
ユーザーインターフェイス（UI）が切り詰められる場合は、アプリに関連する問題であることがほとんどです。UI要素のレンダリングはアプリが制御するためです。この問題は、タブ、メニュー、サブメニュー内のコンポーネントの一部が欠けたり、フィールドが空になったりする症状として現れます。UIオブジェクトのレンダリングとレイアウトの実装を検査するために、アプリチームによる調査が必要です。これはUI／フォーカス関連の問題であるため、一般に、この問題に関する情報がオペレーティングシステムのログに含まれることはありません。
オーディオ関連の問題
オーディオの損失／オーバーラップの問題
アプリがオーディオフォーカスを取得せずにオーディオを書き込もうとすると、「Would Block」というエラーがアプリに返されます。この場合、アプリの観点から、必要なフォーカスセッションを取得できなかった理由に優先順位を付ける必要があります。
E AudioStream_VNTK:writeBuffer:180 failed Would Block
オーディオリークの問題
アプリのフォーカスが一時停止され、その状態で書き込みに失敗した後、アプリが異常な状態になります。
audioFocusの分析
/// ABPがメディアオーディオフォーカスを取得します。
Jan 03 06:31:32.736009 firestick-74357a7ea4ea1145 mixer[841]: 12236 I AudioControlService: requestAudioFocus(): pid=11411, sessionId=44
Jan 03 06:31:32.736033 firestick-74357a7ea4ea1145 mixer[841]: 12236 I AudioFocusStack: requestAudioFocus(): pid=11411, sessionId=44, life=2, request=1, flag=2, type=media, usage=media
Jan 03 06:31:32.736711 firestick-74357a7ea4ea1145 mixer[841]: 12236 I AudioFocusRecordState: handleAudioFocusGained(): pid 11411 session 44 moving from state [init] to [granted]
/// マイクボタンが押されました。
Jan 03 06:31:49.516182 firestick-74357a7ea4ea1145 PuffinApp[1565]: I PuffinApp:[12d] VegaBluetoothKeyEventObserver:startSconeMicStreaming::scone mic button pressed
/// PuffinAppが音声認識フォーカスを取得するため、ABPのメディアフォーカスは一時停止されます。
Jan 03 06:31:49.555699 firestick-74357a7ea4ea1145 mixer[841]: 12236 I AudioControlService: requestAudioFocus(): pid=1565, sessionId=11
Jan 03 06:31:49.555723 firestick-74357a7ea4ea1145 mixer[841]: 12236 I AudioFocusStack: requestAudioFocus(): pid=1565, sessionId=11, life=0, request=0, flag=0, type=voice recognition, usage=voice recognition
/// ABPのメディアフォーカスが一時停止されます。
Jan 03 06:31:49.556032 firestick-74357a7ea4ea1145 mixer[841]: 12236 I AudioFocusRecordState: handleAudioFocusLost(): pid 11411 session 44 moving from state [paused] to [paused]
/// PuffinAppに音声認識フォーカスが移行します。
Jan 03 06:31:49.555045 firestick-74357a7ea4ea1145 PuffinApp[1565]: I PuffinApp:[e:4b] AudioFocusIntegration:acquireFocus:focusRequestId=Dialog
Jan 03 06:31:49.607146 firestick-74357a7ea4ea1145 mixer[841]: 12236 I AudioFocusRecordState: handleAudioFocusGained(): pid 1565 session 11 moving from state [init] to [granted]
Jan 03 06:31:49.608561 firestick-74357a7ea4ea1145 PuffinApp[1565]: 2875 I AudioManagerAipc: dispatchAudioFocusEventCb(): Dispatching audio focus listener event sessionId=11, event=0
Jan 03 06:31:49.608585 firestick-74357a7ea4ea1145 PuffinApp[1565]: 2875 W AudioManagerBase: onAudioFocusResumed(), no handler with focusSessionId 11 is registered before
/// ABPのメディアコードがフォーカスの一時停止を受け取ります。
Jan 03 06:31:49.607683 firestick-74357a7ea4ea1145 com.abp.firetv[11411]: W MEDIA_PLAYERV2:MediaPlayerAudioFocusObserver.cpp(103) audioFocusEventObserver Alert: onAudioPause received
Jan 03 06:31:49.607867 firestick-74357a7ea4ea1145 com.abp.firetv[11411]: W MEDIA_PLAYERV2:MediaPlayerAudioFocusObserver.cpp(105) audioFocusEventObserver Alert: Audio focus paused temporarily, sent event to app
Jan 03 06:31:49.608230 firestick-74357a7ea4ea1145 com.abp.firetv[11411]: W MEDIA_PLAYERV2:MediaPipelineObserverImpl.cpp(132) operator() AudioFocus Paused.
/// PuffinAppがフォーカスを使用中です。
Jan 03 06:31:49.608656 firestick-74357a7ea4ea1145 PuffinApp[1565]: I PuffinApp:[dd] AudioFocusIntegration:onAudioFocusGranted:sessionId=11
Jan 03 06:31:49.609276 firestick-74357a7ea4ea1145 PuffinApp[1565]: I PuffinApp:[dd] AudioFocusIntegration:onAudioFocusGranted:focusgrantresponsetime=53
Jan 03 06:31:49.609820 firestick-74357a7ea4ea1145 PuffinApp[1565]: I PuffinApp:[e:4] AudioFocusIntegration:executeOnFocusAcquire::acquired channel:channelName=Dialog,focusRequestId=Dialog,sessionId=11
/// マイクボタンが解放されました。
Jan 03 06:31:51.563061 firestick-74357a7ea4ea1145 PuffinApp[1565]: I PuffinApp:[12d] VegaBluetoothKeyEventObserver:stopSconeMicStreaming::scone mic button released or cancelled by other key press
/// ABPメディアは、メディアフォーカスが一時停止の状態でオーディオを書き込もうとしますが、想定どおり「Would Block」で失敗します。これはシステムオーディオの問題ではありません。
Jan 03 06:31:52.645487 firestick-74357a7ea4ea1145 com.abp.firetv[11411]: E AudioStream_VNTK:writeBuffer:180 failed Would Block
Jan 03 06:31:52.665143 firestick-74357a7ea4ea1145 com.abp.firetv[11411]: E AudioStream_VNTK:writeBuffer:180 failed Would Block
/// PuffinAppが音声認識フォーカスを解放します。
Jan 03 06:31:53.131161 firestick-74357a7ea4ea1145 PuffinApp[1565]: I PuffinApp:[e:4b] AudioFocusIntegration:onFocusRelease:focusRequestId=Dialog
Jan 03 06:31:53.131504 firestick-74357a7ea4ea1145 mixer[841]: 12236 I AudioControlService: releaseAudioFocus(): pid=1565, sessionId=11
Jan 03 06:31:53.131524 firestick-74357a7ea4ea1145 mixer[841]: 12236 I AudioFocusStack: releaseAudioFocus(): pid=1565, sessionId=11
Jan 03 06:31:53.131558 firestick-74357a7ea4ea1145 mixer[841]: 12236 I AudioFocusRecordState: handleAudioFocusReleased(): pid 1565 session 11 moving from state [granted] to [released]
/// ここでABPのメディアフォーカスが再開されます。
Jan 03 06:31:53.131889 firestick-74357a7ea4ea1145 mixer[841]: 12236 I AudioFocusRecordState: handleAudioFocusGained(): pid 11411 session 44 moving from state [paused] to [granted]
Jan 03 06:31:53.132524 firestick-74357a7ea4ea1145 PuffinApp[1565]: I PuffinApp:[254] AudioFocusIntegration:onAudioFocusReleased:sessionId=11
Jan 03 06:31:53.132438 firestick-74357a7ea4ea1145 PuffinApp[1565]: 13562 I AudioManagerAipc: dispatchAudioFocusEventCb(): Dispatching audio focus listener event sessionId=11, event=1
Jan 03 06:31:53.132461 firestick-74357a7ea4ea1145 PuffinApp[1565]: 13562 W AudioManagerBase: onAudioFocusStopped(), no handler with focusSessionId 11 is registered before
/// ABPメディアコードがフォーカスの再開を受け取り、それを示すログを出力します。これで再び正常にオーディオを再生できます。
Jan 03 06:31:53.132662 firestick-74357a7ea4ea1145 com.abp.firetv[11411]: W MEDIA_PLAYERV2:MediaPlayerAudioFocusObserver.cpp(83) audioFocusEventObserver Alert: onAudioGranted received
Jan 03 06:31:53.132705 firestick-74357a7ea4ea1145 com.abp.firetv[11411]: W MEDIA_PLAYERV2:MediaPlayerAudioFocusObserver.cpp(85) audioFocusEventObserver Alert: Audio focus granted , sent event to app
Jan 03 06:31:53.132796 firestick-74357a7ea4ea1145 com.abp.firetv[11411]: W MEDIA_PLAYERV2:MediaPipelineObserverImpl.cpp(140) operator() AudioFocus Granted.
////// しかし、ABPは現在オーディオの書き込みを行っていません。フォーカスが一時停止された状態で書き込みに失敗した後、異常な状態になっている可能性があります。アプリ開発者は、この問題をさらに調査する必要があります。
メディア再生が機能しない
メディア再生の問題が発生した場合、OSレベルの問題かアプリ固有の問題かを切り分けるには、体系的な調査が必要です。主な診断方法は、複数のアプリで再生をテストすることです。問題がさまざまなメディアアプリで発生する場合は、OSレベルまたはハードウェアの問題を示している可能性があります。一方、問題が1つのアプリでしか発生しない場合は、通常、アプリ固有の問題であることを示しています。さまざまなメディア形式での動作も手がかりになる可能性があります。すべての形式を再生できない場合は、OSまたはドライバーの問題を示唆しています。特定の形式で発生する問題は、多くの場合、アプリのコーデックや互換性の制限を示しています。
もう1つの重要な診断指標として、システムオーディオの動作があります。オーディオが正常に機能していてもアプリ内でメディアの再生が失敗する場合は、通常、アプリに問題があることを示しています。反対に、システムサウンドを含むすべてのオーディオが影響を受ける場合、問題はOSまたはハードウェアレベルにある可能性があります。問題が発生するタイミングも参考になります。OSのアップデート後に発生する問題はシステムレベルの変更を示すことが多いく、アプリのアップデートと同時に発生する問題はアプリ固有の原因を示唆しています。
再生がフリーズする
メディア再生のフリーズの問題を調査する場合、問題の原因がOSレベルにあるか、アプリレベルにあるかを判断するには、いくつかの重要な指標が役立つ可能性があります。主な指標の1つは、CPUとメモリの使用量です。システムがすべてのプロセスにわたって高いCPU使用率を示している場合や、フリーズ中にメモリに大きい負荷がかかっている場合は、OSレベルのリソース制約を示唆していることが一般的です。反対に、メディアアプリだけがリソースを過剰に消費している場合は、アプリ内に問題があると考えられます。フリーズの頻度とパターンからも有用な洞察が得られます。定期的に発生する断続的なフリーズは、多くの場合、アプリ内のバッファリングまたはメモリ管理の問題を示しています。システム全体で複数のアプリに同時に影響を及ぼす途切れやフリーズは、通常、OSレベルの問題を示しています。
フリーズ中のアプリの動作からも、さらなる診断の糸口が得られます。フリーズ中にアプリが完全に応答しなくなるのに対して、ほかのシステム機能は通常どおりに動作し続ける場合は、デッドロックや不十分なスレッド管理など、アプリ固有の問題を示唆しています。ただし、メディアの再生中にシステム全体の動作が遅くなったり応答しなくなったりする場合は、OSレベルのリソース制約やドライバーの問題を示していることがよくあります。フリーズと特定のアクションの関係も手がかりになります。特定の操作（シークや品質設定の変更など）の実行時に常にフリーズが発生する場合は、アプリレベルの処理に問題があると考えられます。一方、システムイベント（バックグラウンドプロセスの起動やシステムリソースの再割り当てなど）と同時にフリーズが発生する場合は、概してOSレベルの競合を示しています。
WebView固有の問題
WebViewの例外がログに表示されない
onError、onHttpError、onSslErrorでは、WebViewで発生する一部の接続エラーはキャプチャされますが、console.logの出力は表示されません。これを表示するには、vda forward tcp:9229 tcp:9229を使用してポート転送を実行し、chrome://inspect/#devicesでデバイスに接続する必要があります。ここでChromeをデバッグツールとして使用して、[コンソール] タブでconsole.logsを確認できます。
WebViewのローカルHTMLアセットが見つからない
これはよくある問題で、2つの原因が考えられます。ローカルファイルを/assets/*に追加しても、デバッグ時の高速リフレッシュと [実行] ボタンでは、assetsフォルダからの変更は反映されません。ローカルHTMLアセットに変更を加えたら、そのたびに実行前に再ビルドする必要があります。buildフォルダを削除して再ビルドすると、新しいHTMLファイルを確実に含めることができます。さらに、source.uriがfile:///pkg/assets/*を指していること、ファイルがプロジェクトのルートの/assetディレクトリ（/srcディレクトリではない）にあることも確認してください。
WebViewのメニューボタンが機能しない
allowsDefaultMediaControlプロパティが有効になっていると、メニューボタンはキャプチャされません。Vegaスクリプトラッパーアプリでは、目的のコマンドのJavaScriptをWebViewの参照に挿入する必要があります。
Last updated: 2025年10月1日
