.NET MAUIがAndroidエミュレーターでオフライン起動しない（Debugのみ）原因と回避策：Release検証とIssue報告の実務

.NET MAUI のチュートリアル（Notes アプリ）を Android エミュレーターで実行すると、オンラインでは起動するのにオフラインだと起動しない――。アプリ側のネットワークリクエストが見当たらないのに再現する場合、切り分けの観点と現実的な回避策をまとめます。

発生している症状（オンラインだと起動、オフラインだと起動しない）

今回のポイントは「アプリがネットワークを使っているから落ちる」のではなく、オフライン状態そのものが起動（特に Debug 実行）に影響しているように見える点です。まずは状況を整理します。

項目	状況	よくある誤解	この問題の特徴
対象	.NET MAUI チュートリアル（Notes アプリ）	サンプルは軽いので環境依存は少ないはず	サンプルでも環境/実行モード依存の挙動は起こり得る
端末	Android エミュレーター	実機と同じ挙動のはず	エミュレーター固有のバグ/制限がある
条件	オンライン：起動する / オフライン：起動しない	アプリの初期化で通信している	通信していなくても起動に影響するケースがある
発生モード	Debug 実行時に顕著	ビルド設定の違いは性能だけ	Debug は動作経路が増え、接続状態の影響を受けやすい
確認済みのこと	ネットワークリクエストなし / 権限確認 / キャッシュ削除 / 新規エミュレーター作成	権限の付け外しで解決する	権限やキャッシュでは解決しないことがある

この時点で重要なのは、「アプリコードの不備」ではなく「エミュレーター × Debug 実行」の相性問題として扱うことです。闇雲にアプリ側を修正すると、根本は直らないまま「たまたま起動する」状態を作ってしまい、再発しやすくなります。

先に結論：これはエミュレーター上の再現現象で、Debug 実行時に起きやすい

本件は、Android エミュレーター上で再現する現象として確認され、特にDebug 実行時の挙動として発生しやすいケースに該当します。つまり、アプリがオフラインに弱いのではなく、デバッグ実行の起動シーケンスが「オフライン状態」で引っかかっている可能性が高い、という扱いになります。

そのため根本対応としては、公式の .NET MAUI リポジトリ（dotnet/maui）へ不具合報告（Issue）を行い、再現手順とログを共有するのが推奨です。実装の工夫で無理に押さえ込むより、プラットフォーム側で直るべきタイプの問題だからです。

なぜ「オフライン」だけで起動に影響が出るのか（起こり得る構造）

ここでは「原因を断定」ではなく、切り分けに役立つ起こり得る構造として整理します。.NET MAUI の Android Debug 実行では、単純に APK を起動するだけでなく、開発体験のための経路が増えます。

要素	Debug で増えがちな処理	オフラインの影響が出やすいポイント	ユーザーが見える症状
デバッガー接続	起動直後にデバッガーをアタッチ	接続待ち/タイムアウトが長くなることがある	起動しない・スプラッシュのまま
Hot Reload / 開発補助	差分適用のための初期化	内部的に待ちが発生することがある	初回だけ遅い、オフラインで極端に遅い
エミュレーターのネットワーク判定	Android 側が接続性チェックを行う	オフライン時に OS 側がリトライする	「何か待っている」ように見える
ツールチェーン連携	IDE/SDK/ADB の連携	エミュレーター状態により起動イベントが遅延	デプロイ完了後もアプリが前面に来ない

この手の問題の厄介さは、アプリがネットワークを叩いていなくても、開発ツール・OS・エミュレーターが「オフライン」を前提にしていない部分で待ちが生まれ、結果として「起動しない」に見える点です。

すでに試した内容が「正しい切り分け」である理由

質問の前提として挙げられている確認項目は、どれも筋が良いです。オフライン問題は「通信しているのでは？」に引っ張られがちですが、今回のケースでは先に疑うべきところを潰せているのが重要です。

試したこと	目的	分かること	今回の示唆
起動時にネットワークリクエストが無いことを確認	アプリの初期化通信の可能性を排除	アプリコードが主因でない可能性	ツール/エミュレーター側へ視点を移せる
エミュレーター設定の確認	ネットワークの挙動や機種差の影響を確認	特定設定が原因か	設定依存ではなく再現性が高い可能性
AndroidManifest の権限（INTERNET / ACCESS_NETWORK_STATE）確認	権限による例外を排除	権限不足が原因か	権限の有無で解決しない＝別要因
キャッシュ削除・新規エミュレーター作成	環境の汚れや状態不整合を排除	永続状態が原因か	個体差ではなく構造的問題の線が濃い

つまり、ここまでで「アプリのコードをいじっても本質は変わらない」という判断がしやすくなっています。次の一手は「運用（ワークアラウンド）」と「公式への報告」の2つに寄せるのが現実的です。

今すぐ使える回避策（ワークアラウンド）

根本修正がツール側で行われるまで、開発と検証を止めないために、実務で効く回避策を2つ紹介します。ポイントは「Debug でしかできないこと」と「Release で検証すべきこと」を分離することです。

起動してからネットワークを切る（Debug でブレークポイントも使いやすい）

アプリを起動してからエミュレーター側のネットワークを切ります。これにより、起動時の「何らかの待ち」だけ回避し、起動後はオフライン状態でデバッグできる確率が上がります。

• オンライン状態で Debug 実行して起動させる
• 起動したらエミュレーターをオフラインにする（Wi‑Fi OFF、機内モード等）
• そのままオフラインで画面遷移・ローカルDB・キャッシュ処理などを確認する

「オフライン時の挙動確認」が主目的で、かつブレークポイントを使いたい場合は、この方法が一番ストレスが少ないことが多いです。

Release モードでデプロイして検証する（オフライン動作の本命）

この問題はDebug モードでのみ発生し、Release では正常起動するケースとして扱われています。したがって、オフライン動作の検証を確実に進めたいなら、Release ビルドでの検証に寄せるのが現実的です。

• Visual Studio の構成を Release に切り替える
• エミュレーターまたは実機へデプロイする
• オフライン状態で起動できることを確認する

Release で検証するメリットは「本番に近い状態での評価ができる」ことです。オフライン対応はユーザー体験に直結するため、Debug の結果だけで判断しないのは、品質面でも合理的です。

目的	おすすめ	理由	注意点
起動後のオフライン処理をデバッグしたい	起動後にオフラインへ切り替え（Debug）	ブレークポイントやウォッチが使える	「起動時オフライン」は再現できない可能性
ユーザー視点のオフライン起動を検証したい	Release で検証	本番相当の起動経路で評価できる	ログが少なくなるのでログ設計が重要
根本の修正を狙いたい	dotnet/maui に Issue	再現情報が集まると修正につながる	再現手順・環境情報・ログが必要

オフライン検証を「破綻させない」ための実務フロー

オフライン問題の検証は、やり方を間違えると「検証できているつもり」になりがちです。Debug 起動が不安定な場合は、次のように手順を分けると事故が減ります。

検証フロー（おすすめ）

1. Release で「オフライン起動」できることをまず確認（ここが崩れると製品として成立しない）
2. 次に Release で主要シナリオ（メモ追加、編集、削除、検索、永続化、復帰）をオフラインで確認
3. 最後に Debug で「起動後にオフライン」に切り替え、細かい例外・分岐・状態を追う

この流れにすると、Debug 起動の問題に引きずられず、製品価値に直結する部分から先に固められます。

オフライン切り替えの方法（エミュレーターでのやり方を複数持っておく）

「オフラインにしたつもり」が原因で切り分けがブレるのはよくあります。エミュレーターでは、同じ“オフライン”でも状態が微妙に違うことがあるため、切り替え方法を複数用意しておくと確認が早くなります。

方法	やり方	特徴	検証に向くケース
Wi‑Fi をOFF	設定アプリから Wi‑Fi をOFF	最も簡単。状態が分かりやすい	一般的なオフライン挙動
機内モード	クイック設定で機内モードをON	通信系をまとめて止める。副作用も出やすい	完全オフラインを想定する場合
エミュレーターの Extended controls	エミュレーターの設定画面から制御	UIで再現性を取りやすい	再現手順を人に共有する場合
ADB コマンド（環境による）	adb shell svc wifi disable adb shell svc data disable	スクリプト化しやすい。端末/権限で効き方が変わる	自動化テストや再現性重視

本件のように「オフラインだと起動しない」タイプは、オフライン切り替え方法を変えても同様に起きるかを見るだけでも、原因がアプリ側かどうかの判断材料になります。

「権限（INTERNET / ACCESS_NETWORK_STATE）」の扱い：やるべきこと・やりすぎないこと

ネットワーク絡みの症状が出ると真っ先に疑うのが AndroidManifest.xml の権限ですが、今回のケースでは権限が主因ではない可能性が高いため、目的を決めて確認するのが大切です。

最低限の確認ポイント

• アプリがネットワーク機能を持つなら INTERNET は必要
• 接続状態を判定するなら ACCESS_NETWORK_STATE が必要
• 今回のように「起動すらしない」場合、権限の付け外しで症状が変わらないなら、深追いはしない

参考：Manifest の例

アプリ設計として必要な場合のみ、次のように宣言します（問題の解決策というより、一般的な整理としての例です）。

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

「オフライン起動ができない」からといって、INTERNET を外すなどの極端な対処はおすすめしません。アプリの設計上ネットワークが必要な場面があるなら、権限は適切に持ちつつ、起動時にネットワーク前提の処理を避ける（タイムアウト短縮、バックグラウンド化、キャッシュ優先）などのアプリ側設計で担保するのが本筋です。

ログで「何が止まっているか」を見る（最短で判断するために）

「起動しない」は、実際には次のどれかであることが多いです。

• プロセスが起動してすぐ落ちている（例外でクラッシュ）
• プロセスは生きているが画面が出ない（初期化待ち/デッドロック/待機）
• デバッガーのアタッチ待ちで止まっている

ここを曖昧にすると、対策が当たりません。エミュレーターの問題を疑うにしても、「アプリがどこまで進んだか」を一度ログで確認すると、Issue 報告にもそのまま使えます。

確認手段（代表例）

• Visual Studio の出力ウィンドウ（デプロイ〜起動までの流れ）
• Android Device Log / Logcat
• ADB でのログ取得（コマンドラインでも可）

特に Logcat では、起動直後の例外や待機状態が見えることが多いです。オフラインにした瞬間に「何かを待ち続けているログ」が出ていないかを確認し、同じ操作をオンラインで行った場合と比較すると判断が早くなります。

追加で試せる小さな工夫（効く場合があるが“本筋”ではない）

結論は「エミュレーター × Debug の挙動」である可能性が高いものの、現場では「とにかく回して検証したい」こともあります。以下は環境によって効く場合がある小技です（万能ではありません）。

工夫	狙い	期待できる効果	注意点
エミュレーターの Cold Boot を試す	状態の持ち越しを避ける	起動シーケンスの不整合が消えることがある	再現性確認は Quick Boot と両方で
API レベル/システムイメージを変える	特定イメージ固有の不具合回避	オフライン判定の挙動が変わる場合がある	本番想定の API レベルから離れすぎない
実機で同条件を確認	エミュレーター固有かを切り分け	再現しないならエミュレーター問題の確度が上がる	実機はOSやメーカー差がある

ただし、これらは「環境で逃げる」方向の対処です。原因の共有（Issue）と、Release での検証がブレないようにしましょう。

dotnet/maui へ Issue を出すときの書き方（再現しやすい報告テンプレ）

根本解決に最短で近づけるには、公式リポジトリへ情報を集約するのが有効です。報告の質が高いほど、同じ問題に困っている人が集まりやすく、再現検証も進みます。

Issue に入れるべき情報

情報	具体例	なぜ必要か
.NET / MAUI のバージョン	例：.NET 8 / MAUI 8.x など	特定バージョン固有かを切り分ける
開発環境	Visual Studio の版、OS（Windows/macOS）	IDE 経路が絡む可能性がある
Android エミュレーター条件	API レベル、システムイメージ種別、ABI	エミュレーター個体差が出やすい
再現手順	「オンラインで起動→OK」「オフラインで起動→NG」など	第三者が同じ操作で検証できる
ログ	Logcat、VS 出力、例外スタック	原因箇所の推測精度が上がる
Release での結果	Release では起動する/しない	Debug 固有かどうかが核心情報

報告文の例（コピペして整形して使える）

以下は文章の骨格です。実際の環境値に置き換えてください。

### Summary
.NET MAUI tutorial (Notes app) does not start on Android Emulator when the emulator is offline.
It starts normally when online.

### Repro steps
1. Create MAUI Notes app (tutorial).
2. Deploy and run on Android Emulator (Debug).
3. When emulator is online -> app starts.
4. When emulator is offline before launch -> app does not start (or stuck at splash).

### Expected behavior
The app should start even when the emulator is offline.

### Actual behavior
It fails to start only when offline, reproducible on emulator.
(Release build starts normally.)

### Environment
- .NET SDK: (paste `dotnet --info`)
- MAUI workload: (paste `dotnet workload list`)
- Visual Studio: version
- OS: Windows/macOS version
- Android Emulator: API level, system image, ABI
- Device: Emulator only (not reproduced on physical device, if confirmed)

### Logs
- Visual Studio output:
- logcat:

Issue の目的は「責任追及」ではなく、再現条件の共有です。再現性が高い情報ほど価値があります。

オフライン対応の品質を上げるコツ（この問題と切り離して考える）

今回の現象は「エミュレーター × Debug」の可能性が高い一方で、オフライン対応そのものはアプリ品質の根幹です。Debug 起動の問題に引っ張られず、次の観点を別枠で固めておくと、後で不具合が減ります。

起動時にネットワーク前提の処理を置かない

• 初回起動の同期処理は、起動後に遅延実行する
• タイムアウトは短めにし、失敗時はキャッシュへフォールバックする
• 「ネットワークがないとアプリが動かない」状態を避ける

ログと状態表示を仕込む（Release 検証で効く）

• オフライン時に何ができて何ができないか、画面で分かるようにする
• ネットワーク判定の結果（例：オンライン/オフライン/不明）を内部ログに残す
• 同期キューや再送処理の状態（未送信件数など）を確認できるようにする

オフライン対応は「通信しない」ではなく、通信できない前提でも UX を崩さない設計が鍵です。今回の起動問題の回避策（Release での検証）とも相性が良いので、検証の段階からログ・状態を整えるのがおすすめです。

まとめ：Debug 起動にこだわりすぎず、検証を前に進める

.NET MAUI の Notes アプリが「オフライン時に Android エミュレーターで起動しない」問題は、アプリのネットワーク実装が原因ではなく、エミュレーター上で再現する Debug 実行時の挙動として扱うのが現実的です。

• すぐに詰まらないための回避策：起動してからオフライン
• オフライン動作の本命検証：Release でデプロイして確認
• 根本改善のために：dotnet/maui に Issue を報告

「オフラインでの起動確認」が目的なら、Debug に固執せず、Release を軸にして品質を固める方が結果的に早く、確実です。そのうえで Debug は“起動後の深掘り”に使う――この役割分担が、今回のような環境依存の罠を避けるコツです。