.NET 9 / .NET MAUI は Android 16（API 36）をいつサポート？ロードマップの追い方と net9.0-android36 対応の確認手順

Android 16 は従来より早いスケジュール（Q2の大型リリース）で動いたため、アプリ側は「いつ対応できるか」を例年より早い段階で判断する必要が出ました。.NET 9（.NET MAUI / .NET for Android）が Android 16（API 36）に追従できるのか、ロードマップの追い方と実務での備えをまとめます。

.NET 9 と Android 16 の「いつサポート？」が問題になる背景

Android 16 では「年1回のメジャーAPI」だけでなく、より高頻度にAPIを更新していく方針が打ち出され、2025年はQ2にメジャーリリース、さらにQ4に追加のSDKリリースが計画されました。従来より四半期（約3か月）前倒しになることで、アプリ開発者は互換性テスト・CI・依存ライブラリの追従を早める必要があります。

一方で、.NET MAUI / .NET for Android のAndroid対応は「OSが出たら即日OK」という単純な話ではありません。Android SDK（platform.jar）やNDK、ビルドツール、APIバインディングの整備、IDE側の追従など、複数レイヤーの整合が必要です。そのため「Android 16対応の予定日は？」と聞きたくなるのは自然ですが、確認すべき場所を間違えると遠回りになります。

Android 16 の節目を整理：OS公開日とSDK/Platform Stabilityは別

「Android 16 が出る＝その日からすぐ全ツールが対応」ではありません。判断の軸になるのは、少なくとも次の3つです。

節目	意味	開発者が取るべき行動
Developer Preview / Beta	APIが変更され得る段階。先行検証向け。	CIでのビルド確認、主要画面のスモークテスト、問題の早期報告。
Platform Stability	API面が「ロック」され、アプリ影響の挙動が確定する節目。	本格的な互換性テスト開始、ターゲットSDK移行計画の策定。
OSの一般公開（GA）	ユーザー端末に広く届き始める。	端末/エミュレータでの最終確認、ストア配布のリスク評価。

Android 16 は「Q2 2025のメジャーリリース」計画が明確に示され、従来（Q3中心）より四半期早めると説明されています。

また、Android 16 は Beta 3 の時点でPlatform Stabilityに到達したと公式に案内されています。ここが多くのツールチェーンにとって「対応時期を読める」起点になります。

さらに、Android Studio の「SDK Platform release notes」では、Android 16（API 36）のSDKプラットフォームが2025年3月にStable channel（プレビュー終了）になったことが明記されています。つまり「SDKとしては3月に固まった」。

そして OS としての Android 16 は、2025年6月の公開が公式ブログで告知されています。

「.NET 9 が Android 16 をサポートする」とは何を満たした状態？

ここを曖昧にしたまま「いつ対応？」と追いかけると、話が噛み合いません。.NET（MAUI含む）文脈での「Android 16対応」は、実務的には次の複合条件です。

サポートの種類	何ができる状態？	確認ポイント
ビルド時（compile/bindings）	Android 16のAPI（API 36）を参照してコンパイルできる	TargetFramework（例：net9.0-android36）/ Android SDK Platform 36 の有無
ターゲットSDK（targetSdkVersion相当）	アプリが「Android 16をターゲット」として申告できる	ビルド成果物の manifest / Play Console の警告有無
実行時互換（runtime）	Android 16端末で正常に起動・動作する	端末/エミュレータでの実機テスト、既知不具合の有無
IDE/ツール連携	VS/VS Code/SDK Managerが新APIを認識し、エラーで詰まらない	XA5207等の警告、Android SDKのplatform.jar整合

この記事で扱う「いつサポート？」は、主にAPI 36をターゲット可能（compile/target）になる時期と、その情報を確実に追う方法です。

Microsoft Learn Q&A で「対応時期」が確定しない理由

結論から言うと、Microsoft Learn の Q&A は「ロードマップ確定や対応時期を追跡するトラッキングシステム」ではありません。実際に、.NET 9 と Android 16 の対応時期を問うスレッドでは、回答側からQ&Aはトラッキング用途ではないこと、そしてSDKサポートの確認は公式リポジトリへという案内がされています。

同スレッドでは、追跡を楽にするためにスレッドのメール通知を有効化する手順への言及もあります。つまり「いつ頃？」を知りたいなら、Q&Aよりも変更が集約される場所で追うべき、というのが公式のスタンスです。

ロードマップを追う正解ルート：dotnet/android を見る

.NET for Android の一次情報は、GitHub の dotnet/android に集まります。ここで見るべき場所は、主に次の4つです。

見る場所	わかること	検索キーワード例
Issues	不具合、互換性問題、サポート要望、ブロッカー	Android 16 / API 36 / net9.0-android36 / platform.jar
Discussions	方針・設計相談、告知、運用上のベストプラクティス	roadmap / release / workload
Milestones / Projects	（存在する場合）いつ何を入れるかのまとまり	Android 16 / API-36
Releases	実際に「入った」変更（確定情報）	API-36 support / backport / servicing

「予定」を知りたい段階では Issues/Discussions が手がかりになり、「確定」を知りたい段階では Releases が一番強い根拠になります。

通知（ウォッチ）を入れて“追う”のが実務では最速

「気づいたら締切が近い」「気づいたらストア警告が出ている」を防ぐには、追跡の仕組みを作るのが一番です。

GitHubで dotnet/android を Watch（通知）
自分の関心キーワード（Android 16 / API 36 / net9.0-android36）でIssues検索し、該当IssueをSubscribe
Releases をRSSやメールで追う
Learn Q&A を使う場合も、スレッド通知をON（ただしロードマップ確定は期待しない）

Q&A側でも「通知を有効化して追跡しやすくする」旨が案内されています。

結論：.NET 9 は「servicingで API 36 をバックポート」して追従した

「.NET 9 は Android 16 に追従できたのか？」に対して、確定情報として強いのは dotnet/android の Releases です。

dotnet/android のリリースノートでは、.NET 9 Servicing, Android 35.0.78（2025-06-17）において“Backport Android API-36 support”が含まれていることが明記されています。これは.NET 9 系のAndroidワークロードに API 36 対応が取り込まれたことを意味します。

つまり「最初から3か月前倒しで対応していたか？」というより、現実的にはAndroid 16が固まる（Platform StabilityやGA）タイミングに合わせて、.NET 9 へ後追いでバックポートされた、という形です。

時系列で見る：Android 16 と .NET 側の動き

日付	出来事	開発者にとっての意味
2024-11-18	Android 16 Developer Preview開始。Q2 2025のメジャーリリースを明言し、Q3中心から四半期前倒しを説明。	互換性テストの前倒しが必須に。依存ツールの追従遅れリスクが顕在化。
2025-03-13	Android 16 Beta 3 で Platform Stability 到達（API面がロック）。	ツール側が「確定API」に向けて本対応しやすくなる節目。
2025-03	Android 16（API 36）SDK Platform が Stable channel（プレビュー終了）。	CI/ビルド環境に API 36 を安定的に入れられる。
2025-06-10	Android 16 一般公開（公式ブログで案内）。	実機での不具合が顕在化しやすい時期。配布中アプリは実機検証が必須。
2025-06-17	.NET 9 Servicing（Android 35.0.78）で「Android API-36 support」をバックポート。	.NET 9でも API 36 をターゲットできる土台が整う。
2025-11以降	.NET 10 では API 36 が標準（デフォルト）になり、Android 16対応が前提に。	長期運用は .NET 10 へ寄せたほうが追従コストが下がる。

.NET 9 で Android 16（API 36）をターゲットできるか確認する方法

対応可否は「手元のVisual Studioの雰囲気」ではなく、SDKとワークロードが揃っているかで決まります。最低限、次の手順で確認すると迷いません。

手順1：.NET SDK と Android workload を最新化する

.NET for Android はワークロード（workload）として配布・更新されます。dotnet/android のリリースでも、.NET SDK を入れた上で dotnet workload install android、dotnet workload list で確認する手順が示されています。

また、.NET 9 自体もパッチが積み上がるため、原則として「使っているメジャーが同じでも、パッチは最新へ」を推奨します。.NET のダウンロードページでは .NET 9 が STS（標準サポート期間）であることや、更新が継続されることが示されています。

手順2：Android SDK Platform 36 を入れる

API 36 をターゲットするには、Android SDK Manager で Android 16（API level 36） の Platform を導入しておく必要があります。Android Developers のリリースノートでは、Android 16（API 36）が SDK Platforms に存在し、Revision 1 が 2025年3月に安定版になったことが確認できます。

手順3：プロジェクトの TargetFramework を確認・調整する

.NET 9 のAndroidターゲットは、プロジェクト設定（TargetFramework）で実質的に決まります。たとえば .NET 9 では「有効な TargetPlatformVersion が 35.0」といった挙動が報告されており、.NET 9 の標準が API 35（Android 15）寄りであることが読み取れます。

一方、.NET 9 の servicing で API 36 が取り込まれた後は、状況に応じて API 36 を明示してターゲットする形が現実的です。

&lt;!-- Android 15 (API 35) を前提にする例 --&gt;
&lt;PropertyGroup&gt;
  &lt;TargetFramework&gt;net9.0-android&lt;/TargetFramework&gt;
&lt;/PropertyGroup&gt;

&lt;!-- Android 16 (API 36) をターゲットしたい例（環境が対応している場合） --&gt;
&lt;PropertyGroup&gt;
  &lt;TargetFramework&gt;net9.0-android36&lt;/TargetFramework&gt;
&lt;/PropertyGroup&gt;

この「net9.0-android36」相当のターゲットが成立するかどうかは、最終的に導入済みのAndroid SDK（Platform 36）と導入済みの.NET Android workloadに依存します。dotnet/android の .NET 9 servicing リリースには API-36 サポートのバックポートが明記されているため、ここを基準に「自分のバージョンがそこに到達しているか」を判断すると確実です。

Android 16 の前倒しに .NET 9 は「3か月前倒しで追従」できたのか？

Android 16 は Q2 のメジャーリリースとして、従来より四半期早めると公式に説明されています。

ただし、.NET 側が「確定対応」を出せるのは、Android 側でAPI面が固まる（Platform Stability到達など）ことが重要な前提です。Android 16 は Beta 3 で Platform Stability に到達したと明言されており、ここがエコシステム全体の追従を加速させるポイントになります。

さらに .NET 側の動きとしては、.NET 10 のプレビュー段階から Android 16（API 36）バインディングが追加され、TargetFramework を net10.0-android36 にする手順が提示されています。これは「先行検証はプレビューで可能」という典型パターンです。

結局、現実的な結論はこうなります。

プレビュー段階で早期検証（.NET 10 preview など）を回すことはできる
製品としての「確定対応」は、Android側の安定化と、.NET側のservicing/GAのタイミングに影響される
.NET 9 については、API 36 対応はservicingでバックポートされた（確定情報はリリースノートで追える）

実務で困らないための運用：おすすめの判断フレーム

「いつ来る？」を待つより、来ても困らない状態を作るほうが、結果的にコストが下がります。おすすめは次の運用です。

おすすめ運用1：CIで“2系統”を回す

安定系：現在の配布ライン（例：net9.0-android / API 35）
先行系：プレビュー/新API（例：API 36 を入れたビルド・テスト）

これにより、Androidの前倒しリリースや挙動変更に対して「壊れ始めた瞬間」を早期に検知できます。

おすすめ運用2：GitHub Releases を“定期チェック”ではなく“通知で受け取る”

忙しい現場で「毎週見に行く」は続きません。dotnet/android の Releases は、.NET 9 servicing で API-36 をバックポートしたように、最終的な確定情報がまとまります。ここを通知で拾えるようにすると、対応の取りこぼしが減ります。

おすすめ運用3：バージョンアップ判断は「APIデフォルト」と「IDE追従」を含めて行う

たとえば .NET 10 では API 36 がデフォルトになり、Android 16 を前提とした動きになります。

ただし、IDE（Visual Studio / VS Code）側が新APIをまだ認識しておらずエラーになる可能性（XA5207）など、ツール連携の罠もあります。.NET MAUI の .NET 10 情報でも、API 36 がデフォルトになることで IDE 側の追従不足がエラー要因になり得る旨が言及されています。

Android 16 で影響が出やすいポイント（MAUI/Android開発者向け）

「ターゲットできた＝終わり」ではありません。Android 16 はUI/挙動の変更もあり、特にターゲットSDKを上げた瞬間に表面化しがちです。

Edge-to-edge の強制：Android 16 をターゲットすると edge-to-edge をオプトアウトできなくなる旨が、Android 16 の公開記事で説明されています。UI崩れや余白調整が必要になるケースがあります。
16KB Page Size などの周辺要件：Beta 3 の案内でも 16KB Page Size に言及があり、ランタイムやネイティブライブラリを含むアプリは早めの検証が安全です。
ライブラリ依存：SDK/ツール/ライブラリ提供側の準備が遅れると、アプリ側がターゲットSDKを上げられず詰まります。Android側からも、SDK/ライブラリ/ツール提供者に向けて早期準備を促すメッセージが出ています。

「いつ対応？」を最短で見極めるためのチェックリスト

目的	まず見る場所	判断のしかた
対応予定（ロードマップ感）を知りたい	dotnet/android の Issues / Discussions	「Android 16 / API 36」で検索し、担当者コメントやマイルストーンを確認
対応が“入った”かを確定させたい	dotnet/android の Releases	「API-36 support」「backport」など、リリースノートに明記されているか
自分の環境が対応しているか知りたい	dotnet workload list / Android SDK Manager	Android SDK Platform 36 と、該当workloadバージョンが入っているか
Q&Aで聞いてよい範囲か	Microsoft Learn Q&A	ロードマップ確定は期待しない。案内されるのは“公式リポジトリへ”が基本

まとめ

Android 16 の前倒しリリースは、モバイル開発にとって「例年の運用が通用しない」典型例でした。.NET 9（.NET MAUI / .NET for Android）の Android 16 対応時期を追うなら、Microsoft Learn Q&A ではなく、一次情報が集まる dotnet/android の Issues / Discussions / Releases を軸にするのが最短です。

そして実務では「予定日」を待つより、通知とCIの仕組みで先行検証ラインを作り、Releasesで確定したら安全に切り替える運用が最も堅い戦略になります。Android 16（API 36）という変化点を、トラブルではなく“計画的な更新”として扱えるように、追跡ルートを整えておきましょう。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。