2013-10-04 22 views
7

Widzę pewne niewyjaśnione zachowanie Proguard.Dlaczego proguard przetwarza AndroidManifest.xml

AFAIK proguard nie zwraca uwagi na manifest z Androidem. Również w moim proguard.cfg nie wspomnę o klasach powiązanych z BroadcastReceiver. Zakładam więc, że powinny one zostać usunięte.

Jednak widzę coś dziwnego w bin/proguard.txt:

# view AndroidManifest.xml #generated:784 
-keep class com.fiksu.asotracking.InstallTracking { <init>(...); } 

i że klasa (descendand z BroadcastReceiver) nie zostanie uproszczoną. Przyczyna nie mówi nic ważnego:

[proguard] com.fiksu.asotracking.InstallTracking 
[proguard] is kept by a directive in the configuration. 

Jeśli klasa nie jest wymieniona w manifeście, zostaje usunięta.

Dobrze byłoby wiedzieć, dlaczego.

+0

Czy sprawdziłeś '/tools/proguard/proguard-android.txt'. To zwykle zawiera deklaracje, które uniemożliwiają Proguardowi całkowite zamordowanie twojej aplikacji. – Jens

+0

Tak, do mojego zrozumienia nie zawiera ona nic związanego z BroadcastReceivers lub manifestem, lub interpretuję go błędnie. – lstipakov

+0

Definicja sdk zwykle zawiera coś takiego: '-keep public class * extends android.content.BroadcastReceiver', który uniemożliwia zniekształcanie się odbiorników. – Jens

Odpowiedz

9

Proces kompilacji uruchamia narzędzie aapt, aby automatycznie utworzyć plik konfiguracyjny bin/proguard.txt, oparty na AndroidManifest.xml i innych plikach xml. Proces budowania przekazuje następnie plik konfiguracyjny do ProGuard. Tak więc ProGuard rzeczywiście nie bierze pod uwagę AndroidManifest.xml, ale robi to aapt + ProGuard.

+0

Dzięki, Eric! Czy oznacza to również, że nie potrzebujemy już ręcznie dodawać dyrektyw "keep" do nadawców, usług i tak dalej? – lstipakov

+0

@Stipa To prawda. Domyślna konfiguracja w SDK powinna zapewniać wszystkie ogólne ustawienia, aapt powinien tworzyć całą konfigurację specyficzną dla aplikacji (z wyjątkiem refleksji specyficznej dla aplikacji). –