Troubleshooting

Start with the failing stage and preserve the original APK, command, and runtime log. For capture, the session directory also contains full instrumentation and report-generation diagnostics.

Build and signing

Symptom	Action
Maven or Java is not found	Check java -version and mvn -version; install/configure the required build tools
Signing tool not configured	Fill both executable paths in the external config.properties and use the classpath helper from Installation
Tool is not executable	Verify the chosen Build Tools version, file path, and executable permissions
Configuration works with the helper but not java -jar	java -jar does not use the helper's external configuration directory; use the documented java -cp invocation
Platform resolution fails	Check that -p points to the SDK platforms directory or a valid platform android.jar
Instrumentation fails	Add -v, retain the diagnostics, and check the JDK, APK, SDK, and scope used

The tracked signing configuration has empty paths by design. Each installation supplies its own SDK executables.

Device, installation, and launch

Symptom	Action
No ready device	Run adb devices; connect/authorize a device or start an emulator
Several devices are ready	Add --device <serial> in capture, or -s <serial> to manual ADB commands
Cannot find ADB	Add --adb /absolute/path/to/adb, or use an SDK with Platform Tools installed
INSTALL_FAILED_UPDATE_INCOMPATIBLE	The installed app has a different signing certificate; use a clean test device or an installation compatible with the test key
No launcher found	Use the manual workflow and trigger the appropriate component yourself
The instrumented app behaves differently	Check device logs and signing-sensitive behavior; instrumentation and re-signing can affect the application

Capture uses adb install -r. It does not automatically uninstall an incompatible installation.

Capture stops without reports

Enter finishes capture and generates reports. Ctrl+C aborts. With closed standard input, specify --duration <positive seconds>. A disconnection or logcat failure also stops the workflow.

If runtime.log exists, it is retained. Recover a report using the original APK, tag, and matching options as described in Capture. The partial run may contain fewer observations than intended.

Coverage is empty or unexpectedly low

Check these in order:

1. APK: reporting uses the exact original APK corresponding to the installed instrumented build.
2. Probes: the same -c, -m, -s, -cp, and -mc selections were used at both stages.
3. Scope: -pkg and -n match; an obfuscated package may be outside an assumed prefix.
4. Tag: -l agrees with the logcat filter and the recorded messages.
5. Timing: recording started before a fresh application process; once-per-process observations may otherwise be absent.
6. Execution: the test actually exercised the relevant code, and the log retained its records.

Selecting more probes only during reporting does not recover missing instrumentation. Regenerating a report from old logs also does not apply improvements to how those logs were recorded.

No dynamic call graph

Instrument with -mc, install that APK, and collect fresh logs. Keep -mc enabled when parsing. Method coverage records alone do not provide the callsite-to-target correlation required by the graph.

If graph data exists but the view asks you to choose a class, the launcher metadata or matching launcher relationships are unavailable. Select a class with recorded calls. The default graph deliberately does not expand to the whole application.

Many dashed edges

Select an edge and inspect its invocation kind and declared signature. The current dashed style includes constructors, uninstrumented framework/native code, excluded APK methods, legacy events, calls that fail before entry, and missing confirmations.

For constructors and directly resolved framework methods, the target can be known despite the missing entry record. Dashed does not mean polymorphism failed. See Dynamic Call Graph.

An ordinary app-to-app virtual call that remains unconfirmed deserves closer inspection. Check that the actual implementation was instrumented, that its signature matches the call, and that the raw log retains its observations. Gaps in MC2 sequence numbers indicate missing records or emission gaps; they do not identify the missing target by themselves. The current tracer does not explain each failed match in the report.

Timeline is empty or differs from aggregate coverage

Use -pam and standard adb logcat -v threadtime output. The current minute extractor expects a leading MM-DD HH:mm timestamp. Other accepted log formats can contribute to aggregate totals without timeline buckets. A probe is counted at its first matching occurrence in file order, so preserve chronological ordering.

The timeline accumulates distinct coverage observations; it does not measure repeated executions. See JSON and Logs.

Share a reproducible problem

Open an issue with the AndroLog commit, command, Java/Maven versions, Android SDK/device details, and relevant error or call-record excerpt. Include the instrumentation flags as well as the reporting flags. A small reproducer is preferable to an entire application when it demonstrates the same behavior.

For capture failures, identify which stage failed and include the relevant part of instrumentation.log or report-generation.log.