In breve, tali classi si trovano nel modello proguard.cfg poiché tali classi possono essere dichiarate in AndrodiManifest.xml.
Considerate questa applicazione minima:
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>
Ora, senza la linea
-keep public class * extends android.app.Activity
nel Proguard.file cfg, proguard potrebbe essere tentato di rinominare ExampleActivity
in A
. Tuttavia, non sa nulla di AndroidManifest.xml, quindi non toccherà il file manifest. Poiché il sistema operativo Android utilizza i nomi di classe dichiarati nel manifest dell'applicazione per avviare un'applicazione, il sistema operativo Android tenterà di creare un'istanza ExampleActivity
, ma tale classe non esisterà da quando proguard lo ha rinominato!
Nel caso di CustomTextView
, va bene per Proguard per rinominarlo dire B
, perché il nome della classe non è importante in quanto non è dichiarato nel manifesto, unico riferimento da codice che Proguard aggiornerà quando cambia il nome della classe CustomTextView
.
In un modo o nell'altro, tutte le classi a cui fa riferimento il file proguard.cfg del modello possono essere dichiarate nel manifest, quindi proguard non deve toccarle.
fonte
2012-01-26 15:09:00
Grazie per aver compreso la mia domanda e per aver fornito una così grande risposta. +1 già e ho intenzione di accettare +50 la tua risposta a meno che non arrivi qualcosa di sorprendente. Ora le domande di follow-up: ** '# 1.' ** Ho capito correttamente dalla tua risposta che' -keep' influisce anche sulla mappatura, non solo sull'ottimizzazione? ** '# 2.' ** Se versioni future di Proguard supportano AndroidManifest.xml,' -keep' non sarà più richiesto per le classi sopra menzionate? –
** '# 1.' **: Non sono del tutto sicuro di cosa intendi per" mappatura ". Se intendete "rinominare le classi", allora sì, '-keep' impedisce a proguard non solo di rimuovere la classe ma anche di rinominare la classe. Se per "mappatura" si intende qualcosa relativo ad AndroidManifest.xml, quindi no, '-keep' non ha alcuna relazione con' AndroidManifest.xml', che è esattamente il motivo per cui '-keep' è necessario in primo luogo (vedi risposta a # 2). ** '# 2.' ** Sì, se proguard conoscesse la semantica di AndroidManifest.xml (e come modificarlo), quindi' -keep' non sarebbe necessario. –