Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Support R8 resource shrinking to reduce app size and resolve Play Console warnings

Abierto
  • ¿Algo no está bien?
#13,252 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
android, csharp
Área
build-system, mobile

Línea de trabajo

Start by reviewing the attached workaround and its setup instructions, then trace the Android SDK’s R8 invocation and AAB packaging path. The issue asks for a supported MSBuild property that preserves managed resources and R8 metadata; done means resource shrinking is enabled in Play Console, protected resource names and IDs remain unchanged, and bundle validation passes.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Area: App+Library Build enhancement
Android framework version

net11.0-android (Preview)

Affected platform version

.NET SDK 11.0.100-rc.2.26504.105 Microsoft.Android.Sdk.Windows 37.2.0-rc.2.84 Bundled R8 9.4.24

Description

Following up on #5203, I’d like to request supported R8 resource shrinking in .NET for Android.

Even with R8 full mode and class repackaging enabled, Google Play Console warns that resource shrinking is disabled.

I tested a local MSBuild workaround across several NativeAOT projects and confirmed two benefits:

  • Modest size reductions: approximately 75–182 KB per signed AAB and 114–214 KB in device-specific installed APK files.
  • Play Console recognizes resource shrinking as enabled, resolving the warning about disabled resource shrinking.

The comparisons used matched builds with shrinking disabled/enabled. Native libraries, assets and manifests were identical within each pair. Installed APK measurements used an arm64 device profile and exclude app data, caches and Android-generated runtime files.

Could resource shrinking be exposed through a supported MSBuild property, with managed resource retention, packaging and R8 metadata handled by the SDK?

Steps to Reproduce

Observed with existing .NET 11 Android applications using NativeAOT:

  1. Build a Release AAB with PublishAot=true and AndroidLinkTool=r8, without custom resource-shrinking integration.
  2. Upload the signed AAB to Google Play Console.
  3. Inspect the bundle’s R8 configuration and optimization recommendations.
  4. Resource shrinking is shown as disabled, and Play Console recommends enabling it.

After adding custom resource-shrinking integration and uploading a new build, Play Console shows resource shrinking as enabled.

Did you find any workaround?

Yes. I implemented a local MSBuild integration using the bundled R8 resource shrinker.

It retains the SDK’s Java inputs, ProGuard rules, mapping and compiler-generated r8.json metadata. Since R8 cannot see managed resource access, it scans NativeAOT input assemblies and generates Java resource roots, conservatively preserving application resources and dynamic string lookups.

The shrunk resource archive is passed into normal AAB packaging and signing. After shrinking, AAPT verifies that protected resource names and IDs remain unchanged. Release builds and bundle validation passed for the tested projects.

Optimized resource shrinking remains disabled: R8 warned about the SDK-generated final Java R fields, so I have not validated that mode. Play Console now checks standard resource shrinking, while optimized resource shrinking remains unchecked.

The workaround depends on SDK implementation details, so built-in support would be preferable.

Attached is an anonymized, source-only version of the workaround, including setup instructions and required NativeAOT compatibility rules, validated with a separate minimal NativeAOT application.

dotnet-android-13252-workaround.zip

Lenguaje dominante
C#
Estrellas
2.1k
Forks
579
Merge medio
1 d 16 h
PR fusionados (30 d)
249

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de dotnet/android

Todos los issues de dotnet/android

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.