Ich arbeite an einem Worklight-Projekt, das eine ZIP-Datei herunterlädt, entpackt und die Dateien im spezifischen Dokumentenverzeichnis der Plattform speichert (in iOS ist das NSDocumentDirectory). auf Android verwende ich getFilesDir()). Die Datei besteht aus einer HTML-Datei und mehreren Bildern, die sich in einem Unterverzeichnis (Medium) befinden. Das Herunterladen und Entpacken funktioniert auf beiden Plattformen einwandfrei. Nach dem Entpacken verlese ich den Inhalt der HTML-Datei in ein bestehendes div (da es sich um eine Worklight-App handelt, befindet sich alles in einer HTML-Datei).Unbekannter Chromfehler -6 beim Laden von lokalen Bildern in Android Webview
Hier werden Dinge kompliziert: Die Bild-Tag-Quellen in der HTML-Datei, die ich heruntergeladen habe, sind relativ zu der HTML-Datei (z. B. 'media/myimage.jpg'). Wenn ich die HTML-Datei in die Worklight-HTML-Datei einfüge (die sich im App-Paket/Paket befindet), ändert sich die Basis-URL und die Bilder können nirgendwo gefunden werden. Ich habe das behoben, indem ich native Funktionen geschrieben habe, die alle Bild-Tags in der heruntergeladenen HTML-Datei so umgeschrieben haben, dass sie auf eine absolute URL verweisen (iOS: /var/mobile/Applications/<identifier>/Documents/, Android: /data/data/<id>/files/). Dies funktioniert auf iOS, aber auf Android wird der HTML-Code nur teilweise geladen. LogCat dann zeigt:
Unknown chromium error: -6
Wenn ich die Dateien bleiben, wie sie sind, die HTML-Lasten korrekt, aber offensichtlich mit gebrochenen Bilder. Ich habe auch versucht, die URLs in file:///data/data/<id>/files/ [...] zu ändern, was auch dazu führt, dass der HTML-Code nicht vollständig geladen wird. Ich habe wirklich keine Ahnung, was dieses Problem verursacht. Die App hat bereits die Berechtigung WRITE_EXTERNAL_STORAGE.
Hat jemand eine Idee, wie man das beheben kann? Vielen Dank!
Hier finden Sie aktuelle [Android/data/data/mypackage/img] [1] [1]: http://stackoverflow.com/questions/7408838/android-data-data-mypackage -img –
@ René, hast du das gelöst? –
Es stellt sich heraus, dass dieser Fehler durch Bilder mit einer Breite von mehr als 1500 Pixel verursacht wurde. Nach dem Skalieren verschwindet der Fehler. Muss ein Problem mit dem Android-Webview sein, schätze ich. –