Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン 初心者向け
  • 何か問題がありますか？
#11,139 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
85/100
issue の種類
ドキュメント
明瞭さ
明確に書かれている
活発さ
静か
技術スタック
android, cpp, csharp, java
領域
documentation

調査の方向性

.github/skills/diagnose-dotnet-android/SKILL.md を作成し、まず既存の skill の frontmatter と、関連する android-tombstone-symbolication および azdo-build-investigator skill を確認します。指定された C#、C++、Java のロギング例、logcat のフィルタリング、tombstone と生成された出力の調査、仮説の検証を文書化します。すべての受け入れ基準とトリガーフレーズが網羅されていれば完了です。

索引モデルが issue の本文から書いたものです。

説明

Area: Debugger enhancement needs-triage

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.

主要言語
C#
スター
2.1k
フォーク
580
平均マージ
1日 22時間
マージ済み PR（30日）
215

環境構築

このプロジェクトの環境構築ファイルはまだ確認していません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

dotnet/android のほかの issue

dotnet/android の issue をすべて見る

似ている issue

C# の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。