Add Copilot skill: diagnosing dotnet/android across C# / Java / C++ / generated native
- 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.