Amazon Developer

as

Settings
Sign out
Notifications
Alexa
Amazonアプリストア
Ring
AWS
ドキュメント
Support
Contact Us
My Cases
開発
設計と開発
公開
リファレンス
サポート
メインコンテンツへスキップ
アプリに関連する問題とOSに関連する問題を切り分けるには、外部ビルドで問題をテストすることが不可欠です。さまざまなビルドでアプリの動作を調べることで、根本原因がアプリコードにあるか、それともオペレーティングシステム自体にあるかを効果的に特定できます。この体系的なアプローチにより、問題の正確な特定と的を絞った解決が可能になり、トラブルシューティングとデバッグのプロセスの効率を高めることができます。 アプリの問題のトラブルシューティングを行う場合、効果的な診断方法としてバージョンの比較を使用できます。同じアプリビルドを実行しているときに、最新のOSバージョンと以前のOSバージョンの両方で問題が再現される場合は、アプリコードかその依存関係に根本的な原因があることが一般的です。反対に、問題が最新のOSバージョンでのみ発生し、同じアプリビルドを使用しているにもかかわらず以前のバージョンでは正常に動作する場合は、OSの互換性の問題を示しており、アプリ側で特定の処理が必要になる可能性があります。この比較テスト方法により、アプリコードのデバッグに焦点を当てるべきか、OS固有の互換性要件を調査するべきかを効率的に判断でき、最終的により的確な問題解決につなげることができます。 次のセクションでは、アプリ側の問題の例について詳しく説明します。

ANRクラッシュ

アプリ応答なし(ANR)でのクラッシュは通常、アプリに関連する問題であり、アプリがライフサイクルマネージャー(LCM)またはシステムコールに応答しない場合に発生します。この場合、LCMは応答しないアプリを強制的に終了します。ANRをトリガーし、アプリの終了を引き起こすような特定のシナリオはいくつかあります。

ANRレポートの解釈

アプリプロセスでANRが発生した場合、まず確認するべきフィールドは「LCM_ANR_REASON」フィールドです。名前から推測されるとおり、このフィールドはプロセスがANRになった理由を示します。次の表で、返される可能性のある理由を詳しく説明します。

アプリが応答なし(ANR)で強制終了された場合

システムで実行されているすべてのアプリが正常に動作していて、アクティブにコントラクトに従っていることを確認するために、システムのさまざまなサービスがアプリの応答性を追跡しています。これらのサービスは、アプリが無応答になったと判断すると、プロセスを強制終了するようにLCMに要求します。以下は、ANRにつながる可能性のあるイベントの一覧です。デフォルトのタイムアウト時間は、プロファイル、プラットフォーム、製品の構成によってオーバーライドされる可能性があるため、アプリが従う必要のあるタイムアウト時間と同じになるとは限らないことに注意してください。 このデータを使用して、収集した情報をアプリチームに説明し、LCM_ANR_REASONに従ってアプリチームに解決策を推奨する必要があります。

JS例外

通常、JavaScript(JS)例外はアプリから発生し、journaldログに記録されます。問題を調査するときは、JS例外を、報告された問題のタイムスタンプと再現手順に関連付けることが重要です。JS例外の中には、さまざまな要因によってランダムにログに表示されるものもありますが、特定の問題の発生期間と同じタイミングで例外が見つかる場合は、OSレベルの問題ではなくアプリ側の問題であることを強く示唆しています。致命的な例外に伴ってJSErrorが発生していて、その後クラッシュする場合は、アプリのメソッドが例外をスローしています。

メディアコントロールボタンが機能しない

ビデオの再生中にリモコンのメディアコントロールキー(再生、一時停止、早送り/早戻しなど)が機能しない場合は、ログの分析が重要になります。詳しい調査では通常、2つの側面に焦点を当てます。つまり、リモコンのキー押下イベントがアプリに正しく届いているかどうかを検証し、これらのイベントに対してアプリが正常に確認を返しているかどうかを確かめます。この系統的なチェックにより、通信チェーンがどこで遮断されているかを特定できます。 ただし、アプリ開発者が参照できるのはアプリの確認のログだけです。

入力ログ

アプリの確認ログ

アプリの確認ログでリモコンからの入力を受信していることが確認されても、想定されたアクションが実行されない場合は、アプリ側に問題があると考えられます。アプリはこれらのキーイベントを受信していますが、正しく処理していません。また、アプリがVegaMediaControls(VMC)を実装している場合は、VMCハンドラーのログにさらなる根拠が示される可能性があります。必要なVMCメソッドがアプリに正しく実装されていないと、ボタンが押されるたびにログに「未定義のキーイベント」が記録されます。 VMCの呼び出し時にAlexaが一時停止/再生/早送り/早戻しに関連する処理を行っている場合、VMCに情報を渡すには、VSM(VegaSpeechModule)が確認を行う必要があります。

VMCの未定義のボタンイベントのログ

ナビゲーションが機能しない

この問題は、前述のメディアコントロールボタンの問題と同じです。調査では、リモコンのキー押下イベントがアプリに正しく届いているかどうかを検証し、これらのイベントに対してアプリが正常に確認を返しているかどうかを確かめるという、2つの側面に焦点を当てる必要があります。この系統的なチェックにより、通信チェーンがどこで遮断されているかを特定できます。アプリ開発者はinputdログにはアクセスできませんが、ボタンイベントに対するアプリの応答を調べることはできます。アプリがボタンイベントの確認を受け取っている場合、リモコンからのナビゲーションイベントは届いていると考えられます。アプリ側で第1レベルのトリアージを実行して、アプリの実装に問題がないかどうかを確認する必要があります。

VoiceViewが機能しない

VoiceViewが機能せず、ユーザーレポートの値が読み上げられない場合は、UCCツリーを調べて、ユーザー補助機能で読み上げる説明がラベルに設定されているかどうかを確認することをお勧めします。VegaスクリプトとWebViewアプリへのリンクは以下のリストにあります KeplerScript WebView

UIの切り詰め/UIフォーカスの問題

ユーザーインターフェイス(UI)が切り詰められる場合は、アプリに関連する問題であることがほとんどです。UI要素のレンダリングはアプリが制御するためです。この問題は、タブ、メニュー、サブメニュー内のコンポーネントの一部が欠けたり、フィールドが空になったりする症状として現れます。UIオブジェクトのレンダリングとレイアウトの実装を検査するために、アプリチームによる調査が必要です。これはUI/フォーカス関連の問題であるため、一般に、この問題に関する情報がオペレーティングシステムのログに含まれることはありません。

オーディオ関連の問題

オーディオの損失/オーバーラップの問題

アプリがオーディオフォーカスを取得せずにオーディオを書き込もうとすると、「Would Block」というエラーがアプリに返されます。この場合、アプリの観点から、必要なフォーカスセッションを取得できなかった理由に優先順位を付ける必要があります。

オーディオリークの問題

このような場合、アプリはフォーカスがPausedした状態での書き込みに失敗した後、異常な状態に陥ることがあります。たとえば、Alexaによる中断後に再生が再開されず、読み込み中のスピナー画面のまま止まってしまう場合に、これが発生することがあります。

メディア再生が機能しない

メディア再生の問題が発生した場合、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の参照に挿入する必要があります。
最終更新日 2026年10月26日