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.

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.

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.

War mit dem in Debian Buster vorhandenen Wine bereits die 32-bit-Version von Adobe Photoshop CS5 mit ein paar Tricks zur Kooperation zu überreden, so funktioniert mit dem in Debian Bullseye vorhandenen Wine auch die 64-bit-Version.

Die Installaton und Aktualisierung läuft bis auf ein paar kleine Anpassungen analog zur bereits beschriebenen Vorgehensweise.

Installation

Davon ausgehend, daß die Installations-DVD im Laufwerk liegt, ist die Installation schnell erledigt. Nach dem Anlegen einer passenden Umgebung

$ WINEPREFIX="$HOME/wineps64" winecfg
...

wird auf der Kommandozeile in das Installationsverzeichnis gewechselt und anschließend die Installation gestartet

$ cd /media/cdrom0/Adobe\ CS5/
$ WINEPREFIX="$HOME/wineps64" wine Set-up.exe
...

Eventuell im Laufe der Installation auftretende Wine-Warnungen können ignoriert werden.

Aktualisierung

Da die von Adobe ausgelieferte "AdobePatchInstaller.exe" auch unter Bullseye genauso wenig funktioniert wie unter Buster, wird die Aktualisierung manuell durchgeführt. Nach dem Öffnen einer Kommandozeile innerhalb der Wine-Umgebung

$ WINEPREFIX="$HOME/wineps64" wine cmd

wird die "Setup.exe" aufgerufen. Es ist lediglich zu beachten, daß diese in 64-bit-Umgebungen im Verzeichnis "Program Files (x86)" statt "Program Files" liegt und ggf. der Pfad des entpackten Installationspakets anzupassen:

c:\>"C:\Program Files (x86)\Common Files\Adobe\OOBE\PDApp\core\..\DWA\Setup.exe" --installSourcePath=h:\Downloads\AdobePhotoshop12_5-mul-AdobeUpdate

c:\>Begin Adobe Setup
UI mode: Silent
100.00%
End Adobe Setup. Exit code: 0
002b:err:ole:CoUninitialize Mismatched CoUninitialize

Wichtig ist die Ausgabe, daß die Aktualiserung zu "100.00%" durchgeführt wurde sowie die Ausgabe des korrekten "Exit-Code: 0".

Leider ist die Oberfläche von Synologys Hyperbackup nicht sonderlich gesprächig, was die Unterschiede zwischen den einzelnen Sicherungsformen angeht.

Auch das Synology Knowledge Center liefert mit "Wie kann ich meine Daten mit Hyper Backup in einem lokalen freigegebenen Ordner oder auf USB sichern?" keine sinnvolle Anwort auf die Frage, wie sich die Sicherungsart "Lokaler Ordner und USB" von der Sicherungsart "Lokaler Ordner und USB (Einzelversion)" unterscheidet.

Des Rätsels Lösung findet sich im Reddit-Beitrag "What's the difference between "Local Folder & USB" and "Local Folder & USB (single-version)?":

I think you'll need the single-version. The other version wraps the files in a format that has be to opened with HyperBackup (.hbk). For just straight file copies I use the single-version.

Während die "Einzelversion" also 1:1 die zu sichernden Dateien kopiert, sichert die "andere" Version die Dateien in eine HyperBackup-Datei. Diese unterstützt auch Kompression, Versionierungen und Verschlüsselung.