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.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 onlyinputd logs
App’s acknowledgment log
VMC button events undefined log
Navigation not working
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 toinputd 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 WebViewUI 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 related issues
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 thePaused 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 usingvda 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 theallowsDefaultMediaControl property is enabled. The Vega Script wrapper app needs to inject JavaScript into a WebView reference with the intended command.

