Creo que el problema central es que androidTest es una unidad de compilación diferente. app/src/androidTest se ensambla en app-debug-androidTest.apk mientras que app/src/main se ensambla en app-debug.apk . Por lo tanto, Proguard durante assembleDebug no ve ni incluye app/src/androidTest en la construcción del gráfico de uso de "sacudida de árboles" porque no está disponible en el classpath. En la práctica, significa que el código de la aplicación al que se hace referencia en las pruebas solo se está eliminando.

Este tema se correlaciona con "¿Debo cambiar la visibilidad de privada a pública solo para el acceso de prueba?" dilema Según el tipo de pruebas que esté escribiendo, puede considerar:

• Mantenga siempre los puntos de entrada adicionales de la aplicación (utilizados por las pruebas) en la versión que se puede enviar a los release.apk
• Compile el apk principal de manera diferente al ejecutar la prueba y nuevamente acepte el riesgo de enviar a los usuarios un código que no sea exactamente el mismo que el que se está ejecutando en la prueba.

Desafortunadamente, no conozco ninguna solución automática mágica en este momento (similar al complemento all-open ). Pero es posible resolver el problema de los métodos faltantes caso por caso.

 buildTypes { debug { minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-project.txt', 'proguard-project-ext.txt' testProguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-test-project.txt' } }

• proguard-project.txt - configuración para app/src/main y sus dependencias de implementation
• proguard-project-ext.txt : configuración para app/src/main que contiene -keep instrucciones para cada método/campo utilizado en las pruebas solo que proguard eliminó "falsamente". Prefiero mantenerlo por separado, para eliminar condicionalmente al publicar en Google Play
• proguard-test-project.txt : configuración para app/src/androidTest y sus dependencias de androidTestImplementation . Normalmente contiene -dontwarn net.bytebuddy.** y etc. Aunque tenga en cuenta que el apk de prueba no es compatible con multidex, por lo que es posible alcanzar el método de límite de 65k al incluir demasiadas dependencias.

Consulte android/platform/tools/base/studio-master-dev/./build-system/integration-test/test-projects/minify para obtener la referencia de implementación.

Las compilaciones de test son , de forma predeterminada, siempre compilaciones de debug , incluso cuando se configura un testBuildType , esto tiene que tener config initWith debug , lo que sugiere otra configuración incorrecta. Lo siento por no proporcionar la respuesta esperada, pero esta configuración incorrecta se basa en una cierta concepción errónea. Sugeriría deshabilitar la ofuscación, porque en este caso no tiene sentido, porque este paquete nunca se distribuirá. es posible que ni siquiera sea posible definir las reglas de ProGuard para la aplicación de prueba (que es un paquete en sí mismo). este comportamiento es "por diseño", causado por trabajar contra el marco de prueba... porque la aplicación de prueba no sabrá sobre el mapeo de ofuscación de clase/método del otro paquete de aplicación y, por lo tanto, las posibilidades son bastante escasas, que esto podría alguna vez hacer ejercicio.

Firebase Test Lab Robo UX Test es lo más parecido a lo que efectivamente se demanda.