Air Applikation und flashlog.txt

Friday, June 24. 2011

Unter XP war das alles gar kein Thema, die installierte Air Appl. schrieb ihre Traces in die Datei flashlog.txt und gut. Aber auf Linux? Denn natürlich trat der Fehler, den ich suchte, nur auf, wenn die Anwendung unter Linux lief...

Ich dachte zunächst, dass auch für AIR der installierte flashplayer entscheidend sei (und für Linux 64 baut Adobe keinen debug-flashplayer). Aber in einer vm mit Mint/32, debug-flashplayer, korrekter mm.cfg und allem blieb die Air trotzdem stumm.

Etwas Suchen musste ich schon bis ich hier den entscheidenden Hinweis fand: 
cd /opt/$applName/share/META-INF/AIR
touch debug

(Für $applName natürlich den Namen der jwlg. Applikation einsetzen...) Die Appl. neu starten und nun schreibt sie ihre traces brav nach ~/.macromedia/Flash_Player/Logs/flashlog.txt

Mit Flex 3 eine air app als Installationspaket packen geht ja erstmal ganz leicht, Project/export release build  und der wizzard macht es. Anschliessend sind (appName).swf und (appName)-app.xml in der .air, die letztlich auch nur ein .zip mit kleinen Extras ist.
Hakelig wurde es mir erst, als ich zu diesen beiden noch weitere Dateien  (und Verzeichnissbäme) zufuegen wollte.

Relevante Einträge im properties-wizzard sind 'Flex Compiler / Compuiler options: Copy non embedded files to output folder ' und dann im export release build - wizzard die letze Seite, wo man zu integrierende Ressourcen auswählen kann. Wenn sie denn gelistet werden. Was dort gelistet wird, gilt. Die Regeln dafür, was dort gelistet wird, sind nicht eben intuitiv. 

Basis dessen ist der Ordner (projektOrdner)/bin-release. Was man vor einem release build in einen solchen Ordner kopiert oder linkt, wird im dann erzeugten .air enthalten sein.
Problem gelöst - nur leider: als naechstes wird der ganze Folder bin-release gelöscht und neu aufgebaut, mit dem Minimal-'Content  (appName).swf und (appName)-app.xml . Alles, was man da gesammelt hat, ist weg, und wenn man (wie hier, mit unterliegendem ext-Dateisystem) die Inhalte des bin-release per symLink eingestellt hat, ist auch gleich noch die Quelle des Links gelöscht. Einfach super. Alle Versuche, per Ownership oder Permissions oder HardLink oder was dies Löschen zu verhindern, führen zu bitterlichen Message-Boxen und sonst nirgendwohin.

bin-release ist hier also ein - mittelfristig gesehen - dynamisches Verzeichnis und definitiv nicht der Ort, um irgendwas wichtiges abzulegen / anzusiedeln. Es gibt ein best practice / howto von adobe, das ernstlich empfiehlt, bei jedem release-build die Dateien/Ordner hier neu einzukopieren. Ja danke, man nennt sowas glaub' ich Sollbruchstelle. Oder broken design, oder so...
Faktisch ist die Quelle für den Aufbau des dynamisch erzeugten bin-release der Inhalt des src/, aber...:

  • Verzeichnisse oder Verzeichnisbäume, die nicht wenigstens eine 'akzeptable' Datei enthalten, werden ignoriert
  • *.as und *.mxml sind *nicht akzeptabel*
  • wenn man also, wie ich, die Sache mit einem 'leeren' Verzeichnisbaum und einem Verzeichnis mit zwei .as testet, sieht man nichts.

Entfernt in dem Zusammenhang: Ein Blog - Labor zu headless building on Linux

In einem früheren Eintrag hatte ich ja mal über die Mühen der Installation von Adobe Air unter 64 Bit Linux geschrieben, irgendwie habe ich es dann doch hinbekommen. Ich arbeite derzeit selbst an eine air app und brauchte es. Ok, mein debian squeeze kde 4.4.5 listet mir nun unter K / utilities den Ad. Air Installer, mit dem ich mir ein *.air package installieren kann. Läuft, wunderbar, beim naechsten Versiönchen will ich den neuen Stand installieren: geht nicht, eine app dieses Namens sei schon vorhanden. Mh, das lässt sich ändern, kurz mal auf /opt/ und da steht die App, F8 und weg ist sie. - Von wegen!

Der Installer rödelt jetzt eine Weile und meldet dann, es habe ein Problem gegeben, sowas wie Fehler 1, und ich solle doch mal den Autor der Appp fragen. Fein! Wer immer sich solche Texte ausgedacht hat, in meinen Augen hat er sich eine rekursive Bastonade verdient. Wenn man sich schon die Mühe einer Messagebox macht, warum kann da dann nicht etwas stehen wie " schauen sie doch mal in $LogDatei, wo wir die richtige Fehlermeldung für sie versteckt haben"

 cat ~/.appdata/Adobe/AIR/Logs/Install.log  in meinem Falle, und dort findet sich dann auch der Text zur Fehlernummer: 
error 1  error: dpkg: Fehler beim Bearbeiten von /tmp/FlashTmp.xme90K/setup.deb (--install):; Versuch, »/opt/airBase/share/mimetype« zu überschreiben, welches auch in Paket  airbase.6eb066ed6af4d1c4f05c36654e32b365cae9a188.1 v1 ist;

Aha, deshalb das anfängliche Rödeln: der Air Installer hat das .air in ein .deb umverpackt und an dpkg übergeben. 
dpkg -l|grep airbase (der momentane Arbeitstitel meines vorhabens) zeigt mir das installierte app,
dpkg -r PAKETNAME
macht es weg und dann tut auch der Installer wieder.

Nun, es geht auch mit Software-Center/Installierte Anwendungen und jemand hat sogar einen speziellen Uninstaller for Adobe AIR geschrieben.

"Die Adobe® AIR™-Laufzeitumgebung ermöglicht den Einsatz bewährter Web-Technologien für die Entwicklung plattformübergreifender Rich-Internet-Anwendungen für den Desktop."

Ok, ein kleines "Hallo welt" angelegt und als .air exportiert, rüber zum Linux desktop (Ubuntu 8.04 64 Bit LTS) und die .air angeklickt: wird als .zip-Archiv erkannt und geöffnet. Ein INSTALL ist nicht zu sehen, also wohl erstmal zu Adobe und die runtime herunterladen.

http://get.adobe.com/de/air/ erkennt mein OS und schlägt gleich AdobeAIRInstaller.bin vor, der download geht fix und dann eine shell im Download-Verzeichnis geoeffnet,

chmod 755 AdobeAIRInstaller.bin
./AdobeAIRInstaller.bin

und schon habe ich eine wunderschöne Fehlermeldung
Error loading the runtime (libnss3.so: wrong ELF class: ELFCLASS64)

Fein, Google findet mir Leidensgefährten und so bin ich bald auf Adobes Knowledgebase mit einer Installationsanleitung, die mich die fuer die runtime benötigten 32Bit-Libs manuell installieren lässt, inclusive eines getLib - Tools und zweier Fehler.

So wird man in Schritt 10 aufgefordert, Symlinks fuer die einkopierten libs zu legen:

$ sudo ln -s /usr/lib32/libnss3.so.1d /usr/lib32/libnss3.so $ sudo ln -s /usr/lib32/libssl3.so.1d /usr/lib32/libssl3.so $ sudo ln -s /usr/lib32/libnspr4.so.0d /usr/lib32/libnspr4.so

fehlt aber eine:

$ sudo ln -s /usr/lib32/libsmime3.so.1d /usr/lib32/libsmime3.so

sonst bekommt man eine vertraute Fehlermeldung. Und wer (wie ich) die Anleitung mit copy/paste abarbeitet, stolpert auch noch über den typo im Programmnamen.

Nach der kleinen Hürde startet der Installer nun endlich und tut auch, was man von ihm erwartet, im Menü findet man dann unter /Applications/Accessories zwei Einträge füer den Adobe Air Application Installer und Uninstaller. 

Aber jetzt nicht zu früh freuen und darauf klicken - dann passiert nämlich gar nichts. Stattdessen den Pfad zu dem neuen Programm finden und in der shell aufrufen

 /usr/bin/Adobe\ AIR\ Application\ Installer

 um die aktuelle Fehlermeldung zu sehen:

Error loading the runtime (libadobecertstore.so: cannot open shared object file: No such file or directory)

Dagegen hilft:

 cp /usr/lib/libadobecertstore.so /usr/lib32

und dann, dann geht es tatsächlich. Eindrucksvoll, und kaum aufwendiger als die Installation eines CD-Rom-Laufwerks unter Dos 4. 

Unter Windows 7 (Prof. 64) wollte sich die HalloWelt.air nicht installieren lassen, der Installer startete, liess sich die Erlaubnis zur Installation erteilen und kam alsbald mit der Mitteilung:

"Leider ist ein Fehler aufgetreten.

Die Anwendung konnte nicht installiert werden, da die AIR-Datei beschädigt ist. Bitten Sie den Anwendungsautor um eine neue AIR-Datei."

Leidensgefährten, aber keine Lösung, auf die rechte Spur brachte mich schliesslich Adobes Troubleshoot Adobe Air Installation Issues mit dem Tip, das .air auf den desktop zu kopieren und von da zu installieren. Offenbar kann der Application Installer mit Netzwerklaufwerken nicht umgehen.

Noch ein Nachtrag, bei der Installation des FlashPlayer unter Linux-64 hilft diese Anleitung

(Page 1 of 1, totaling 4 entries)