Apps lassen sich nicht mehr kompilieren seit update des android sdk's

Willkommen im Club. Auch wir konnten seit erscheinen des SDK14 bzw. ADT14 nix mehr kompilieren. Wir haben Tage damit zugebracht immer wieder alles neu zu installieren etc.. Das diese Nacht in aller Eile erschienene SDK15 hat darauf auch nur begrenzt Auswirkungen. Betroffen sind hauptsächliche alle Eclipse workspaces in denen mit eigenen Android Library Projekten gearbeitet wird. Einige Tipps:

* Wenn Du Library Projekte benutzst dann müssen alle R.* Referenzen, die in "switch()" Statements stehen, in "if-else if" Kaskaden umgewandelt werden. Das betrifft vor allen Dingen die "onContextItemSelected()" und "onOptionsMenuSelected()" Methoden aber auch andere Stellen. Das liegt daran da nun alle R.* Ids nicht mehr "static final" sondern nur noch "static" sind.

* Kontrolliere ob all Projekte, die von Library Projekten anhängig sind, den neuen virtuellen Ordner "Library Projects" haben. Wenn dann noch der alte virtuelle xxx_src Ordner existiert dann lösche diesen xxx_src Ordner.

* Library Projekt Kaskaden über drei Stufen haben wohl generelle Probleme. Dazu gibt es gehörig Fehlermeldungen bei Google, such mal danach.

* Es gibt im Eclipse eine Einstellungsseite auf der man für den ganzen Baum aller Projekte die Reihenfolge für den Compiler einstellen kann. Dort habe ich beginnend mit dem untersten Library Projects bis hoch zu den abhängigen Projekten alles genau eingestellt - und siehe da, jetzt klappt alles. Ich finde die Seite nicht mehr, google einfach mal.

Viel Glück
Harald

— geändert am 28.10.2011, 21:18:12

Bei mir kam das Problem nur bei Projekten die eine Libary includen. Als ich diese neu eingebunden habe, ging alles wieder. Aber nach Harald gibts da ja einige Probleme mehr
MfG

Das kannst Du wohl laut sagen.

Wann kam SDK14 raus? Ist ja schon eine gefühlte Ewigkeit her - dabei war es nur eine Woche voller Neu-Installationen, Löschen, Neu-Installationen, .... Ich stand sogar schon vor dem Kauf eines neuen Rechners - habe aber gerade noch die Kurve bekommen. Ich war kurz davor die Android Brocken hinzuschmeißen. Das Dreckstool Eclipse (www.dreckstool.de) hasse ich schon seit Jahren und dann kommt Google und baut ohne einen Migrationspfad lustig darauf auf.

Lösch mal ADT14 und SDK14 und installiere mal die vorherigen Versionen (ADT12/SDK13). Das geht nicht. Die haben mit Erscheinen von SDK14 erstmalig den Downgrade abgeschaltet. Ich habe mir sogar die ZIPs der alten Versionen besorgt - es geht nicht - gleichzeitig hat Google aber eine fehlerhafte neue Version auf den Markt geschmissen. Wer so was macht der hat bei den ersten Stunden zum Thema Entwicklung schlichtweg nicht aufgepasst. Jetzt haben die diese Nacht hektisch ein SDK15 hinterher geschoben (welches noch nicht einmal ansatzweise die Ankündigungen für SDK15 enthält sondern nur Bugfixes).

Das Problem sind Library Projekte die aufeinander aufbauen. Beispiel:Ich habe unter anderem ein LP A auf das ein LP B aufbaut. Auf A aber auch auf B baut ein LP C auf. Und nun kommt das Endprodukt D welches auf A, B und C aufbaut. Ich habe hier die Krise bekommen. Sobald ich in C eine Resource geändert habe krachte der Compiler mit einem Fehler runter. Ok, sage ich, ändere ich halt nichts. Dann meckerte D das C nicht kompiliert wurde. Häh? Ach ja, jetzt gibts ja JARs und keine virtuellen Sourcefolder mehr. Ok, habe ich diese also reingetrickst. Aha, DEX mag das nicht mehr kompilieren. Argh!!!

Meines Erachtens geht das Android Team falsch vor. Migrationspfade gibt es immer nur nach Lehrbuch - nie nach Praxis. Es ist zwar schön einen glänzenden Klassenbaum zu haben. Der nutzt aber nichts wenn man die Altprodukte und deren Entwickler nicht mitnimmt. Und das erkenne ich bei jedem Versionswechsel.

Beispiel Fragmente. Alle klopfen sich auf die Schenkel. Tolles Konzept. Passt brilliant in den Klassenbaum. Komisch wieso kommen keine Tablet Apps? Ach so, die Entwickler können Ihre Apps quasi neu programmieren. Wie dämlich ist denn das? Meines Erachtens muss ein Erfolg eines Upgrades auch am Migrationspfad gemessen werden. Und kommt mir nicht mit der Compatibility Library. Die ist kein Migrationspfad. Sie hilft nur denen die ihre Apps neu entwickeln.

Heute der nächste Hammer. Seit kurzem ist der sogenannte Streetview in der Map als deprecated markiert. Wundert mich seit ein paar Wochen. Bei StackOverflow kamen ein paar zaghafte Fragen. Darauf gab es dann immer wenig hilfreiche Antworten. Und was muss ich da heute lesen? Maps in Websites kosten jetzt u.U. Geld. Aha, deprecated, Maps in Website kostenpflichtig, 1 und 1 zusammengezählt, mein Verdacht: demnächst gibt's das nicht mehr im Handy ohne Kohle. Und schon wieder lustig die existierende Software umbauen...

Sorry, das musste mal raus.

Ich hatte ähnliche Probleme bei der Umstellung. Mit dem neuen SDK wurde in Eclipse eine neue Art der Einbindung der Library Projekte eingeführt. Meine Probleme konnte ich lösen, in dem ich alle Referenzen der Library Projekte entfernt habe, also über den Android Reiter in den Preferences der Projekte sowie aus den properties-Dateien (project und default). Das Ganze musste ich teilweise auch bei geschlossenem Eclipse direkt über das Dateisystem machen. Außerdem habe ich dabei die gen und bin Verzeichnisse gelöscht. Beim nächsten Eclipse-Start habe ich dann alle Projekte refreshed und gecleaned und anschließend die Library-Dependencies wieder über die Preferences der Projekte gesetzt. Danach hatte ich keine Probleme.

Achja, ich musste natürlich auch die Switch-Case Konstrukte durch If-Else ersetzen.