.NET MAUIでAndroid API Level 35(Android 15)をターゲットにする完全手順ガイド
Google Play Console から「2025年8月31日までに Target API Level 35 が必須」と警告された開発者向けに、.NET MAUIで android‑35 を指定して配信要件を満たすための、最短ルートと実務の落とし穴をまとめました。現在 net8.0‑android34.0 を使っているプロジェクトを前提に、移行の考え方から .csproj の更新、ビルド&署名、Play への配信確認まで、コピペで使える形で解説します。
結論:API 35 を狙うなら .NET 9 版 MAUI へのアップグレードが前提
- .NET MAUI(.NET 8 系)は 2025年5月中旬でサポート終了になりました。.NET 本体は LTS でも、MAUI は独自のポリシーで早く終わる点に注意。
- API 35(Android 15)を公式にターゲットできるのは .NET 9 版 MAUI 以降です。プロジェクトの TFM は
net9.0-android35.0(もしくはnet9.0-android)へ。 - Google Play の要件では2025年8月31日以降、新規アプリとアップデートは API 35 必須(Wear OS / TV / Automotive は別基準)。既存アプリ継続配信のための救済もありますが、早めの移行が安全です。
なぜ今 API 35(Android 15)が必要なのか
Google Play のターゲット API ポリシーは「最新 Android リリースに追随して一定期限内に targetSdkVersion を更新する」ことを求めます。2025 年の締め切りは以下の通りです。
| 対象 | 要件(2025年時点) | 補足 |
|---|---|---|
| 新規アプリ / アップデート | Android 15(API 35)以上をターゲット | モバイル向け一般アプリ |
| Wear OS / Android TV / Automotive | 多くのカテゴリで API 34 以上 | プラットフォーム別の基準あり |
| 既存アプリ(更新しない場合) | 配信継続のための救済期間が設定 | Play Console 側の案内・申請に依存 |
「アップデートを出さない」という消極策もありますが、審査要件や配信の安定性を考えると、API 35 対応を早期に完了するのが最適解です。
.NET MAUI のサポートポリシーと「.NET 8 でも LTS なのに…」の疑問
混同しがちなポイントは「.NET 本体の LTS」と「.NET MAUI ワークロードのサポート期間」が別物であることです。.NET 8 は LTS ですが、.NET MAUI 8 は 2025年5月でサポート終了。Android など外部依存の更新に追随するため、MAUI は .NET 本体より短いサイクルで入れ替わります。
- .NET MAUI 8:サポート終了(Android 15/SDK 35 の公式対応対象外)
- .NET MAUI 9:現行の安定ライン。API 35 をターゲット可能。リリース種別は STS(2年サポート)
- .NET MAUI 10(.NET 10):次期 LTS ライン(長期運用予定なら将来再移行)
前提条件(Windows / macOS 共通)
- .NET SDK 9 系の導入(
dotnet --infoで 9.x を確認) - .NET MAUI ワークロードの導入/更新(
dotnet workload install mauiまたはdotnet workload update) - Android 15(API 35)SDK と Build-Tools 35.x のインストール
- Windows の場合:Visual Studio Installer から「.NET MAUI」ワークロードに含まれる Android ツールを最新化、または Android SDK Manager で Android SDK Platform 35/Build‑Tools 35.x を追加
- macOS の場合:Android Studio の SDK Manager で同様に API 35 と Build‑Tools 35.x を追加
- JDK 17(.NET Android には同梱の Microsoft OpenJDK が利用されるため通常は追加不要)
- (ネイティブライブラリを使う場合)NDK の整合(ビルド時に自動取得されることが多い)
macOS の IDE 事情:Visual Studio for Mac はすでにリタイア済み。macOS では Visual Studio Code + .NET MAUI 拡張での開発が公式ルートです。Windows は Visual Studio 2022 の最新安定版(17.14 以降を推奨)を使用します。
移行の全体像(5 ステップ)
- ブランチを切る:移行用の長寿命ブランチを作成(例:
feature/upgrade-maui9-api35)。CI も分岐。 - SDK/ワークロードを更新:開発機・CI ともに .NET 9 & MAUI ワークロードを最新化。Android SDK 35 を追加。
.csprojを更新:TFM をnet9.0-android35.0(またはnet9.0-android)へ。複数ターゲットならnet9.0-ios/net9.0-maccatalystなども。- NuGet を更新:Microsoft.Maui.* は 9.* 系、その他ライブラリは .NET 9 対応版へ。
- ビルド・署名・配信:Release で AAB を発行し、Play Console で「ターゲット API レベル 35」を確認。
.csproj 更新例(単一ターゲット)
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net9.0-android35.0</TargetFramework>
<UseMaui>true</UseMaui>
<ApplicationId>com.example.myapp</ApplicationId>
<ApplicationDisplayVersion>1.5.0</ApplicationDisplayVersion>
<ApplicationVersion>15000</ApplicationVersion> <!-- versionCode -->
<AndroidMinSdkVersion>24</AndroidMinSdkVersion> <!-- 既存ユーザー層に合わせて -->
<AndroidEnableProfiledAot>false</AndroidEnableProfiledAot>
<Nullable>enable</Nullable>
ポイント:.NET 9 では net9.0-android34.0 のような「34 指定」は無効です。35.0 のみ有効(もしくはサフィックスを省略して net9.0-android とし、環境の最新 SDK を自動解決)にします。CI の再現性を重視するなら 35.0 を明示するほうが安全です。
.csproj 更新例(マルチターゲット)
<PropertyGroup>
<TargetFrameworks>
net9.0-android35.0;
net9.0-ios;
net9.0-maccatalyst
</TargetFrameworks>
<SupportedOSPlatformVersion Condition="'$(TargetFramework)'=='net9.0-ios'">12.2</SupportedOSPlatformVersion>
<SupportedOSPlatformVersion Condition="'$(TargetFramework)'=='net9.0-maccatalyst'">15.0</SupportedOSPlatformVersion>
</PropertyGroup>
iOS/Mac Catalyst の最小サポートは .NET 9 で若干引き上げられています。既存プロジェクトの SupportedOSPlatformVersion を確認し、ビルド警告が出ない設定に合わせます。
NuGet パッケージの整合チェック
- Microsoft.Maui.* は 9.* 系へ。
Maui.Controls以外にEssentials、Maui.Graphics、Maui.Controls.Compatibilityなども確認。 - CommunityToolkit.Maui や SkiaSharp などネイティブを含むライブラリは「Android 15 対応版」「.NET 9 対応版」かを要チェック。
- 更新がない場合は代替ライブラリへ切替、もしくは一時的に機能を無効化して先に配信要件を満たす判断も現実的です。
ビルドと署名(AAB 出力)
Google Play への公開は .aab(Android App Bundle)が推奨/必須です。CLI なら以下が最小構成です。
dotnet restore
dotnet build -c Release -f net9.0-android35.0
REM AAB を発行(Windows の例)
dotnet publish -c Release -f net9.0-android35.0 ^
-p:AndroidPackageFormat=aab ^
-p:AndroidKeyStore=true ^
-p:AndroidSigningKeyStore="C:\keys\myapp.keystore" ^
-p:AndroidSigningKeyAlias="myapp" ^
-p:AndroidSigningKeyPass="%KEYPASS%" ^
-p:AndroidSigningStorePass="%STOREPASS%"
出力先は bin\Release\net9.0-android35.0\publish*.aab。CI ではシークレットを環境変数で渡し、ログへ出さないように注意します。
Trim/サイズ対策:-p:PublishTrimmed=true は有効ですが、反射多用ライブラリではクラッシュを招きます。トリマーのルート記述子(TrimmerRootDescriptors)や動的アクセス属性で明示してください。グローバリゼーションを簡略化できる場合は InvariantGlobalization=true も有効です。
Play Console で「Target API Level 35」を確認する
- リリース管理から「新しいリリース」を作成し、生成した AAB をアップロード。
- 「アプリのコンテンツ」→「アプリのアクセス権限」や「データセーフティ」も合わせて最新に。
- 「アプリの設定」→「詳細設定」等で ターゲット API レベル:35 と表示されることを確認。
審査に先立つ自動チェックで API レベルや署名の不備は弾かれます。クラッシュ率や ANR の基準にも注意してください。
Android 15(API 35)で遭遇しやすい変化と注意点
| 領域 | 変化・メリット | 注意点/対処 |
|---|---|---|
| ネイティブライブラリのページサイズ | Android 15 では16KB ページサイズが前提になり警告が出るケースあり | XA0141 等の警告が出たら、該当 SO の更新版へ。ベンダー更新を待つ間は影響範囲を確認しつつ一時許容の判断。 |
| 権限モデル / プライバシー | 最新の権限フローによりユーザー信頼性が向上 | バックグラウンド実行やメディア系権限は動作が厳格化。不要権限の削除・初回起動時説明 UI の改善を。 |
| 前景サービス / Job | 省電力保護や実行制限の見直しで電池持ちが向上 | 長時間の前景サービスは審査で指摘されがち。WorkManager 等へリファクタを検討。 |
| ビルド時の互換性 | .NET 9 / SDK 35 でビルドパイプラインが最新に | net9.0-android34.0 は無効。必ず 35.0 かサフィックスなしを使用。 |
トラブルシュート集(実務で多い落とし穴)
NETSDK1140「34.0 は有効な TargetPlatformVersion ではありません」 TFM を net9.0-android35.0 に修正するか、net9.0-android に変更して再ビルド。
<dt>「Android Debug/実機ターゲットが Visual Studio に表示されない」</dt>
<dd>Visual Studio の更新直後に起こりがち。MAUI ワークロードの修復(Installer)と、<em>Android SDK Manager</em> で Platform 35 と Build‑Tools 35.x の再インストールを実施。ADB の再起動も有効。</dd>
<dt>XA0141(SO のアラインメント警告)</dt>
<dd>該当パッケージを最新へ。自作 SO は NDK で再ビルド。配信前に警告ゼロを目指す。</dd>
<dt>AAB 署名エラー</dt>
<dd><code>AndroidKeyStore=true</code> と署名パラメータ(キーストア、エイリアス、パスワード)が正しいか再確認。CI では安全なシークレット管理を徹底。</dd>
<dt>IL トリミングでのランタイム例外</dt>
<dd><code>PublishTrimmed=true</code> で反射使用部が削除されるとクラッシュ。必要型をルート指定、または該当ライブラリのトリミング対応ガイドに従う。</dd>
<dt>macOS での iOS ビルドだけ失敗する</dt>
<dd>.NET 9 の iOS / Catalyst の最小サポートが上がっています。<code>SupportedOSPlatformVersion</code> を見直し。</dd>
</dl>
移行タスクのチェックリスト
| カテゴリ | 実施内容 | 完了基準 |
|---|---|---|
| 環境 | .NET 9 / MAUI ワークロード/Android SDK 35 の導入 | dotnet --info に 9.x が表示、SDK Manager に API 35 が見える |
| プロジェクト | TFM を net9.0-android35.0 に更新、最小 SDK/バージョンコード更新 | Release ビルドが通る |
| NuGet | Microsoft.Maui.* を 9.*、他依存も .NET 9 対応へ | ビルド警告(互換性・非推奨)が解消 |
| 品質 | Android 15 実機/エミュレータで主要フロー検証 | 権限・通知・バックグラウンド実行が正常 |
| 配信 | AAB 署名・アップロード・審査 | Play Console 上で「ターゲット API レベル 35」を確認 |
FAQ:よくある質問
.NET 8(LTS)のまま配信はできないの?
.NET 本体は LTS でも、MAUI 8 は既にサポート外です。API 35 を公式にターゲットするには .NET 9 へ移行してください。
<h3><code>net9.0-android</code> と <code>net9.0-android35.0</code> はどちらが良い?</h3>
<p>どちらでも API 35 を使えますが、<strong>CI の再現性を重視するなら 35.0 を明示</strong>。開発機やビルドエージェントに SDK 35 が入っていないと暗黙解決で齟齬が出ます。</p>
<h3>Wear OS や TV 向けも 35 必須?</h3>
<p>Wear OS / TV / Automotive は<strong>別の基準</strong>が設定されています(多くは 34 以上)。対象プラットフォームごとの Play の要件を確認し、MAUI のマルチターゲットで適切に分岐してください。</p>
<h3>どうしても今すぐ移行できない</h3>
<p>既存アプリを「更新しない」選択で期限をやり過ごすことは可能です。ただし新規公開・アップデートは 35 が必須になるため、<strong>早めの移行計画</strong>を強く推奨します。</p>
サンプル:GitHub Actions で AAB を出力する
name: android-aab
on:
workflow_dispatch:
push:
branches: [ "main" ]
jobs:
build:
runs-on: windows-latest
steps:
- uses: actions/checkout@v4
- name: Setup .NET 9
uses: actions/setup-dotnet@v4
with:
dotnet-version: '9.x'
- name: Install MAUI workload
run: dotnet workload install maui
- name: Restore
run: dotnet restore
- name: Publish AAB
run: |
dotnet publish MyApp/MyApp.csproj -c Release -f net9.0-android35.0 ^
-p:AndroidPackageFormat=aab ^
-p:AndroidKeyStore=true ^
-p:AndroidSigningKeyStore="${{ secrets.ANDROID_KEYSTORE_PATH }}" ^
-p:AndroidSigningKeyAlias="${{ secrets.ANDROID_KEY_ALIAS }}" ^
-p:AndroidSigningKeyPass="${{ secrets.ANDROID_KEY_PASS }}" ^
-p:AndroidSigningStorePass="${{ secrets.ANDROID_STORE_PASS }}"
- name: Upload AAB
uses: actions/upload-artifact@v4
with:
name: appbundle
path: MyApp/bin/Release/net9.0-android35.0/publish/*.aab
Windows ランナーを使う例です。macOS ランナーでも同様に動作します。
移行メリットと将来計画
| 項目 | メリット | 注意点 |
|---|---|---|
| セキュリティ | 最新の権限モデル・プライバシー保護 | 権限の申請タイミングや説明 UI の見直しが必要になることあり |
| パフォーマンス | .NET 9 ランタイムの最適化、AOT/Trim でサイズ削減 | トリミングの除外設定が不足するとランタイム例外の原因に |
| 将来対応 | Play 要件を早期に満たし、審査での摩擦を低減 | .NET 9 は STS。長期安定が必要なら .NET 10(LTS)への再移行も計画 |
(補足)macOS 開発の最適構成
macOS では Visual Studio Code + .NET MAUI 拡張が第一選択肢です。Android ターゲットのみなら Mac 単体で完結します(iOS も扱う場合は Xcode 等のセットアップが別途必要)。Windows ベースでの開発を継続したいチームは、クラウドや仮想環境の Windows に Visual Studio 2022 を用意するのがシンプルです。
まとめ:API 35 対応の最短ルート
- .NET MAUI 9 へアップグレード(.NET MAUI 8 はサポート終了済み)
- Android SDK 35 / Build‑Tools 35.x を導入
net9.0-android35.0に TFM を更新(複数ターゲットは iOS / Catalyst も 9 系に)- NuGet を最新化、Release ビルドで AAB を出力し、Play Console で「API 35」を確認
- .NET 9 は STS。長期運用なら将来の .NET 10(LTS)移行も見据える
以上を踏まえれば、「Target API Level 35 必須」の壁はテクニカルには難しくありません。ポイントは「MAUI は .NET 本体とサポート期間が違う」「.NET 9 では 35 以外の Android サフィックスは無効」という 2 点。これを押さえ、環境と依存を丁寧に更新すればスムーズに通過できます。

コメント