Zaktualizowane narzędzia SDK i narzędzie ADT do wersji 17, a teraz otrzymuję VerifyErrors

Question

Mam projekt odwołujący się do dwóch projektów bibliotecznych. Po uaktualnieniu narzędzi ADT i SDK do wersji version 17 aplikacja ulega awarii, gdy tylko trafi odwołanie do klasy zdefiniowanej w jednym z projektów biblioteki. Błędy takie jak:

Unable to resolve superclass of Lcom/my/package/name/MyActivity; (118) 
Link of class 'Lcom/my/package/name/MyActivity;' failed 
VFY: unable to find class referenced in signature (Lcom/my/package/name/MyActivity;) 

oraz:

FATAL EXCEPTION: main 
    java.lang.VerifyError: my/package/name/util/SomeClass 
    at my.package.name.App.onCreate(App.java:120) 
    at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:969) 
    at android.app.ActivityThread.handleBindApplication(ActivityThread.java:3925) 
    at android.app.ActivityThread.access$1300(ActivityThread.java:122) 
    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1184) 
    at android.os.Handler.dispatchMessage(Handler.java:99) 
    at android.os.Looper.loop(Looper.java:137) 
    at android.app.ActivityThread.main(ActivityThread.java:4340) 
    at java.lang.reflect.Method.invokeNative(Native Method) 
    at java.lang.reflect.Method.invoke(Method.java:511) 
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784) 
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551) 
    at dalvik.system.NativeStart.main(Native Method) 

(mój pakiet, a zajęcia nie są nazwane w ten sposób, po prostu je modyfikować za zamieszczenie tutaj)

jakieś pomysły na to, co się dzieje tutaj? O ile mogę powiedzieć, nie ma błędów kompilacji i mój projekt wygląda tak, jakby poprawnie odwoływał się do projektu biblioteki.

Answer 1

Miałem dokładnie ten sam problem. Znalezienie tego wpisu: oszczędzaj mi frustracji.

Answer 2

Uff, to było przerażające, ale próbowałem wielu różnych rzeczy, dopóki nie zadziałało. Gdzieś w tym wszystkim to rozwiązało. Mój projekt biblioteczny zawiera garść słoików dodanych do folderu "lib" i dołączonych do ścieżki budowania.

Przeczytałem tę notatkę zmiany dziennika: http://tools.android.com/recent/dealingwithdependenciesinandroidprojects o zmianach w bibliotekach i zależnościach. Zauważyłem to:

Projekty mają foldery źródłowe, a także zależą od Biblioteki i plików jar. Bez innej konfiguracji potrzebnej niż dodawanie Projekty Biblioteka jako zależność w project.properties, ścieżka klasy danego projektu jest automatycznie wypełniane:

The content of the project’s libs/*.jar 
The output of the Library Projects. 
The Library Projects’ libs/*.jar 

z jakiegoś powodu, folderu Mój projekt biblioteki nazwano „lib”, nie „bibliotekami ". Używam go w ten sposób przez prawie dwa lata bez żadnych problemów, ale poszedłem dalej i zmieniłem go na "libs". Następnie odświeżyłem projekt i wyłączyłem flagę "jest biblioteka", a następnie ponownie, aby upewnić się, że zauważyłem tę zmianę.

Ponadto, za pomocą nowych narzędzi, wspominają, że obsługuje on słoiki projektu biblioteki w projekcie odwołującym się do biblioteki. Do tego momentu ręcznie dodałem słoiki projektu biblioteki do projektu referencyjnego. Więc poszedłem do projektu referencyjnego i usunąłem słoiki ze ścieżki budowania. Następnie we właściwościach projektu usunąłem projekt biblioteki i ponownie go dodałem.

Na koniec zauważyłem, że plik JAR był w folderze projektu biblioteki, ale nie był używany. To było właśnie w folderze. Usunąłem ten plik.

Więc gdzieś tam zaczął działać ponownie. Wyobrażam sobie, że prawdziwa poprawka zmieniała "lib" na "libs", ale chciałem się upewnić, czy wspominałem o tym wszystkim na wypadek, gdyby pomagało to innym deweloperom doświadczającym strachu i paniki w ich sercach. Powodzenia!

Answer 3

@kargi

W zasadzie myślę, że rozwiązanie here i here jest bardzo złą praktyką. Maven rozwiązał ten niedorzeczny biznes folderów lib dawno temu, ale Maven nie jest również bardzo wydajny w budowaniu Androida, więc polecam używanie funkcji eksportu Eclipse, jak opisuję here.