En resumen, esas clases están en la plantilla proguard.cfg porque esas clases se pueden declarar en el AndrodiManifest.xml.
considerar esta aplicación mínima:
CustomTextView.java:
package com.example.android;
import android.content.Context;
import android.widget.TextView;
public class CustomTextView extends TextView {
public CustomTextView(Context context) {
super(context);
setText("The class name of this class is not important");
}
}
ExampleActivity.java:
package com.example.android;
import android.app.Activity;
import android.os.Bundle;
import android.util.Log;
public class ExampleActivity extends Activity {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(new CustomTextView(this));
Log.i("ExampleActivity", "The class name of this class is important");
}
}
AndroidManifest.xml:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.android"
android:versionCode="1"
android:versionName="1.0">
<application>
<activity android:name=".ExampleActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
</intent-filter>
</activity>
</application>
</manifest>
Ahora, sin la línea
-keep public class * extends android.app.Activity
en el Proguard.archivo cfg, proguard podría tener la tentación de cambiar el nombre ExampleActivity
al A
. Sin embargo, no sabe nada de AndroidManifest.xml, por lo que no tocará el manifiesto. Dado que el sistema operativo Android usa nombres de clase declarados en el manifiesto de la aplicación para iniciar una aplicación, el sistema operativo Android intentará crear una instancia de ExampleActivity
, pero esa clase no existirá ya que proguard la renombró.
En el caso de CustomTextView
, que está bien para Proguard para cambiar el nombre con decir B
, porque el nombre de la clase no es importante, ya que no se ha declarado en el manifiesto, sólo se hace referencia por código que Proguard actualizará cuando cambia el nombre de clase de CustomTextView
.
De una forma u otra, todas las clases a las que se hace referencia desde el archivo proguard.cfg de la plantilla pueden declararse en el manifiesto, por lo que proguard no debe tocarlas.
Gracias por entender mi pregunta y por brindar una respuesta tan buena. +1 ya y planeo aceptar +50 tu respuesta a menos que surja algo sorprendente. Ahora las preguntas de seguimiento: ** '# 1.' ** ¿Entiendo correctamente de su respuesta que' -keep' también afecta el mapeo, no solo "optimizando"? ** '# 2.' ** Si las futuras versiones de Proguard son compatibles con AndroidManifest.xml, entonces' -keep' ya no será necesario para las clases antes mencionadas. –
** '# 1.' **: No estoy del todo seguro de lo que quiere decir con" mapeo ". Si quiere decir "cambiar el nombre de las clases", entonces sí, '-keep' evita que procure no solo eliminar la clase sino también cambiar el nombre de la clase. Si "mapear" significa algo relacionado con AndroidManifest.xml, luego no, '-keep' no tiene ninguna relación con' AndroidManifest.xml' en absoluto, que es exactamente la razón por la cual '-keep' es necesario en primer lugar (ver respuesta al # 2). ** '# 2.' ** Sí, si proguard supiera sobre la semántica de AndroidManifest.xml (y cómo modificarla), entonces' -keep' no sería necesario. –