Der Befehlssatz RISC-V soll in Android vollständig unterstützt werden. Noch in diesem Jahr soll der Support für Entwickler finalisiert werden.

Erst vor wenigen Wochen hat Google angekündigt, gemeinsam mit Qualcomm Android-Geräte auf Grundlage des freien CPU-Befehlssatzes RISC-V vertreiben zu wollen. Nun veröffentlicht Google zahlreiche Details und vor allem einen groben Zeitplan dafür, wie andere OEMs und eventuell betroffene Anwendungsentwickler auf RISC-V wechseln können. Wichtigstes Ziel laut Google ist es dabei, seinen Partnern den bereits prinzipiell vorhandenen Support möglichst ausgereift zur Verfügung stellen zu können.

So verweist Google etwa direkt auf die Patches, die es ermöglichen, Android für RISC-V-CPUs zu bauen. Diese seien aber noch nicht optimiert. Das gelte insbesondere für das Backend der Android Runtime (ART), die zum Ausführen von Apps genutzt wird. Ebenso fehlten sowohl Android selbst als auch externen Abhängigkeiten wie Compilern noch eine Erweiterung, um optimierten und platzsparenden Code zu erzeugen. Dennoch sei jetzt schon die Zeit für Experimente und eine tiefere Zusammenarbeit gekommen, versichert Google.

Noch in diesem Jahr will das Team außerdem die Arbeiten an der Binärschnittstelle des NDK abschließen und erste Testbuilds bereitstellen, um RISC-V-Android-Apps auf x86- und ARM-Hostmaschinen emulieren zu können. Anfang 2024 sollen die Emulatoren allgemein verfügbar sein, um Apps mit allen Android-Funktionen und für alle Gerätekategorie testen zu können.

Schon jetzt lässt sich Android für RISC-V in der Virtualisierungslösung des Projekts, Cuttlefish, nutzen. Fest steht ebenso, dass konkret das Befehlssatzprofil RVA22 samt Vektor- und Vektor-Krypto-Erweiterungen für Android genutzt werden soll. Google arbeitet eigenen Angaben zufolge außerdem weiter aktiv an den zahlreichen Werkzeugen zur RISC-V-Unterstützung und dem gesamten Softwareökosystem. Letzteres wird vor allem in dem Rise-Projekt mit zahlreichen Partnern aus der Hard- und Softwarebranche umgesetzt.

Der Beitrag Plan für Android-Port auf RISC-V steht erschien zuerst auf Linux-Magazin.

Mit KDE Connect lassen sich Smartphone und Laptop miteinander verbinden. Play Protect entfernt die App, wenn diese über F-Droid installiert wurde.

Die Android-App KDE Connect wird derzeit durch die Sicherheitstechnik Play Protect von Google automatisch von zahlreichen Smartphones entfernt. Das geht unter anderem aus Berichten auf X, vormals Twitter, oder auch einer Diskussion auf Reddit hervor. Auch in der Golem-Redaktion ist die App auf einem Pixel 6a mit aktuellem Android 14 durch Play Protect gelöscht worden.

Der KDE-Entwickler Niccolò Venerandi schreibt dazu vor einigen Tagen: “Es ist offiziell: Google deinstalliert wahllos KDE Connect von den Telefonen der Nutzer, ohne dass es dafür eine Erklärung gibt.” Inzwischen zeigt sich aber, dass dies nicht wirklich wahllos geschieht, sondern wohl nur jene Installation betrifft, die über den alternativen Open-Source-Store F-Droid bezogen werden. Das zumindest schreibt der Betreuer von KDE Connect, Albert Vaca Cintora. Die über den Play Store vertriebene App, welche aus dem exakt gleichen Quellcode erstellt wird, ist von den Löschungen wohl nicht betroffen.

In der Benachrichtigung von Play Protect zu der automatisierten Löschung heißt es, dass dies aus Sicherheitsgründen geschehe und es sich bei der App um eine Fälschung handele. Die App könne demnach personenbezogene Daten wie Bankinformationen oder Passwörter stehlen. Wie die Systeme Googles zu dieser Einschätzung kommen, ist derzeit nicht klar. Vaca kritisiert zudem, dass es für Entwickler wie ihn keine Möglichkeit gebe, das zugrunde liegende Problem einer automatischen Einordnung mit einem Menschen bei Google zu besprechen, um eine Lösung dafür zu finden. Der Entwickler fragt sich außerdem, ob dieses Verhalten im Einklang mit europäischem Wettbewerbsrecht stehe.

Die App selbst bietet in Zusammenarbeit mit einem Desktop-Client, der auch für Gnome, Windows oder MacOS bereitsteht, eine Verbindung des Smartphones mit einem Rechner. So können darüber die Zwischenablage geteilt werden, Dateien übertragen werden oder die Benachrichtigungen synchronisiert werden. Auch eine Mediensteuerung ist möglich oder die Nutzung des Smartphones als virtuelles Eingabegerät für den Laptop etwa zur Steuerung für Präsentationen oder als externes Touchpad.

Der Beitrag Google entfernt KDE-App aus F-Droid von Android-Smartphones erschien zuerst auf Linux-Magazin.

Das gerade erst vorgestellte Fairphone 5 ist nun auch mit dem Google-freien und privacy-freundlichen mobilen Betriebssystem /e/OS verfügbar, teilt Murena, der Anbieter des Betriebssystems mit.

Das Gerät sei für rund 764 Euro bestellbar. Die installierte Version von /e/OS sei auf der Basis von Android 13 und vollständig mit den meisten Android-Apps kompatibel, teilt Murena weiter mit.

Das Murena Fairphone 5. Quelle: Murena

Das Murena Fairphone 5 sei wetterfest nach IP55, verfügt über 8 GByte RAM, einen Speicher von 256 GByte (erweiterbar), sowie eine Dreifachkamera mit 50 Megapixeln und Sony-Sensoren. Der OLED-Bildschirm biete eine Bildwiederholrate von 90 Hz, der austauschbare Akku biete 4200 mAh und schnelles Aufladen. Das Murena Fairphone 5 sei ab sofort bestellbar, die Auslieferung sei für Ende September geplant, teilt Murena mit.

Der Beitrag Mit “google-freiem” /e/OS: Murena Fairphone 5 vorbestellbar erschien zuerst auf Linux-Magazin.

Mit der kommenden Version 14 des mobilen Betriebssystems Android verbessert Google die Sicherheit. Unter anderem bietet Android 14 IT-Administratoren die Möglichkeit, die 2G-Unterstützung in ihrer verwalteten Geräteflotte zu deaktivieren.

Mit der wachsenden Verbreitung von 5G hätten viele Betreiber begonnen, 2G-Dienste abzuschalten, teilt Google mit. Dennoch unterstützten alle Mobilgeräte weiterhin 2G und könnten, sofern verfügbar, eine Verbindung zu einem 2G-Netz herstellen. Dies geschehe etwa automatisch, wenn 2G das einzige verfügbare Netz sei. Die Verbindung lasse sich aber auch durch einen böswilligen Angriff aus der Ferne herstellen, bei dem die Geräte stillschweigend auf eine reine 2G-Verbindung heruntergestuft werden und somit alle Nicht-2G-Netze ignorieren würden. Die 1991 eingeführten  2G-Netze seien unsicher. Vor allem bei 2G-Netzen, die auf dem GSM-Standard (Global System for Mobile Communications) basieren, fehle die gegenseitige Authentifizierung, was triviale Person-in-the-Middle-Angriffe ermöglicht. Außerdem hätten Sicherheitsforscher seit 2010 gezeigt, dass das Abfangen und Entschlüsseln von 2G-Datenverkehr über die Luft trivial sei.

Die veraltete Sicherheit von 2G-Netzen in Verbindung mit der Möglichkeit, die Konnektivität eines Geräts von 5G und 4G unbemerkt auf 2G herunterzustufen, seien die häufigsten Angriffsmuster, teilt Google mit. Mit Android 12 habe man eine manuelle Deaktivierung von 2G eingeführt, teilt Google mit. Jetzt lasse man mit Android 14 eine zentrale Deaktivierung durch Admins über alle Geräte hinweg zu.

Android 14 biete zudem die Möglichkeit, Null-Cipher-Verschlüsselungen zu unterbinden. Null-Cipher-Verschlüsselungen ermöglichten das Abhören von Sprach- und SMS-Verkehr (etwa für One-Time-Passwords) von Nutzern auf triviale Weise. Android 14 führt eine Benutzeroption ein, mit der die Unterstützung für nicht verschlüsselte Verbindungen auf Modemebene deaktiviert werden könne, teilt Google mit. Ähnlich wie bei den 2G-Kontrollen sei es immer noch möglich, Notrufe über eine nicht verschlüsselte Verbindung zu tätigen.

Der Beitrag Android 14 erlaubt Admins Deaktivierung von 2G erschien zuerst auf Linux-Magazin.

Google hat in einer Sicherheitsmeldung eine kritische Sicherheitslücke in der Systemkomponente von Android gemeldet. Das Sicherheitspatch-Level von 2023-07-05 behebt dieses und weitere Sicherheitsprobleme.

Die kritische Sicherheitslücke in der Systemkomponente ermögliche unter Umständen eine Remotecodeausführung, ohne dass zusätzliche Ausführungsrechte erforderlich seien, berichtet Google. Für die Ausnutzung sei auch keine Benutzerinteraktion erforderlich. Betroffen sind laut dem Sicherheitsbericht die Android-Versionen 11, 12, 12L und 13. Die unter Remote-Code-Execution (RCE) geführte Sicherheitslücke trägt die Kennung CVE-2023-21250. Google listet unter der Rubrik RCE eine weitere Sicherheitslücke auf.

Zu den weiteren Sicherheitsproblemen, die durch das aktuelle Patchlevel beseitigt werden, zählt Google auch mehrere im Kernel auf, die zu einer Ausweitung der Rechte führen können, ohne dass zusätzliche Ausführungsrechte erforderlich seien. Auch in diesen Fällen sei für die Ausnutzung der Lücken keine Benutzerinteraktion erforderlich.

Der Beitrag Android braucht Patches gegen Remotecode-Lücke erschien zuerst auf Linux-Magazin.

Nach sieben Jahren wird der Software-Support für das Fairphone 2 endgültig eingestellt, teilt das hinter dem Android-Smartphone stehende Unternehmen mit. Ab März 2023 werden wir keine Software-Updates mehr für das Fairphone 2 liefern, heißt es in der Ankündigung.

Mit sieben Jahren Support überbietet Fairphone sein eigenes Versprechen für fünf Jahre Support um zwei Jahre und die Support-Zeiten von den meisten namhaften anderen Anbietern ebenfalls deutlich.

Mit dem letzten Update im März für Android 10 könnten die Benutzer ihr Gerät wie gewohnt weiter verwenden, schreiben die Anbieter. Allerdings gebe es bei möglichen Bugs keine Updates mehr. Zudem würden einige sicherheitskritische Anwendungen – etwa Bankanwendungen – mit der Zeit als veraltet eingestuft und nicht mehr ausgeführt.

In der Zwischenzeit könne man einen begrenzten Vorrat an Ersatzteilen im Webshop anbieten, einschließlich Display-Modulen. Nutzer hätten auch die Option, das Phone im Offline-Modus zu verwenden.

Wer sich vom Fairphone 2 verabschieden wolle, könne es an das Wiederverwendungs- und Recyclingprogramm des Unternehmens schicken, heißt es weiter. Dafür gebe es als Dankeschön einen 50 EUR-Gutschein für den Fairphone-Webshop, wenn das Gerät bis zum 31. März 2023 in dem Programm registriert werde, teilt das Unternehmen mit. In der Ankündigung sind die Optionen genauer beschrieben und das Recycling-Programm ist verlinkt.

Der Beitrag Support für Fairphone 2 endet erschien zuerst auf Linux-Magazin.

Das Unternehmen Statcounter veröffentlicht regelmäßig unter anderem die Marktanteile von Betriebssystemen und Browsern. Demnach verwendeten die meisten Nutzerinnen und Nutzer im Jahr 2022 den Browser Chrome. Firefox verlor langsam aber stetig Marktanteile.

Einen Einbruch gab es im März, zum Ende des Jahres lag der Markteinteil von Firefox nur bei 7,21 Prozent. Demgegenüber verwendeten Chrome zum Jahreswechsel 66,41 Prozent. Diese Zahlen gelten für die weltweite Nutzung. Gemäß Statcounter ist in Deutschland Firefox deutlich populärer: Dort lief er im letzten Jahr auf fast 20 Prozent aller Systeme. Chrome lag Ende des Jahres mit fast 45 Prozent aber auch in Deutschland vorne. Statcounter untersuchte allerdings nur die Browsernutzung unabhängig vom Betriebssystem. Es bleibt somit offen, ob die Marktanteile der Browser unter Linux identisch ausfallen.

In einer weiteren Statistik führt Statcounter die Marktanteile der Betriebssysteme auf. Demnach blieb der Marktanteil von Windows weltweit bis zum Jahresende unter 30 Prozent. Linux blieb relativ konstant bei etwas über 1 Prozent. Marktführer ist und bleibt Android mit 44,6 Prozent.

Die Statistiken sind allerdings mit Vorsicht zu genießen: Statcounter verwendet nach eigenen Angaben einen Tracking-Code auf über 1,5 Millionen Webseiten, über den das Unternehmen die Browser-Kennung ausliest. Server bleiben somit unerkannt, gleiches gilt für anonymisierte Browser.

Der Beitrag Beliebteste Browser und Betriebssysteme im Jahr 2022 erschien zuerst auf Linux-Magazin.

Google hat Malware gefunden, die mit den Zertifikaten von Android-Herstellern signiert sind. Das kann für Systemberechtigungen genutzt werden.

Mehrere Android-Plattformzertifikate sind offenbar dazu genutzt worden, Malware-Apps für das freie Mobilbetriebssystem zu signieren. Einen entsprechenden Bug-Report hat das Team von Google öffentlich gemacht. Die Zertifikate sind eigentlich für die Android-OEMs selbst gedacht, die damit ihre Kernanwendungen signieren. Das umfasst auch die eigentlichen ROM-Abbilder mit dazugehörigen Apps.

Zur möglichen Gefahr durch die Malware-Apps heißt es: “Ein Plattformzertifikat ist das Anwendungssignaturzertifikat, das zum Signieren der Android-Anwendung auf dem Systemabbild verwendet wird. Die Android-Anwendung wird mit einer hochprivilegierten Benutzer-ID – android.uid.system – ausgeführt und verfügt über Systemberechtigungen, einschließlich Berechtigungen für den Zugriff auf Benutzerdaten. Jede andere Anwendung, die mit demselben Zertifikat signiert ist, kann erklären, dass sie mit derselben Benutzer-ID ausgeführt werden möchte, wodurch sie dieselbe Zugriffsebene auf das Android-Betriebssystem erhält.”

Viele weitere Details nennen die Beteiligten nicht. Zur Verfügung stehen jedoch SHA256-Hashwerte von Malware-Apps sowie der dafür genutzten Zertifikate. Demnach wurden einige der Anwendungen mit den Plattformzertifikaten von Samsung, Mediatek oder auch LG signiert. Einzelheiten dazu, wie dies geschehen konnte und ob etwa Angreifer die dazugehörigen privaten Schlüssel entwenden konnten, gibt es nicht. Auch über das Ausmaß und die Verbreitung der Malware ist noch nichts öffentlich bekannt.

Eigenen Angaben zufolge hat Google die betroffenen Hersteller dazu aufgefordert, die Zertifikate zu ersetzen und dafür auch neue private und öffentliche Schlüssel zu verwenden. Darüber hinaus empfiehlt Google eine interne Überprüfung, wie es überhaupt zu der signierten Malware kommen konnte. Das Unternehmen empfiehlt seinen OEMs außerdem, möglichst wenige ihrer Apps mit dem Plattformzertifikat zu signieren, um einen regelmäßigen Wechsel zu erleichtern.v

Der Beitrag Android-Malware mit OEM-Zertifikaten signiert erschien zuerst auf Linux-Magazin.

Trotz der Einstellung, Verbindungen ohne VPN zu blockieren, nimmt Android diese für Verbindungsprüfungen auf. Google verteidigt das Verhalten.

Der kommerzielle VPN-Anbieter Mullvad berichtet in seinem Blog von einem unerwarteten Verhalten von VPN-Verbindungen unter Android. Demnach senden die Geräte unter bestimmten Umständen Teile des Netzwerkverkehrs auch dann an dem VPN vorbei, wenn die Option Verbindungen ohne VPN blockieren in den Einstellungen ausgewählt ist.

Dem Team von Mullvad sei dies bei einem Audit aufgefallen, dessen Ergebnisse noch veröffentlicht werden sollen. Im Blog des Anbieters heißt es: “Wir verstehen, warum das Android-System diesen Datenverkehr standardmäßig senden möchte. Wenn es beispielsweise ein Captive-Portal im Netzwerk gibt, ist die Verbindung unbrauchbar, bis sich der Benutzer dort angemeldet hat. Daher möchten die meisten Benutzer, dass die Captive-Portal-Prüfung durchgeführt wird und ihnen erlaubt wird, das Portal anzuzeigen und zu verwenden.”

Der damit verbundene Netzwerkverkehr könne je nach Bedrohungsszenario aber ein Datenschutzproblem sein. Mullvad hat dies auch im Android-Bugtracker beschrieben und fordert doch eine Änderung der Einstellungen. Nutzer sollten zumindest eine einfache Option erhalten, die Verbindungsprüfungen zu deaktivieren. Dies sei etwa in GrapheneOS möglich.

Das Team von Google bestätigte zunächst, dass die Technik so funktioniere wie vorgesehen. Darüber hinaus würde eine Änderung Nutzer eventuell verwirren und das Verhalten sei für einige Szenarien und Anwendungen wie ein Split-Tunnel-VPN sogar notwendig. Darüber hinaus gäben die Verbindungsprüfungen keine Details preis, die nicht auch aus dem L2-Traffic ersichtlich seien. Eine Änderung wird es in Android also vorerst nicht geben.

Das Team von Mullvad forderte in einem weiteren Bug-Report deshalb, zumindest die offizielle Dokumentation von Android anzupassen und das umgesetzte Verhalten zu beschreiben. Eine Reaktion von Google darauf gibt es bisher noch nicht.

Der Beitrag Android schickt Verbindungsprüfungen an VPN vorbei erschien zuerst auf Linux-Magazin.

Google hat die Version 13 seines mobilen Betriebssystems Android veröffentlicht. Die neue Ausgabe verspricht mehr Sicherheit.

Letzteres geht Google damit an, dass die Zwischenablage nun automatisch nach einiger Zeit gelöscht wird, sollten dort sensible Daten wie Adressen, Telefonnummern oder Logins gespeichert sein, die zuvor kopiert wurden. Zudem verbietet es Android 13, dass Apps Benachrichtigungen verschicken, die nicht ausdrücklich vom Nutzer nach der Installation erlaubt wurden.

Neu ist auch, dass der Anwender bestimmte Fotos und Videos für die Nutzung in anderen Apps freigeben kann. Apps haben damit auf nicht freigegebene Fotos und Videos keinen Zugriff.

Optisch kommt Android 13 in einer weiterentwickelten Version des Material-You-Designs. Dessen Farbschemata lassen sich nun auch auf Apps von Drittanbietern anwenden. Zudem lassen sich einzelnen Apps nun eine zweite Systemsprache zuweisen.

Android 13 gestattet es zudem, dass Nutzer mit passenden Kopfhörern Spatial Audio wählen können, das einen Raumklang simuliert. Android 13 unterstützt auch Bluetooth LE.

Wie gewohnt spielt Google Android 13 zuerst auf die eigenen Pixel-Smartphones ab dem Pixel 4 auf. Es folgen dann andere Hersteller. In welchem Tempo Nutzer Android 13 bekommen, hängt dann auch von denen ab.

Android 13 bietet einen aktualisierten Media Player, der sein Aussehen und seine Bedienung an die Musik anpasst, die gerade läuft. Der Media Player zeigt das Albumcover an und hat eine Wiedergabeleiste, die während des Songs tanzt, teilt Google mit.

Der Beitrag Google hat Android 13 fertig erschien zuerst auf Linux-Magazin.

Das verschlüsselte DNS in Android läuft nun auch über HTTP/3. Im Vergleich zu DoT werde dadurch die Latenz verringert, so Google.

Zusätzlich zu dem bereits verfügbaren DNS über TLS (DoT), das Google seit Android P in sein Mobilbetriebssystem integriert hat, kann in Android nun auch DNS-over-HTTP/3 genutzt werden, wie Google in seinem Security-Blog ankündigt. Google verspricht sich davon laut eigenen Aussagen vor allem Verbesserungen im Vergleich zu dem bisher verfügbaren DoT.

Der Nachteil von DoT ist laut der Ankündigung der Mehraufwand, der durch die Verschlüsselung der DNS-Anfragen entstehe. Zu DNS über HTTPS (DoH) heißt es: “Während die Verwendung von HTTPS allein den Overhead nicht wesentlich reduziert, verwendet HTTP/3 QUIC, ein Transportprotokoll, der mehrere Streams über UDP effizient multiplext, indem eine einzige TLS-Sitzung mit Sitzungswiederaufnahme verwendet wird. All diese Funktionen sind entscheidend für den effizienten Betrieb auf mobilen Geräten.”

Wichtig für den Mobilbetrieb ist unter anderem, dass bei den häufigen Wechseln zwischen den Netzen die Verbindungen bei DoT jedes Mal wieder neu aufgebaut werden müssten. Da HTTP/3 aber eben auf QUIC basiert, könne dessen Technik zur Wiederaufnahme einer Sitzung auch in DoH genutzt werden, wie Google schreibt. Die in QUIC integrierten Kontrollflusstechniken könnten bei unzuverlässigen Verbindungen gar dazu führen, das DNS über HTTP/3 schneller sei, als das klassische unverschlüsselte DNS.

Die Nutzung von DoH3, wie Google dies selbst nennt, hat das Unternehmen über ein Play-Store-Update an Android-Nutzer verteilt. Zur Verfügung steht dies damit nun für alle Versionen ab Android 11. Als DNS-Server unterstützt werden bisher die Dienste von Google sowie auch von Cloudflare, für deren Nutzung nun keine DoT mehr zum Einsatz kommt. In der Ankündigung weist Google außerdem noch auf den Standard-Entwurf Discovery of Designated Resolvers (DDR) hin, dessen Umsetzung die Konfiguration und Auswahl der DNS-Server vereinfachen und damit weiter beschleunigen soll.

Der Beitrag Google macht DNS auf Android per DoH schneller erschien zuerst auf Linux-Magazin.

Mit dem aktuellen Patchlevel für den Mai schließt Google unter anderem mehrere mit hohem Risiko bewertete Sicherheitslücken.

Die schwerwiegendste dieser Schwachstellen ist eine Sicherheitslücke mit hohem Risiko in der Framework-Komponente, die zu einer lokalen Eskalation von Rechten führen kann, für die die Rechte des Benutzers erforderlich sind, schreibt Google im zugehörigen Bulletin für seine Patches. Eine als kritisch eingestufte Lücke stecke zudem in den Qualcomm-Komponenten, heißt es weiter. Weitere Informationen dazu sind nicht veröffentlicht. Im Bulletin sind auch die Wege zur Prüfung des auf dem Gerät vorhandenen Patchlevels verlinkt. Die Pixel-Geräte von Googel bekommen im Mai zusätzliche Updates.

Die Android-Partner informiere man über diese Probleme mindestens einen Monat vor der Veröffentlichung, teilt Google mit. Quellcode-Patches für diese Probleme werden man zudem in den nächsten 48 Stunden im Repository des Android Open Source Project (AOSP) veröffentlichen.

Der Beitrag Aktuelles Android-Patchlevel schließt Sicherheitslücken erschien zuerst auf Linux-Magazin.

Google bringt eine neue Funktion in die Beschreibung von Apps im Play Store für Android Geräte, über die Nutzer Informationen zur Sammlung und Verwendung der von der App genutzten Daten erhalten.

Der neue Abschnitt Datensicherheit in der App-Beschreibung im Play Store von Google muss von App-Entwicklern nun ab 20. Juni mit Informationen darüber ausgefüllt werden, wie ihre App Nutzerdaten erhebt, weitergibt und schützt. Den Entwicklern obliegt es ab diesem Zeitpunkt auch, bei Änderungen bei der Erhebung von Daten ihre Angaben im Abschnitt zur Datensicherheit der jeweiligen App anzupassen.

Wie Google in einem Blogbeitrag wissen lässt, wollen Nutzer wissen, zu welchem Zweck ihre Daten erhoben und ob diese an Dritte weitergegeben werden. Außerdem möchten sie verstehen, wie Entwickler Nutzerdaten nach dem Herunterladen einer App schützen.

im Abschnitt zur Datensicherheit können App-Entwickler folgende Informationen angeben:

•     Ob Daten erhoben werden und zu welchem Zweck.
•     Ob diese Daten an Dritte weitergegeben werden.
•     Welche Sicherheitsmaßnahmen in der App vorgenommen werden, zum Beispiel ob die Daten beim Übertragen verschlüsselt sind und ob Nutzer das Löschen der Daten beantragen können.
•     Ob die App sich dazu verpflichtet, die Richtlinie für familienfreundliche Inhalte von Google Play einzuhalten, um Kinder im Play Store besser zu schützen.
•     Ob die Sicherheitsmaßnahmen auf einem weltweiten Standard beruhen (insbesondere auf dem MASVS).

Der Beitrag Android-Apps: Informationen zur Datenverwendung im Play Store erschien zuerst auf Linux-Magazin.