Seit Freischaltung der Discover UI zeigt der Homescreen der NVIDIA Shield genau wie die meisten anderen Android-TV-Geräte Werbung an. Im oberen Drittel des Bildschirms sowie im Hintergrund werden Anzeigen für Abonnements und Sendungen eingeblendet und will man versuchen, die Vorschäge auch nur geringfügig anzupassen (Registerkarte “Discover”), so soll man Google gleich das Tracken aller Aktivitäten erlauben.

Da dieser Mechanismus zentral von Google gesteuert wird, hat NVIDIA auch keine Chance, hieran etwas zu ändern.

I did check with the developers team and has been informed that it is indeed an implementation of Google’s Discover UI, which is part of the Android itself. Nvidia is only the manufacturer of the hardware and we do not have control over the User interface of Android. This is not just specific with Shield, but is already being implemented on all Android tv boxes. [Quelle]

Konnte man mit der Version 8.2.3 noch zur alten UI zurückkehren, in dem die vorhanden Updates für die Android TV Home-App deinstalliert wurden, wird die aktualisierte App seit Version 9.0.0 direkt mit dem Betriebssystemupdate ausgeliefert.

Eine Möglichkeit, zu einem werbefreien Startschirm zurückzukehren, ist die Installation eines alternativen Launchers, welche die Android TV Home-App ersetzt. Hier kann z.B. der quelloffene FLauncher direkt über den PlayStore installiert werden. Dieser ist anschließend unter “Apps” zu finden und kann erst einmal ausgiebig konfiguriert und getestet werden.

Sofern die Tests zufriendenstellen verlaufen, kann der Launcher auch dauerhaft als Alternative verwendet werden. Hier hatte NVIDA eine direkte Auswahlmöglichkeit implementiert, wurde aber ebenfalls von Google ausgebremst.

Back on shield experience 8.0.1 we enabled 3rd party launchers. We were the only device with this feature and other manufactures went to Google asking why we could do this and they could not. As a result, we had to disable the ability to select a 3rd party launcher (without doing adb commands) on all future releases in order to get through the google release process. [Quelle]

Glücklicherweise hat man als Android-Nutzer aber trotzdem noch eine Chance, das Verhalten wie gewünscht zu ändern - wenn auch etwas unkomfortabler über die adb-Schnittstelle.

Hierzu werden zuerst auf der Shield die Entwickleroptionen freigeschaltet: Im Menü auf “Geräteeinstellungen”, dann auf “Info” und in der Zeile “Build” insgesamt sieben mal auf die OK-Taste drücken, bis eine entsprechende Meldung erscheint.

Anschließend wird das “Geräteeinstellungen”-Menü am Ende um den Punkt “Entwickleroptionen” ergänzt. Dieser wird nun geöffnet und unter “Debugging” der Punkt “Netzwerk-Debugging” aktiviert. Nach erfolgreicher Aktivierung erscheint der Text “Aktiviert auf a.b.c.d:5555”

Nun wird auf einem PC eine aktuelle Version der Android SDK Platform Tools benötigt. Diese gibt es sowohl für Windows, Mac OS und Linux direkt bei Google zum Download. Wer Linux verwendet, kann direkt auf wget zurückgreifen:

$ wget https://dl.google.com/android/repository/platform-tools_r31.0.3-linux.zip

Sind die SDK Platform Tools heruntergeladen und entpackt, so kann im Verzeichnis “platform-tools” direkt mit adb gearbeitet werden. Nach Eingabe von (natürlich sind a, b, c und d mit der oben angezeigten Adresse zu ersetzen)

$ ./adb connect a.b.c.d:5555

muss auf der Shield der Dialog “Netzwerk-Debugging erlauben?” mit “ERLAUBEN” bestätigt werden. Anschließend wird die Verbindung überprüft:

$ ./adb devices
List of devices attached
a.b.c.d:5555 device

Sofern das Gerät angezeigt wird und verbunden ist, fehlt lediglich noch ein Befehl:

$ ./adb shell pm disable-user --user 0 com.google.android.tvlauncher

Beim Druck auf die “Home”-Taste der Fernbedienung wird automatisch FLauncher gestartet (da einziger verfügbarer Launcher) und als Standardanwendung eingerichtet. Sollte eine Rückkehr zum Standard-Android TV Home notwendig sein, so reicht das Ausführen des oben genannten Befehls mit dem Parameter “enable-user” statt “disable-user” un diesen wieder zu reaktivieren.

Seit einem Monat stellt unser Auto seine Mobilfunkverbindung über eine Vodafone CallYa Classic-Karte her. Wie im Beitrag “Vodafone CallYa Classic und das MB-Rätsel” geschildert, gibt Vodafone einen Preis von 3 Cent pro verbrauchtem Megabyte an, liefert aber keinerlei Informationen, nach welchem System ein Teilverbrauch abgerechnet wird. Alles, was von Kundenseite an Verbrauchswerten und Abrechnungsdaten ersichtlich ist, ist das aktuelle Guthaben unter “MeinVodafone”.

Ein Erster Verbindungstest (einmal Online-Verkehrsdaten abrufen) hat das vorhandene Guthaben um 1 Cent reduziert, d.h. es ist klar, daß wohl nicht nur in vollen MB-Schitten sondern in Teilen davon abgerechnet wird. Die Monatsbilanz fällt zufriedenstellend aus: für eine unbekannte Zahl an verbrauchten MB, aufgeteilt auf eine nicht näher protokollierte Anzahl von Fahrten innerhalb eines Monats wurden insgesamt 43 Cent berechnet.

Passt.

Ausgangssituation

Die Debian-Veröffentlichungen gliedern sich in drei Varianten, von denen “stable” für die Verwendung durch den Ottonormalbenutzer empfohlen wird:

The release of Debian called “stable” is always the official released version of Debian. Ordinary users should use this version. [Quelle]

Stabil bedeutet hierbei

once released, the operating system remains relatively unchanging over time. [Quelle]

Im Rahmen eines sog. Freeze werden zu einem bestimmten Zeitpunkt Programme in den zu diesem Zeitpunkt aktuellen Versionen eingefroren, welche dann Teil der nächsten “stable”-Veröffentlichung werden. So war zum Beispiel bei der Veröffentlichung von Debian 10 Libreoffice 6 aktuell und ist auch zum jetzigen Zeitpunkt in Debian 10 noch enthalten, der Wechsel zu Version 7 wurde erst mit Debian 11 durchgeführt.

Dies garantiert eine weitestgehend stabile Arbeitsplattform, auf der nicht durch Updates bestehende und funktionierende Prozesse gefährdet werden, da i.d.R. nur sicherheitsrelevante Änderungen in einmal veröffentlichte Programmpakete integriert werden.

Es gibt nur wenige Ausnahmen von diesem Schema, eine davon ist Firefox, welcher von Debian in der ESR (Extended Support Release)-Version ausgeliefert wird.

Leider reicht aber der verlängerte Support-Zeitraum der ESR-Versionen nicht aus, um die komplette Lebensspanne einer Debian-“stable”-Veröffentlichung zu begleiten, so daß innerhalb einer Stable-Version das Firefox ESR-Paket aktualisiert werden muss. Aktuell steht der Wechsel von Version 78 zu Version 91 an, der sich leider auf Grund einiger Randbedingungen spürbar verzögert.

Die Betreuer des Pakets laden nicht nur das fertige Binärpaket von der Mozilla-Website und verteilen es neu, es wird stattdessen eine eigene Version von Firefox aus dem öffentlich zugänglichen Quelltext gebaut und verteilt, wozu aber erst zahlreiche hierfür verwendete Werkzeugpakete angepasst werden müssen, was Zeit benötigt.

Lösungsmöglichkeiten

Da der Einsatz des nicht mehr aktuellen Browsers auf Grund mehrerer Sicherheitslücken nicht mehr empfehlenswert ist, gibt es verschiedene Möglichkeiten, zumindest temporär auf eine aktuellere Version auszuweichen, bis eine aktualisierte Browserversion bereitgestellt wird.

Flathub / snap

Vorteil (oder Nachteil) der Lösung ist, daß nicht nur die Anwendung heruntergeladen wird, sondern auch alle Bibliotheken, welche die Anwendung zur Laufzeit benötigt und die Anwendung mit “ihren” statt den im System installierten Bibliotheken ausgeführt wird. Somit müssen nicht wie bei einem “normalen” System die passenden Bibliotheken systemweit installiert werden, sondern die Anwendung kann gekapselt mit den für sie zuständigen Bibliotheken laufen, während der Rest des Systems andere Versionen verwenden kann.

Nachteil ist, daß irgendwelche Bibilotheken im Zweifelsfall mehrfach auf dem System vorhanden sind und falls der Ersteller des Pakets z.B. eine Bibliothek, die Sicherheitsprobleme hat, nicht aktualisiert, ist und bleibt das eben so. Mit ein bißchen Pech wird somit durch die Hintertür die Systemsicherheit ausgehebelt. Ob es dann reicht, daß die unsichere Bibliothek in der jeweiligen Umgebung läuft, bleibt im Ernstfall spannend …

Da es sich um eine temporäre Zwischenlösung handeln soll, ist dieser Ansatz nur dann interessant, wenn aus anderen Gründen sowieso bereits eine der beiden Umgebungen in Betrieb ist.

Direkter Download von Mozilla

Hier wird lediglich die aktuelle Binärversion des Browsers heruntergeladen, entpackt und in das System eingebunden. Für den geplanten Einsatzzweck also perfekt geeignet.

Umsetzung

Als erstes wird die aktuelle ESR-Version von der Mozilla-Website heruntergeladen:

$ wget 'https://download.mozilla.org/?product=firefox-esr-latest-ssl&os=linux64&lang=de' -O "$HOME/Downloads/firefox-esr.tar.bz2"

und dann nach “/opt” entpackt:

$ cd /opt
$ sudo tar xfvj "$HOME/Downloads/firefox-esr.tar.bz2"

Theoretisch gäbe es auch die Möglichkeit, die Dateien innerhalb des “$HOME”-Verzeichnisses zu entpacken und zu verwenden, aus Sicherheitsaspekten ist davon aber abzuraten: der Browser hat standardmäßig Schreibrechte im kompletten “$HOME”-Verzeichnis und könnte somit im Schadensfall auch die eigenen Programmdateien modifizieren.

Als letzter Schritt muß noch die “.desktop”-Datei angepasst werden. Unter GNOME kann dies wie folgt erledigt werden:

$ cp /usr/share/applications/firefox-esr.desktop ~/.local/share/applications/

Anschließend die soeben kopierte Datei bearbeiten

$ vi ~/.local/share/applications/

und den Pfad in der Zeile

Exec=/usr/lib/firefox-esr/firefox-esr %u

in

Exec=/opt/firefox/firefox %u

ändern. Nach einmal ab- und wieder anmelden wird von der kompletten Oberfläche die neu installierte Version verwendet. Da sich Firefox 78 und 91 auch optisch deutlich unterscheiden, ist die Ausführung des neueren Browsers jederzeit klar erkennbar und man braucht nicht panisch nach jedem Browserstart die Version zu kontrollieren.

Der so installierte Browser läuft hier seit einiger Zeit problemlos, lediglich beim ersten Start musste das richtige Profil gewählt werden.

Sobald Firefox 91 ESR in Debian integriert ist, reicht es, den Ordner “/opt/firefox” sowie die Datei “~/.local/share/applications/firefox-esr.desktop” zu löschen.

Damit unser Auto unterwegs Live-Verkehrsinformationen herunterladen kann (und nicht TMC benutzt), benötigt es eine WLAN-Verbindung. Diese kann entweder über die Tethering-Funktion eines Smartphones oder über einen dedizierten WLAN-Hotspot bereitgestellt werden. In einem Durchschnittsmonat werden insgesamt rund 20 MB an Datenvolumen für das Herunterladen der Verkehrsinformationen verbraucht, weshalb sich die Suche nach einer passenden Mobilkarte als durchaus interessant gestaltet.

Die meisten Provider bieten als kleinste Pakete rund 500MB Datenvolumen für rund 2,99€ / Monat an, was zwar finanziell überschaubar aber trotzdem eigentlich zu viel Geld für jede Menge ungenutztes Volumen bedeutet. Alte Tarifmodelle wie Congstar 100MB für 1,99€ / Monat sind leider nicht mehr erhältlich.

Der wahrscheinlich interessanteste aktuelle Tarif ist Vodafone CallYa Classic, welcher mit Kosten von

3 Cent pro MB mit Vodafone 4G|LTE Max

wirbt. Leider ist die genaue Berechnung des verbrauchten Datenvolumens nirgendwo öffentlich dokumentiert und auch ein Anruf bei der CallYa-Hotline brachte keine Erleuchtung (außer der Information, daß diese Frage dem Mitabeiter noch nie jemand vorher gestellt hatte).

Verschiedene Modi erscheinen möglich:

• Beim Verbrauch des ersten Byte werden 3 Cent berechnet und dann wird so lange addiert, bis das MB überschritten ist. Dann beginnt ein neues MB, es werden wieder 3 Cent berechnet und das Muster setzt sich fort.

• Eine daraus abgeleitete Variante könnte bedeuten, daß die verbrauchten Daten addiert werden, eine Berechnung aber erst stattfindet, wenn ein MB überschritten wurde.

• Der Verbrauch wird über einen Zeitraum addiert und dann auf volle MB gerundet. Hier ist der Zeitraum entscheidend, wie sinnvoll der Tarif für den geplanten Einsatzzweck ist.

• …

Da es sich um eine Prepaid-Karte und somit um ein überschaubares finanzielles Risiko handelt, wurde jetzt eine Karte bestellt, aufgeladen, ins Auto gepackt und ich bin auf das erste Monatsergebnis gespannt.

Nachdem es aktuell beim Wechsel von Firefox 78esr zu 91esr innerhalb der Debian-Repositories zu Verzögerungen kommt, habe ich den Firefox 91esr direkt von der Mozilla-Seite heruntergeladen und nach “/opt” entpackt. Der Plan ist, die parallel installierte Version so lange zu benutzen, bis die Debian-Version erfolgreich aktualisiert wurde und dann wieder den Browser aus dem Repository zu verwenden.

Der erste Start des neuen Browsers sorgte allerdings für eine Schrecksekunde: statt des gewohnten Anblicks mit Lesezeichenleiste und Erweiterungen präsentierte sich ein Firefox im Auslieferungszustand. Ein Blick in den “.mozilla”-Ordner innerhalb des Benutzerverzeichnisses beruhigte, denn das alte Profil war noch vorhanden und Firefox hatte ein neues Profil angelegt.

Die Erklärung hierfür liefert “Ein gesondertes Profil für jede Firefox-Installation” mit dem sachdienlichen Hinweis, daß es sich hierbei um ein Feature und keinen Bug handelt:

Wenn Sie eine neue, zusätzliche Installation von Firefox installieren, wird ein neues Profil erstellt. Ihre persönlichen Daten oder Anpassungen bleiben dabei erhalten, denn Ihre bisherigen Profildaten werden gesichert und der vorherigen Firefox-Installation zugeordnet.D

Da die Version 78esr aus den Repositories sowieso nicht mehr verwendet werden sollte, half ein erneuter Start des Browsers mit angehängtem “-p”, welches den Profilmanager aufruft. Das neue Profil löschen, das alte als Standard definieren und schon war wieder alles wie gewünscht.