Amazon Developer

as

Settings
Sign out
Notifications
Alexa
Amazon Appstore
Ring
AWS
Documentation
Support
Contact Us
My Cases
Get Started
Design and Develop
Publish
Reference
Support
Skip to main content
Testing issues in external builds is crucial for distinguishing between app-related and OS-related problems. By examining the app’s behavior across different builds, you can effectively pinpoint whether the root cause lies within the app code or the operating system itself. This systematic approach helps ensure accurate problem identification and targeted resolution, leading to more efficient troubleshooting and debugging processes. When troubleshooting app issues, you can use version comparison as an effective diagnostic approach. If an issue reproduces on both the latest OS versions and previous OS versions when running the same app build, it typically indicates that the root cause lies within the app code or its dependencies. Conversely, if the issue only manifests on the latest OS version but works correctly on the previous one despite using the same app build, this suggests an OS compatibility issue that might require specific handling in your app. This comparative testing method helps you efficiently identify whether to focus debugging efforts on your app code or investigate OS-specific compatibility requirements, ultimately leading to more targeted problem resolution. The following sections detail examples of app-side issue.

ANR crash

Application Not Responding (ANR) crashes are typically app-related issues, occurring when an app fails to respond to the Lifecycle Manager (LCM) or system calls. In these cases, the LCM forcibly terminates the unresponsive app. There are several specific scenarios that can trigger an ANR, leading to app termination.

Reading ANR reports

If your app process was ANR’ed, the next field you’ll want to look at will be the “LCM_ANR_REASON” field; as the name implies, this will be the reason why the process was ANR’ed. These reasons are detailed in the following table:

App was killed for being unresponsive (ANR)

To ensure all apps running on the system are alive and actively obeying their contracts, various services on the system track app responsiveness. If they determine the app has become unresponsive, they will request for LCM to forcefully terminate the process. The following are the events that could lead to an ANR. Note the default timeout lengths can be overridden by profile, platform, and product configurations, so this might not be the timeout length your app must comply with. With this data, reach out to the app team with the collected information and recommend the solution according to the LCM_ANR_REASON to the app team.

JS exceptions

JavaScript (JS) exceptions typically originate from the app and are recorded in journald logs. When investigating issues, it’s important to correlate JS exceptions with the reported problem’s timestamp and reproduction steps. Although some JS exceptions might appear randomly in logs due to various factors, finding exceptions that align with the specific issue timeframe strongly suggests an app-side problem rather than an OS-level issue. If JSErrors come with Fatal exception followed by crash, then it is the App’s method is throwing exception.

Media control buttons aren’t working

When media control keys (like play, pause, or fast-forward/rewind) on the remote control fail during video playback, log analysis becomes crucial. The full investigation typically focusses on two aspects: verifying if the remote’s key press events are properly reaching the app, and confirming whether the app successfully acknowledges these signals. This systematic check helps identify where the communication chain breaks down. However, app developers can look at the app acknowledgement log only

inputd logs

App’s acknowledgment log

When app’s acknowledgment logs confirm about receiving the input from remote , but the expected actions still don’t occur, it likely indicates an app-side issue. The app is receiving but failing to process these key events properly. Additionally, If the app has implemented VegaMediaControls(VMC) , the VMC-handler logs can provide further confirmation - it will record “undefined key events” for each button press if the app hasn’t properly implemented the required VMC methods. When VMC is invoked , If Alexa is processing the Pause/Play/Forward/Rewind related , VSM (VegaSpeechModule) has to acknowledge to pass the information to VMC.

VMC button events undefined log

This issue is the same as the previously mentioned media control buttons issue. The investigation should focus on two aspects: verifying if the remote’s key press events are properly reaching the app, and confirming whether the app successfully acknowledges these signals. This systematic check helps identify where the communication chain breaks down. Although app developers don’t have access to inputd logs, they can see the app’s acknowledgement of the button event. If the app has an acknowledgment of the button event, it is likely that it has received the navigation event from the remote and first level triage should be done on the app side to check if there has been any issue in the app implementation.

VoiceView not working

If VoiceView is not working and the user reports value is not read, it is worth checking the ucc tree to see if the label has description for accessibility to read. Link for the Vega script and WebView apps are in the following list KeplerScript WebView

UI crop/UI Focus issues

User Interface (UI) cropping issues are typically app-related problems since the app controls UI element rendering. These issues appear as either truncated components or empty fields within tabs, menus, or submenus. Investigation by the app team is necessary to examine UI object rendering and layout implementation. As these are UI/focus-related issues, operating system logs generally won’t contain relevant information about these problems.

Audio loss/overlap issues

If app tries to write audio without acquiring audio focus, then “Would block” error is returned to app. This requires triaging from App perspective why they failed to acquire required focus session:

Audio leak issues

In such cases, apps enter into a bad state after failing to write in the Paused focus state. For example, this might occur when the playback does not resume and stays in the loading spinner screen after Alexa interruptions.

Media playback not working

When encountering media playback issues, distinguishing between OS-level and app-specific problems requires systematic investigation. A key diagnostic approach is to test playback across multiple apps - if the issue persists across various media apps, it likely indicates an OS-level or hardware problem, while issues isolated to a single app typically point to app-specific causes. The behavior with different media formats can also be telling; if all formats fail to play, this suggests an OS or driver issue, whereas problems with specific formats often indicate app codec or compatibility limitations. System audio behavior provides another crucial diagnostic indicator. When audio functions normally but media playback fails within an app, this typically points to an app issue. Conversely, if all audio is affected, including system sounds, the problem likely resides at the OS or hardware level. The timing of issues can also be informative - problems arising after OS updates often indicate system-level changes, while issues coinciding with app updates suggest app-specific causes.

Playback freeze

When investigating media playback freezing issues, several key indicators can help determine whether the problem originates from the OS or the app level. One primary indicator is CPU and memory usage - if the system shows high CPU utilization across all processes or significant memory pressure during freezes, this typically suggests an OS-level resource constraint. Conversely, if only the media app shows excessive resource consumption, the issue likely resides within the app. The frequency and pattern of freezing also provide valuable insights - intermittent freezing that occurs at regular intervals often indicates buffering or memory management issues within the app, while system-wide stuttering or freezing that affects multiple apps simultaneously usually points to OS-level problems. App behavior during freezes offers additional diagnostic clues. If the app becomes completely unresponsive during freezes while other system functions continue normally, this suggests an app-specific issue such as deadlocks or poor thread management. However, if the entire system becomes sluggish or unresponsive during media playback, this often indicates OS-level resource constraints or driver issues. The relationship between freezing and specific actions is also telling - if freezes consistently occur during particular operations (like seeking or changing quality settings), this suggests app-level handling issues. Meanwhile, freezes that coincide with system events (like background processes starting or system resources being reallocated) typically indicate OS-level conflicts.

WebView specific issues

WebView exceptions are not showing in logs

The onError, onHttpError, and onSslError will capture some connection errors with the WebView but will not show console.log outputs. To do this, you need to port forward using vda forward tcp:9229 tcp:9229 and then connecting to the device with chrome://inspect/#devices. Here, can use Chrome as a debugging tool, including seeing console.logs in the console tab.

WebView local HTML asset not found

This is a common issue with two likely causes. When adding local files to /assets/*, the debug fast refresh and “run” buttons do not upload changes from the assets folder. You will need to rebuild before running each time a change is made to a local HTML asset. You might also delete the build folder and rebuild to ensure that the new HTML file is present. Also make sure that your source.uri is pointing to file:///pkg/assets/* and that the file is in the project root’s /asset directory (and not in the /src directory)

WebView menu button not working

The menu button is not captured when the allowsDefaultMediaControl property is enabled. The Vega Script wrapper app needs to inject JavaScript into a WebView reference with the intended command.
Last modified on October 6, 2025