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

[R8] Maps and Search SDK consumer rules apply app-wide and significantly restrict optimization

オープン
  • 何か問題がありますか？
#2,731 コメント 0 件 リアクション 4 件 担当者 0 名 GitHub で見る

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
活発
技術スタック
android, kotlin
領域
build-system, devtools, performance

調査の方向性

まず、Maps、Common、Search SDK のアーティファクトにバンドルされている consumer ProGuard ルールを特定し、その調査結果を AGP の R8 設定アナライザーで再現します。グローバルな enum、パッケージ全体、Gson、bindgen、冗長な SerializedName、legacy-package の各ルールを確認します。安全な場合にルールを絞り込むか削除し、JNI、リフレクション、シリアライゼーションの動作を維持できれば完了です。

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

説明

auto-triaged bug :beetle:

Description

The consumer ProGuard rules bundled with the Mapbox Maps and Search SDKs contain several app-wide and package-wide rules that significantly restrict R8 shrinking, optimization, and obfuscation outside Mapbox code.

We found this using AGP’s R8 configuration analyzer.

Versions

  • com.mapbox.maps:android-ndk27:11.16.4
  • com.mapbox.common:common-ndk27:24.16.4
  • com.mapbox.search:mapbox-search-android-ndk27:2.15.0
  • com.mapbox.search:base-ndk27:2.15.0
  • Android Gradle Plugin: 9.3.1
  • R8 full mode
  • proguard-android-optimize.txt
  • Minification and resource shrinking enabled

Highest-impact rules

Global enum rule

com.mapbox.search:base-ndk27:2.15.0 bundles:

-keepclassmembers enum * {
    <fields>;
}

Because this targets enum *, it affects enums throughout the entire application and all dependencies—not only Mapbox enums.

In our application it matches 10,916 fields and prevents shrinking, optimization, and obfuscation for them.

Could this be scoped to Mapbox Search enum types that require name preservation?

Entire Maps SDK package
-keep class !com.mapbox.maps.extension.**,!com.mapbox.maps.plugin.**,com.mapbox.maps.** {
    *;
}

This matches:

  • 748 classes
  • 3,725 fields
  • 4,815 methods
  • 9,288 items total

Could this rule be narrowed to classes and members accessed through JNI, reflection, or serialization?

Entire Mapbox Common package
-keep class com.mapbox.common.** {
    *;
}

This matches:

  • 711 classes
  • 1,405 fields
  • 3,322 methods
  • 5,438 items total

Could this be replaced with surgical rules for JNI-bound or reflectively accessed types?

Entire Gson library

com.mapbox.maps:android-ndk27:11.16.4 bundles:

-keep class com.google.gson.** {
    *;
}

This keeps the complete Gson implementation, including code unrelated to Mapbox.

In our application it matches:

  • 221 classes
  • 469 fields
  • 1,244 methods
  • 1,934 items total

Modern Gson versions bundle their own consumer rules. Could this blanket rule be removed and replaced with rules targeting only Mapbox models that require Gson reflection?

Search bindgen package
-keep class com.mapbox.search.internal.bindgen.** {
    *;
}

This matches:

  • 114 classes
  • 636 fields
  • 820 methods
  • 1,570 items total

If these classes are JNI-bound, could the rule permit optimization or shrinking where native lookup does not depend on the affected symbol?

Redundant rules

SerializedName fields

Mapbox Search bundles:

-keepclassmembers,allowobfuscation class * {
    @com.google.gson.annotations.SerializedName <fields>;
}

This matches 703 fields. The analyzer reports it as subsumed by Gson’s bundled conditional rule:

-if class *
-keepclasseswithmembers,allowobfuscation class <1> {
    @com.google.gson.annotations.SerializedName <fields>;
}

Could the Mapbox copy be removed in favour of Gson’s consumer configuration?

Unused legacy package rules

The following rules match no items in our application:

-keep class com.mapbox.mapboxsdk.log.** {
    *;
}

-keep class com.mapbox.mapboxsdk.text.** {
    *;
}

Could these legacy rules be removed from the current Maps SDK consumer configuration?

Aggregate impact

Accounting for overlap with rules from other dependencies, Mapbox-originating rules uniquely restrict approximately:

  • 25,010 items from optimization
  • 17,046 items from shrinking
  • 15,901 items from obfuscation

These are R8 pre-optimization item counts, not APK byte-size measurements, and some rules are clearly required for correct JNI or reflection behaviour. They indicate the available optimization headroom if the consumer rules can be made more surgical.

Requested improvement

Would you consider reviewing the bundled consumer rules to:

  1. Scope wildcard rules to Mapbox-owned packages.
  2. Preserve only types and members accessed through JNI, reflection, or serialization.
  3. Apply allowoptimization, allowshrinking, or allowobfuscation where safe.
  4. Remove the blanket Gson keep rule and rely on Gson’s bundled configuration.
  5. Remove rules subsumed by dependency-provided consumer rules.
  6. Remove unused rules for legacy Mapbox packages.
主要言語
Kotlin
スター
577
フォーク
161
30日以内にマージされた PR はありません

環境構築

はじめの一歩

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

mapbox/mapbox-maps-android のほかの issue

mapbox/mapbox-maps-android の issue をすべて見る

似ている issue

Kotlin の issue をもっと見る

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

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