あなたの Capacitor Android Gradle Plugin 9 (AGP 9) にアップグレードした後、プラグインが正常に動作しなくなった場合、Gradle の構成問題に遭遇している可能性があります。
この投稿は、以下の一般的な検索意図に焦点を当てています:
- Capacitor プラグインのビルドエラー AGP 9
- Android Gradle Plugin 9 プラグインのビルドエラー
proguard-android.txt見つかりません- AGP 9
getDefaultProguardFileエラー - Capacitor Android のビルドが AGP のアップグレード後に失敗しました
短いバージョン:
proguard-android.txtAGP 9 プラグインのビルドで安全な基準として参照することはもう安全ではありません。- AGP 9 プラグインのビルドに使用する安全な基準を変更してください。
proguard-android-optimize.txt. - 再構築して確認してください。
長いバージョンも重要です。特に、多くのプラグインや大きなCapacitorワークスペースを維持する場合にそうです。
- この記事では、以下について説明します。
- What Capacitor is and how plugin builds work
- __CAPGO_KEEP_0__とは何か、プラグインビルドのしくみ Capgo __CAPGO_KEEP_0__
- はリリースの信頼性にとってなぜ重要か
- AGP 9の変更が古いプラグインテンプレートを破壊する正確なもの
1つのリポジトリまたは多くのリポジトリに対する安全な移行戦略
この文脈におけるAndroidとは何か Androidは、オペレーティングシステムとビルドエコシステムの両方です。AndroidでCapacitorアプリまたはプラグインを配信する場合、プロジェクトは次のプロセスを通過します。
- Gradle ビルドシステムとして。
- Android Gradle プラグイン (AGP) Android用のGradle統合として。
- Android SDK ツールチェーンは、パッケージング、縮小、linting、および生成
.aar,.apk、または.aab出力。
AGPのバージョンが変更された場合、既定値と内部ファイルも変更されることがあります。AGP 8で機能したプラグイン設定は、AGP 9で失敗する可能性があります。削除されたまたは非推奨のベースラインに指示している場合。
What is Capacitor?
Capacitor iOS/Androidアプリをビルドするためのクロスプラットフォームランタイムです。Capgoは、TypeScript、JavaScript、HTML、CSSなどのWeb codeを使用して、native APIを呼びながらiOS/Androidアプリをビルドできます。
Capacitor apps usually include:
- Web層 (UIとビジネスロジック)
- ネイティブシェル (
ios/,android/) - ネイティブ機能をJavaScriptに公開するプラグイン
各プラグインには独自のネイティブビルド構成が含まれます。Androidの場合、これは各プラグインに含まれる android/build.gradle AGPが正しくパースおよびコンパイルする必要がある
If plugin Gradle settings are outdated, the whole app build can fail, even when your web code is correct.
Capgo
Capgo Capacitor
- ウェブバンドルの変更に対するライブ更新 プラグインエコシステムとネイティブ機能パッケージ
- CI/CDフレンドリーな更新ワークフロー
- Capacitor
ライブ更新でも、ネイティブビルドの安定性は譲れません。次の理由で、クリーンなAndroidビルドが必要です:
- App Store / Play Storeのリリース
- ネイティブプラグインのアップグレード
- プラットフォームSDKのマイグレーション
- チームのオンボーディングとCIの信頼性
AGP 9の互換性修正は重要です。プラグイン層の信頼性を維持することで、配信パイプラインの予測性を保つからです。
AGP 9が古いプラグイン設定を破壊する理由
多くのプラグインテンプレートは歴史的に使用してきました:
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
AGP 9のセットアップでは、この古いファイルの参照が失敗する可能性があります。これは、古いテンプレート/設定が、ファイルが期待どおりの場所に存在しないことを意味します。
典型的な症状は、Gradleエラーがビルド assemble, lint、または build フェーズで発生し、プロガードのベースラインリソースが欠落している、またはデフォルトファイル参照が無効であることを示唆しています。
Quick background: ProGuard, R8, とベースライン ファイル
- R8 code Android ビルドの現代的な shrinker/optimizer です。
proguard-rules.proプロジェクト/プラグインのカスタム保持規則がありますか。getDefaultProguardFile(...)Android から提供されるベースラインを挿入します。
参照する場合:
proguard-android.txt-> 旧バージョン、最小限のベースラインproguard-android-optimize.txt-> 現代の最適化ベースライン (現在の設定の推奨デフォルト)
AGP 9 の互換性のために、 proguard-android-optimize.txt 現代の最適化ベースラインに切り替えることが実用的解決策です。
一行の修正
プラグインとアプリ モジュールの Gradle ファイルを更新します:
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
最低限、確認する:
android/build.gradle各プラグインexample-app/android/app/build.gradleプラグインリポジトリ- 新しいプラグインGradle構成を作成する任意のジェネレータ/テンプレートファイル
1つのプラグインの移行ガイド
1. 旧の参照を探す
rg -n "proguard-android\\.txt" android example-app
2.置き換える
perl -pi -e "s/proguard-android\\.txt/proguard-android-optimize.txt/g" \
android/build.gradle example-app/android/app/build.gradle
3. Bun で検証する
bun run verify:android
バッチですべてのプラグインリポジトリを更新する場合:
bun run verify
多くのプラグインリポジトリを1つのワークスペースで管理する場合、自動化する:
次に、トラッキングされているプラグインソースがまだ古いファイルを使用していないことを検証する:
rg -l "proguard-android\\.txt" capacitor-* \
--glob '!**/node_modules/**' \
--glob '!**/.gradle/**' \
--glob '!**/build/**' \
| xargs perl -pi -e "s/proguard-android\\.txt/proguard-android-optimize.txt/g"
__CAPGO_KEEP_0__
for d in capacitor-*; do
[ -d "$d/.git" ] || continue
git -C "$d" grep -n "proguard-android\\.txt" -- || true
done
No matches means the old baseline reference is gone from tracked plugin files.
Capgo のロールアウト状況
Capgo の公式 Capacitor プラグインリポジトリとテンプレートのすべてにこの移行を完了しました。
- プラグインの Android モジュールは、
proguard-android-optimize.txt - プラグインの例の Android アプリも更新されました。
- プラグインのスケルトン テンプレートは、デフォルトで AGP 9 安全な新しいプラグインを作成するように更新されました。
これは、CI に到達する前に AGP 9 アップグレードの一般的なクラスを防ぐためです。
これは、今日はビルドが通っている場合でも重要な理由です。
直ちに失敗を確認できない場合の理由
- CI キャッシュが問題を隠しているため
- プロジェクト間で AGP のバージョンが混在しているため
- ローカル開発でのみ一部のモジュールが再構築されるため
しかし、最終的には、クリーン ビルド、新しい環境、またはアップグレードされた実行者がそれを明らかにします。 その時点で、現在の移行を実行すると、隠れた不安定性が削減されます。
置き換え後もビルドが失敗する場合のトラブルシューティング
確認する点があります:
-
すべてのモジュールはパッチが適用されています。 プラグインモジュール、アプリモジュール、サンプル、テンプレートアセットを確認してください。
-
共有スクリプトに 2 番目の参照がないことを確認します。 すべてのリポジトリ (包括カスタム Gradle スクリプト) を検索してください。
-
キャッシュはクリーンです。 Run、 そして再構築してください。
./gradlew cleanAGP / Gradle / JDK のバージョンは一致しています。 Android ドキュメントでサポートされている AGP バージョンに合ったバージョンを使用してください。 -
CI はローカルと同じバージョンを使用しています。 JDK と Gradle wrapper バージョンを CI で固定して環境の漂白を避けます。
-
あなたは、
-
のみをパッチングしていないことを確認してください。 トラッキングされているプラグインソースを修正するのではなく、トランジエント依存性ディレクトリを修正してください。
node_modulesSEO FAQ: AGP 9 __CAPGO_KEEP_0__ プラグイン ビルド エラー
SEO FAQ: AGP 9 Capacitor plugin build errors
Capgoでどうやって修正するか proguard-android.txt AGP 9で見つかりません
置き換え:
getDefaultProguardFile('proguard-android.txt')
次に、Clean Rebuildを実行してください。
getDefaultProguardFile('proguard-android-optimize.txt')
Capgoの__CAPGO_KEEP_0__プラグインをアップグレードした後でAndroid Gradle Plugin 9でビルドが失敗するのはなぜですか?
Why does my Capacitor plugin build fail after upgrading to Android Gradle Plugin 9?
まだAGP 9プロジェクトで使用している android/build.gradle AGP 9プロジェクトでは proguard-android.txtCapgoの__CAPGO_KEEP_0__プラグインのAGP 9への最速の移行パスは何ですか? proguard-android-optimize.txt.
What is the fastest AGP 9 migration path for many Capacitor plugins?
と実行してください。 git grep と実行してください。 bun run verify:android 代表的なプラグイン。
これは、Capacitor のみの問題ですか?
いいえ。AGP 9 ビルドエラーに似たエラーを発生させるのは、Android モジュール (アプリまたはライブラリ) で、廃止された ProGuard 基準参照を使用している場合です。特に、プラグインエコシステムでは、多くのリポジトリが古いテンプレートを共有しているため、特に目立つようになります。
この移行に関連するキーワードは何ですか?
内部の実行書き方やサポートページでこの内容を記載する場合は、以下の用語を含めてください。
- AGP 9 ビルドエラー
- Android Gradle プラグイン 9 ProGuard ファイルが欠落している
- Capacitor プラグイン Android ビルド失敗
proguard-android.txt置き換えproguard-android-optimize.txt移行
関連リンク
- Android Developers: アプリケーション概要の構築
- Android Gradle プラグイン: リリースノート
- Android code のサイズ圧縮: R8 とルール
- Gradle ドキュメント: ビルドツールの基本
- Capacitor ドキュメント: 公式ドキュメント
- Capgo ドキュメント: 自動更新ドキュメント
最終的なまとめ
AGP 9 のこの問題は単純ですが、多くのプラグインを使用するワークスペースでは見落としやすいです。 proguard-android.txt を proguard-android-optimize.txt すべての関連箇所に置き換えると、Android のビルドが予測可能になります。
Capgo プラグインを使用している場合、このマイグレーションは公式のリポジトリで既に適用されているため、驚きの少ないアップグレードが可能です。