2012-04-08 2 views
1

Nach der Aktualisierung auf ADT r17-Tools haben wir das Problem von einigen Dev-Boxen mit classes.dex-Datei innerhalb der .apk 3.2MB vs 700KB. Zusätzlich zur inflationierten Dex-Datei kann die Anwendung nicht von einem Gerät gestartet werden. Es spuckt eine ClassNotFoundException aus.Android .apk verdoppelt die Größe abhängig von der Dev-Box zur Bereitstellung seit v17 tools

Wir sind ratlos, da alle Projekt-/Eclipse-Einstellungen in allen Dev-Boxen identisch zu sein scheinen.

Das Projekt selbst besteht aus zwei Bibliotheksprojekten und einem Hauptprojekt mit dem supportv4.jar und einem internen Jar.

aktualisieren

ich den Export der Bibliotheksprojekte und die Gläser gewählt (im Hauptprojekt) und es funktioniert, wenn es auf das Gerät einsetzt, wird die APK noch die Größe verdoppeln. Ein weiterer lustiger Teil ist (auf den Boxen funktioniert es nicht) wir haben eine 50% Fehlerrate beim Start (das ist Eclipse friert). Es ist also immer noch im Wesentlichen unbrauchbar. Bei den r16-Tools gab es kein Problem mit irgendeiner Box, die es zum Bauen und Starten brachte.

-Update v0.2

Ich hatte Bibliotheksprojekt 1 hängt von Bibliotheksprojekt 2 und hinzugefügt, um die neccesary Gläser nur zu lib1. Es startet und läuft, aber dauert immer noch 3-4 Minuten pro Änderung an der Quelle zu replizieren/build/deploy und die apk ist immer noch x2 die normale Größe.

-Update v0.3

Noch mehr Spaß, wird es schnell über die Kommandozeile, kompilieren, aber nicht über Eclipse. Ich bekomme immer noch eine sehr große .apk (7,16 MB vs 3.xxMB für eine zuvor "normale" apk).

-Update v0.4

Es stellt sich heraus, sogar mit einer aktualisierten sdk/adt irgend Eclipse Box verwendet adt 15/16 (Hilfe-> über Eclipse -> Einträufeln Details) ohne Beschwerden. Das waren die Funktionsbox ....

UPDATE V0.5

Sie veröffentlichtes Tool r18 heute, welche „Mittel“ die Probleme, aber die apk noch zweimal die „Original“ Größe und die Build dauert eine ganze Weile zu vervollständigen. Am Ende haben wir das Projekt auf ein Projekt konzentriert, keine befriedigende Antwort, aber wir konnten keine weiteren Zyklen mehr verschwenden, um unsere Tools zu debuggen.

Antwort

0

Sie können dies erhalten, wenn Sie die Gläser zu jedem Projekt hinzufügen (wie es in ADT16, usw. gearbeitet hat). Darüber hinaus zeigt ADT17 automatisch Bilder unter libs/an. Wenn Sie also ältere Versionen von jars haben, können Sie Probleme bekommen. Setzen Sie die JAR-Dateien unter die lib/des Bibliotheksprojekts, und entfernen Sie alle JAR-Dateien , die Sie den Hauptprojekten hinzugefügt haben, um Klassenpfad zu erstellen.

+0

Wenn die Gläser nicht identisch sind, dann wird der Compiler das Duplikat auslaufen lassen. – HandlerExploit

+0

ADT17 prüft und gibt einige Warnungen für 'Version' basierend auf der (IIRC) SHA1-Summe aus, aber altes Zeug kann noch enthalten sein: Wenn Sie lib-1.0.jar und lib-2.0.jar unter libs/haben, werden beide hinzugefügt. Details: http://tools.android.com/recent/withwithdependenciesinandroidprojects –

+0

Was bedeuten würde, dass, wenn sie nicht die gleiche Datei sind, sie mehrfach enthalten sein werden, was ich gesagt habe. – HandlerExploit

0

Zusätzlich zu Nikolays Antwort möchten Sie vielleicht in die Proguard-Setup schauen. Das ist jetzt anders und könnte eine ganze Menge Zeug entfernen, wenn Sie r17 gegen eine ältere Version verwenden.

Verwandte Themen