2012-08-24 21 views
6

Ich habe ein WebView in meiner Aktivität und die Verwendung von Proguard zur Verschleierung scheint meine WebView zu durchbrechen und ich verstehe nicht warum.Proguard bricht Android WebView, warum?

Der Code ist ziemlich einfach, ich habe die HTML-Datei in meinem Res/Raw-Verzeichnis, hier ist der Code, der es beim Debuggen gut lädt.

WebView mv = (WebView)findViewById(R.id.webView1); 
mv.loadUrl("file:///android_res/raw/wesite.html"); 

Sobald ich die apk für die Freigabe zu erstellen, es durch proguard läuft es nicht funktioniert, bekomme ich nur die Seite kann nicht geladen werden.

Ich habe noch nichts zur proguard config-Datei hinzugefügt.

Antwort

9

Proguard verschleiert Verzeichnisse so, wenn Sie für android_res/raw suchen, ist es wahrscheinlich nicht mehr so ​​genannt!

Sie können der proguard.cfg-Datei in Ihrem Projekt Regeln hinzufügen, die bestimmte Dateien überspringt. In diesem Fall reicht es aus, die rohe Ressource in den Ordner "Assets" zu verschieben.

Das Problem besteht darin, dass der Webkit FileLoader versucht, Ihre R $ Zeichenklasse mithilfe von Reflektion zu laden. Wenn Sie Ihrer proguard.cfg-Datei keine keep-Regel hinzufügen, wird diese Klasse umbenannt. Daher kann Webkit Ihre Ressource nicht laden. (entnommen aus Prevent Proguard to remove specific drawables).

Aus diesem Grunde ist Android das R-Klasse Benennungssystem für Ressourcen verwendet - eine uniquie Lookup-ID statt Verweisen auf die Dateien, die von ihrem Standort

Durch die Datei in das Vermögen platzieren Ordner Sie das R-Klasse Referenzierung System zu umgehen und Alles sollte gut funktionieren.

Sie sollten Ihre website.html-Datei in den Ordner verschieben Assets und rufen:

mv.loadUrl("file:///android_asset/wesite.html"); 

Wie bei den Link oben vorgeschlagen wird, sollte es möglich sein, die unter der Regel auf Ihre Proguard.cfg Datei hinzufügen zu die Ressourcen Standort stoppen obfucated stattdessen wird: die Verschleierung funktioniert, wie es funktioniert aus einem Grund

-keepclassmembers class **.R$* { 
    public static <fields>; 
} 

-keep class **.R$* 

Bare daran!

hoffe, das hilft

+1

Das obige funktioniert für die Proguard.cnf und Verschieben der Website in den Ordner Assets. Der Code sollte jedoch 'mv.loadUrl (" file: ///android_asset/wesite.html ") lauten;' ** Hinweis: ** 'android_asset' nicht' android_assets'. Ich danke Ihnen für Ihre Erklärung. – Ne0

+0

Sie müssen nicht alle R-Klassen und ihre Felder behalten, es sollte möglich sein, einige Ressourcennamen, die Sie wirklich behalten möchten, auszuwählen und den Rest (z. B. Layout | xml | values) zu verschleiern. – TWiStErRob

-1

zu Datei von rohen Ordner in einem Webview zu laden:

myWebView.loadUrl("file:///android_assets/myfile.html"); 
+0

Das lädt Dateien aus dem Asset-Verzeichnis, nicht das rohe Verzeichnis. Bitte lesen Sie den Beitrag. Das Problem liegt in der Verschleierung von Proguards, nicht im Code. – Ne0

1

einfach das Asset vs Vermögenswerte Debatte zu klären. Der Ordner, in dem Projektverzeichnis sollte „Assets“, wie pro Google Text & Tabellen (siehe unten) genannt werden, während sie für den Zugriff auf Sie „file: /// android_asset /“ verwenden müssen

assets/ Dies ist leer. Sie können damit Rohdaten-Dateien speichern. Dateien, die Sie hier speichern, werden in einer .apk-Datei wie sie sind kompiliert und der ursprüngliche Dateiname wird beibehalten. Sie können dieses Verzeichnis auf die gleiche Weise wie ein typisches Dateisystem mit URIs durchsuchen und Dateien mit dem AssetManager als Bytestrom lesen. Zum Beispiel ist dies ein guter Ort für Texturen und Spieldaten.

Bitte beachten Sie, dass ich keinen Kommentar hinzufügen kann, deshalb habe ich dies als Antwort gepostet.

0

Nur zu aktualisieren, nachdem zu diesem Post von einer neueren Frage geführt worden.

In Android Studio (mindestens 1.0.1) gibt es keinen Unterschied in der Standardstufe der Verschleierung, die in einem Release-Build enthalten ist, wenn Sie Assets oder Res für Ihre Medien verwenden. android_res/raw oder android_asset. Und sie wurden beide immer noch so genannt.

Ich lief apktool auf beiden Builds, erschrocken von den neuesten, mit , größer. Die Größe wurde ausschließlich von meinen Medien verursacht. Beide wurden im Einklang mit anderen Apps im App Store kaum verschleiert. Ressourcen und XML wurden in keinem Fall verschleiert. Die einzige Schwierigkeit, die Reverse Engineering haben würde, ist das Konvertieren des Baksamis nach Java. Ich habe gesehen, dass andere apk besser verschleiert sind, aber meins behielt die ursprünglichen Klassennamen, die ich ihnen gab, wenn auch in mehrere Teile zerlegt.

Ich bin neu in Pro-Wache, lieber C++, aber ich verstehe, dass es standardmäßig für Release-Builds angewendet wird.

+0

set 'minifyEnabled true' (nekrocommement viel) – n00b