dotnet / dotnet/android

Add Copilot skill: diagnosing dotnet/android across C# / Java / C++ / generated native

Open
#11,139 0 comments 0 reactions 0 assignees View on GitHub
Area: Debugger enhancement needs-triage
Dominant language
C#
Stars
2.1k
Forks
579
Avg merge
1d 20h
Merged PRs (30d)
257

Description

## Problem

Diagnosing runtime issues in dotnet/android requires following execution across four loosely-coupled layers: C# (Mono.Android), Java (the JCW layer), C++ (the native host), and generated LLVM IR (marshal methods, typemap). There is no CLI debugger that can step through all four, and static reasoning about "who calls whom" is often wrong because the coupling is dynamic (JNI reflection, function pointers passed through init args, registered native methods).

During PR #11091, several hours were lost chasing assumed call paths that turned out to be completely dead (e.g., a C++ `registerNatives` entry point we were "fixing" was never actually called — verified only after adding logging).

## Proposal

Add `.github/skills/diagnose-dotnet-android/SKILL.md` documenting best practices for cross-language diagnosis:

1. **Add logging at each layer** and verify assumptions empirically:
- C#: `AndroidLog.Print (AndroidLogLevel.Warn, "TAG", "...")` / `Logger.Log`
- C++: `log_warn (LOG_DEFAULT, "..."sv, ...)` in `src/native/`
- Java (if modifying JCW templates): `android.util.Log.w("TAG", "...")`

2. **Absence of log output is itself evidence.** If your log never fires, your mental model of the call graph is wrong. Walk back and re-verify entry points.

3. **Grep logcat with meaningful prefixes:**
```
adb logcat -d | grep -E 'TAG|FATAL|tombstone'
```

4. **Cross-reference tombstones** for native crashes — use the `android-tombstone-symbolication` skill.

5. **Decompile generated IL/LLVM IR** when behavior suggests generator output differs from generator source.

6. **Bracket your hypothesis** — before "fixing" a suspected bug, add a log that proves the buggy code path is actually reached. If the log doesn't fire, the bug is somewhere else.

## Acceptance criteria

- [ ] Skill exists with proper frontmatter.
- [ ] Triggered by phrases like "diagnose android runtime", "why isn't this code being called", "logcat".
- [ ] Includes concrete logging snippets for C#, C++, and Java layers.
- [ ] Cross-references related skills (`android-tombstone-symbolication`, `azdo-build-investigator`).

## Discovered during

PR #11091 — adding the CoreCLRTrimmable CI lane. Significant time lost to flawed assumptions about call paths that could have been cheaply disproven with a single log statement.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.