2013-07-22 6 views
6

Als mein Android-Projekt bauen, ich habe folgendes auf die build.gradle Datei hinzugefügt proguard zu aktivieren:Android Gradle build resultierende apk enthält sowohl verschleiert und nicht-verschleierten Klassen

buildTypes { 
    release { 
     runProguard true 
     proguardFile 'proguard-project.txt' 
     proguardFile '../common/proguard-shared.txt' 
     proguardFile getDefaultProguardFile('proguard-android.txt') 
    } 
    } 

Alles baut in Ordnung, aber wenn Ich zerlege die resultierende Dex-Datei, es stellt sich heraus, dass sowohl die verschleierten als auch die nicht verschleierten Dateien vorhanden sind.

Zum Beispiel existieren sowohl common.Base64 als auch common.a, die erste ist nicht verschleiert, während die zweite ist.

Nicht sicher, es ist verwandt, aber das Projekt selbst hat eine nicht-typische Struktur. Dies ist ein Ergebnis von uns mit einer großen Android-Code-Basis mit mehr als 40 Android-Apps. Wir versuchen, einen gruppebasierten Build-Flow Seite-an-Seite der bestehenden Eclipse-basierten Build zu erstellen.

Wenn alles gut geht, beabsichtigen wir, die Dateistruktur zu mehr native Gradle zu ändern und Aromen und Build-Typen zu verwenden, um mit vielen der Bibliotheken, die wir geschaffen haben, um den Mangel an Aromen und dergleichen zu umgehen .

Projekt E verlässt sich oben auf eine Kette von Bibliotheken wie das:

E -> D -> C -> B -> A

z.B. Das E-Projekt hängt von der Bibliothek D ab, die von der Bibliothek C abhängt ... bis hin zu A.

Antwort

7

Nachdem ich das untersucht habe, habe ich herausgefunden, dass dies ein Problem ist, wenn Sie zuerst ohne Proguard erstellen und dann bauen es damit aktiviert. Dies ist auf den inkrementellen Modus von dex zurückzuführen.

Sie können einen sauberen Build nach der Aktivierung von Proguard machen und es wird dies beheben.

Edit: Ich habe zuvor angegeben, dass Sie den inkrementellen Modus in Dex deaktivieren können, aber es stellt sich heraus, dass das tatsächlich nicht hilft!

+0

Funktioniert, danke, @Xav!. Gibt es einen empfohlenen Weg, um vor dem Erstellen eines Veröffentlichungskandidaten "zu erzwingen"? – Guy

+2

Ist '' 'gradle clean assembleRelease''' Arbeit für Sie? –

+0

@ThuyTrinh es tut. Stellen Sie nur sicher, dass Sie das "clean" für alle Abhängigkeiten durchführen (d. H., Wenn Sie ein Projekt mit mehreren Modulen haben, löschen Sie zuerst das root und dann assembly. Geben Sie das Submodul frei, das Sie benötigen). – Guy