Wie ich eine Android-App in eine Webseite verwandelt habe

• Travelbound, das Reisepläne, Unterkunftsinformationen und PDFs anzeigt, zeigte im Grunde Inhalte aus dem Web an, brachte dabei aber auch Tracking und Reise-Werbung mit. Daher wurde es durch eine Webseite mit denselben Informationen ersetzt.
• Ein virtuelles Android-Gerät wurde gerootet und der Traffic mit HTTP Toolkit abgefangen. Dabei stellte sich heraus, dass eine API, die Benutzername und Passwort in der URL kombiniert, den gesamten App-Inhalt als JSON zurückgibt.
• Mit einem Ruby-Skript und Cron wird regelmäßig das aktuelle JSON abgerufen und HTML erzeugt; Werbedaten werden ausgeschlossen, nur benötigte Dateien wie Reiseplan und PDFs werden bereitgestellt.
• Die Web-Version ermöglicht Kopieren, Drucken, Speichern, Lesezeichen und Suche, funktioniert auf einer größeren Geräteauswahl und entfernt außerdem den Tracking-Code und die Werbung der ursprünglichen App.
• Die ursprüngliche App wächst von 43 MB nach dem Herunterladen der Inhalte auf 124 MB, während die Webseite 0,05 MB groß ist und selbst optionale Bilder nur 35 MB ausmachen. Für dokumentartige Inhalte, die per HTML und HTTP ausgeliefert werden, ist das Web besser geeignet.

---

Travelbound, für das eine Webseite genügt hätte

• Um den Disneyland-Reiseplan, Transport und Unterkunftsinformationen für die Schule für darstellende Künste des Kindes einzusehen, musste die Travelbound-App installiert werden.
• Der Kerninhalt der App bestand aus Text, Bildern und PDF-Links, die über das Web ausgeliefert wurden.
• Die Funktionen, die sie von einer Webseite unterschieden, waren zwei für Nutzer nachteilige Punkte.
  • Sie übermittelte mit dem Google Account verknüpfte Tracking-Daten an den Entwickler.
  • Sie bewarb andere Reiseangebote desselben Reiseveranstalters unter dem Namen inspirations.
• Eine Webseite würde es ermöglichen, Inhalte zu kopieren, zu drucken, zu speichern, als Lesezeichen abzulegen und zu durchsuchen, sie auf nahezu jedem Gerät zu nutzen und potenziell auch die Barrierefreiheit zu verbessern.

Android-App-Traffic abfangen

• Im Virtual Device Manager von Android Studio wurde ein neues virtuelles Gerät erstellt und geprüft, ob adb shell funktioniert.
• Mit rootAVD wurde ein virtuelles Android-33-Gerät gerootet.

  ./rootAVD.sh system-images/android-33/google_apis_playstore/x86_64/ramdisk.img  
  

• Das Rooten war nötig, damit Apps mit Certificate Pinning dem selbstsignierten TLS-Zertifikat eines Man-in-the-Middle-Proxys vertrauen.
  • Ohne Rooting hätte eine App wie Travelbound das Zertifikat als ungültig eingestuft und die Kommunikation verweigert.
• Nach einem Cold Boot wurde Magisk gestartet und so konfiguriert, dass es su-Zugriff für anfragende Apps automatisch erlaubt.
  • Ohne automatische Erlaubnis startete HTTP Toolkit im nicht privilegierten Modus, ohne auf eine Nutzerantwort zu warten.
• Mit HTTP Toolkit wurde der Traffic des virtuellen Android-Geräts abgefangen.
  • Ein gefälschter VPN-Provider wurde installiert, um den Geräte-Traffic an den Proxy weiterzuleiten.
  • Wegen Android-Sicherheitsbeschränkungen musste das installierte Root-CA-Zertifikat manuell hinzugefügt werden.
• Nach der Installation von Travelbound aus dem Play Store wurde die Konfiguration so angepasst, dass zur Rauschreduzierung nur der Traffic dieser App über den Proxy lief.

API-Aufruf und Datenstruktur

• Die App setzte Benutzernamen und Passwort der Reisegruppe zusammen und rief eine API-URL im folgenden Format auf.

  https://travelbound.api.vamoos.com/api/itineraries/…}  
  

• Benutzername und Passwort waren Zugangsdaten, die von der gesamten Reisegruppe geteilt wurden.
• Das JSON der API-Antwort enthielt alle Inhalte, die die App anzeigte.
  • Ein Array mit den einzelnen Abschnitten des Reiseplans
  • Ein Werbe-Array inspirations
  • Ein Querverweis-Array mit Dateien wie Bildern, auf die andere Abschnitte verweisen
• Sogar der HTML-Code, den die App anzeigen sollte, war in den Daten enthalten; die Art der Inhaltsauslieferung ähnelte also selbst einer Webseite.
• Die S3-Bild-URLs hatten eine vergleichsweise kurze Ablaufzeit, sodass das JSON regelmäßig erneut abgerufen werden musste, auch wenn sich der Inhalt nicht änderte.
  • Eine andere Möglichkeit wäre, die Bilder lokal zu cachen; die ursprüngliche App schien diesen Ansatz zu verwenden.

JSON in HTML umwandeln

• Es wurde ein Ruby-Skript geschrieben und so konfiguriert, dass es nach einem Cron-Zeitplan das aktuelle JSON abruft und eine HTML-Seite erzeugt.
• Bei der Generierung wurden die inspirations-Werbungen, die im Datenschema overlayRows entsprechen, vollständig ausgeschlossen.
• Auf der Webseite wurden nur die folgenden Informationen angezeigt:
  1. Reiseplan-Einträge
  2. Alle Dateien, auf die weder Werbung noch Reiseplan verweisen
• Die zweite Liste diente als einfache Methode, PDF-Download-Links an einer Stelle zu sammeln.
• Die erzeugte Seite wurde mit demselben Passwort geschützt, das der bestehenden Reisegruppe bereitgestellt worden war.
• Das ursprüngliche JSON wurde in ein <details>-Element gelegt, damit später geprüft werden kann, ob Schemadaten auftauchen, die das bestehende Skript noch nicht erfasst.

Eine kleinere und flexiblere Web-Version

• Die Webseite ist nicht so schick wie die ursprüngliche App, aber deutlich kleiner und bietet Web-Grundfunktionen ohne separate Implementierung.
• Inhalte lassen sich kopieren, drucken, speichern, als Lesezeichen ablegen und durchsuchen; außerdem sind sie auf einer größeren Auswahl an Geräten zugänglich.
• Durch Entfernen von Tracking-Code und Werbung wurden auch die zwei unnötigen Funktionen der ursprünglichen App beseitigt.
• Die Barrierefreiheit wurde nicht formell geprüft, aber in der ursprünglichen App gab es Elemente, die mit assistiven Technologien schwieriger nutzbar wirkten als in der einfachen Web-Version.

Vergleich von Größe und Bereitstellung

• Die ursprüngliche Travelbound-App ist anfangs 43 MB groß und wächst nach dem Herunterladen zusätzlicher Inhalte auf 124 MB.
• Die Ersatz-Webseite ist 0,05 MB groß; wenn alle Bilder optional heruntergeladen werden, kommen 35 MB hinzu.
• Der Reisegruppe wurden beide Ansätze mitgeteilt, damit Nutzer zwischen App und Webseite wählen können.
• Für manche Aufgaben ist eine App passend, aber die bereits in HTML geschriebenen und per HTTP ausgelieferten Travelbound-Inhalte sind kein Fall, der eine App erfordert.
• Die Verteilung über App Stores erhöht Kosten und Entwicklungsaufwand; wenn solche dokumentartigen Inhalte auf eine App beschränkt werden, stehen weniger Menschen und weniger Grundfunktionen zur Verfügung als bei einer direkten Veröffentlichung im Web.

[GN⁺]

Meinungen auf Lobste.rs

• Ich bin es leid, dass Dienste, die im Kern nichts weiter als Webseiten sind, zur App-Aufblähung beitragen; gut zu wissen, dass ich damit nicht allein bin.
  Unter Android ist das Erstellen von Verknüpfungen zu Webseiten für Nutzer nicht besonders sichtbar, daher kann ich verstehen, warum Unternehmen Apps bevorzugen. Wenn ein Dienst aber ein Passwort zusammen mit einem App-Link per SMS verschickt, ist eine Web-App am passendsten. Man verlinkt einfach direkt auf die Passwortseite, fertig.
  Im App Store von /e/OS gibt es sogar einen Bereich „web apps“ mit Einträgen wie der Webversion von Google Maps. PWAs selbst sind einfach zu nutzen, aber ich weiß nicht, wie aktiv und sichtbar das Standard-Chrome oder Hersteller-Android das Erstellen von Verknüpfungen anbietet.
  Klar ist: Die aktuelle Vorgehensweise ist nicht für die Nutzer gedacht, und man sollte darüber nachdenken, wie sie verbessert werden kann.

• Für normale Nutzer, besonders für Menschen, die mit Computern nicht vertraut sind, besteht der Unterschied zwischen einer App und einer Webseite praktisch nur in einer Verknüpfung auf dem Desktop oder Homescreen.
  Wenn man Webseiten-Verknüpfungen direkt verteilen könnte, wäre das eine sehr günstige Methode, Apps zu entwickeln, und vermutlich hätten die meisten Apps so gebaut werden können.

  • Wenn man unter iOS in Safari eine Webseite öffnet und über den Teilen-Button, „Mehr anzeigen“ und dann „Zum Home-Bildschirm“ geht, kann man dem Homescreen ein Icon hinzufügen.
    Tippt man auf dieses Icon, öffnet sich kein neuer Browser-Tab, sondern ein eigenständiges Fenster wie bei einer normalen App. Ich habe auf diese Weise ein selbst gebautes Tool für Familienausgaben verteilt, ohne es im App Store zu veröffentlichen.

• Zahllose „Apps“ wären völlig ausreichend, wenn sie einfach Webseiten wären. Es ist frustrierend, wie oft man erst eine App installieren muss, nur um irgendeine kleine Funktion zu nutzen, ohne dass es dafür einen echten Grund gibt.
  Eine App für die Verbindung mit lokalen Geräten zu verwenden, kann ich nachvollziehen; es gibt aber auch Systeme, bei denen die App über einen zentralen Server mit dem lokalen Gerät kommuniziert. Dann fällt sogar der einzige plausible Grund weg, überhaupt eine App installieren zu müssen.
  Das frühe iPhone wollte Webseiten als App-Plattform etablieren, aber am Ende ist daraus das heutige chaotische Ökosystem geworden.