Meta hat diese Woche die Utility-App „VR Android File Manager“ aus dem Horizon Store entfernt. Die App gewährte Zugriff auf den Android-Dateimanager der Meta Quest und erlaubte es, Android-Anwendungen aus externen Quellen am Store vorbei direkt auf Meta Quest zu installieren.

In einer Nachricht an den Entwickler begründete Meta den Schritt damit, dass die App die Installation anderer Anwendungen außerhalb des Horizon Stores ermögliche. Um die Integrität der Plattform zu wahren, müsse diese Funktion entfernt und die App erneut eingereicht werden. Erst dann werde über eine Wiederaufnahme in den Horizon Store entschieden, so Meta.

Der Entwickler, bekannt unter dem Pseudonym „Anagan79“ und durch sein außerhalb des Horizon Stores vertriebenes Tool „Quest Games Optimizer“, warf Meta in seiner Reaktion vor, ein geschlossenes System zu betreiben: Während andere Android-Geräte Sideloading standardmäßig unterstützen, sei dies unter Horizon OS nicht der Fall. Der „VR Android File Manager“ war eineinhalb Monate im Horizon Store verfügbar und erreichte in dieser Zeit mehr als 50.000 Nutzer.

Sideloading auf Quest: Möglich, aber umständlich

Das Betriebssystem der Meta Quest, Horizon OS, basiert auf einer stark angepassten und erweiterten Android-Version. Wie auf anderen Android-Geräten werden Anwendungen im APK-Format („Android Package Kit“) bereitgestellt.

Meta erlaubt die Installation von APKs aus anderen Quellen als dem Horizon Store, stellt dafür aber einige Hürden auf. Nutzer müssen zunächst ein Entwicklerkonto einrichten, wofür eine gültige Kreditkarte oder Telefonnummer hinterlegt werden muss. Erst danach lässt sich der für das Sideloading erforderliche Entwicklermodus auf dem Gerät aktivieren. Für das Sideloading selbst müssen Nutzer ihre Meta Quest per USB-C-Kabel mit einem Rechner (Windows, MacOS oder Linux) verbinden. Die Installation von APKs erfolgt anschließend mithilfe spezieller Kommandozeilenbefehle oder, wesentlich komfortabler, durch die Sideloading-Anwendung „SideQuest“.

Der „VR Android File Manager“ umging diese Hürden vollständig. Nach der Installation der Utility-App über den Horizon Store konnten Nutzer per Browser heruntergeladene APKs direkt auf der Quest installieren – ganz ohne Entwicklerkonto, Entwicklermodus oder externe Geräte.

Metas Plattform-Missbrauchsrichtlinien verbieten Apps im Horizon Store, welche die Sideloading-Beschränkungen umgehen. Dass der „VR Android File Manager“ überhaupt im Store zugelassen wurde, dürfte auf eine ungenaue Prüfung seitens Meta zurückzuführen sein. Das Unternehmen wurde offenbar erst durch mediale Berichterstattung und soziale Netzwerke auf die Sideloading-Funktion der Anwendung aufmerksam.

Meta wählt den Mittelweg

Der Rauswurf war absehbar. Bereits im Juni hatte Meta einen anderen Entwickler gezwungen, eine ähnliche Funktion aus der VR-App „Mobile VR Station“ zu entfernen. Beim „VR Android File Manager“ ergäbe die Entfernung wenig Sinn: Die App öffnet lediglich den Dateimanager des zugrundeliegenden Android-Betriebssystems (mit dem sich APKs installieren lassen) und hat darüber hinaus keine andere Funktion. Quest-Nutzern ist der Dateimanager standardmäßig verborgen.

Sideloading ist ein natives Android-Feature und auf den meisten Android-Smartphones ohne große Umwege möglich. Nutzer müssen in den Einstellungen die Option „Unbekannte Apps installieren“ aktivieren und können anschließend heruntergeladene APKs direkt auf dem Gerät installieren.

Anders sieht es auf iOS aus. Apple sperrt sich gegen Sideloading, musste jedoch auf Druck der EU in den Mitgliedsstaaten entsprechende Optionen zulassen. Die erzwungene Öffnung ist noch im Gange: Zwar erleichtert das jüngste iOS-Update das Einspielen alternativer App-Marktplätze, der direkte Download einzelner Apps von einer Entwickler-Webseite ist für Anbieter aber weiterhin mit großen Hürden verbunden. Das Sideloading ist also nach wie unter Apples Kontrolle. Für visionOS gelten zudem andere Regeln als für iOS und iPadOS: Auf Apple Vision Pro haben Endnutzer keinerlei Möglichkeit, Apps aus anderen Quellen als dem App Store zu installieren.

Im direkten Vergleich mit den großen Smartphone-Plattformen nimmt Metas VR-Plattform in puncto Sideloading eine Mittelstellung ein: weniger offen als Android, aber deutlich weniger geschlossen als iOS. Offener gestaltet sind die VR-Headsets der Marke Pico, die ebenfalls auf Android basieren und anders als Meta auf künstliche Hürden beim Sideloading verzichten.

Was macht Google mit Android XR?

Dass Meta den Nutzern Steine in den Weg legt, hat mehrere Gründe. An erster Stelle dürften finanzielle Interessen stehen. Meta behält 30 Prozent der Einnahmen aus dem Store ein. Alternative App-Stores und externe Bezugsquellen bedrohen dieses Geschäftsmodell langfristig.

Sicherheitsaspekte dürften ebenfalls eine Rolle spielen: Könnten Verbraucher unkontrolliert Software installieren, würden die Geräte häufiger durch Schadprogramme in Mitleidenschaft gezogen. Anstatt Nutzer zu bevormunden, könnte Meta aber auch, wie andere Hersteller, auf Warnhinweise setzen.

Zu guter Letzt dürfte Meta mit den Sideloading-Beschränkungen auch Piraterie eindämmen wollen. Die VR-Plattform des Unternehmens ist ohnehin stark von Raubkopien betroffen. Die Möglichkeit, APKs aus unbekannten Quellen ohne Umwege auf dem Headset zu installieren, würde der Piraterie Tür und Tor öffnen.

Offen ist noch, wie sich Google mit Android XR positionieren wird. Wird das Sideloading auf dieser Plattform so einfach wie auf Android-Smartphones und zu einem Erfolgstreiber für kommende Android-XR-Headsets, dann könnte Meta vielleicht nachziehen. Vorerst dürfte das Unternehmen jedoch am bewährten Modell festhalten. Eine Plattform nachträglich zu öffnen, ist aus PR-Sicht stets einfacher, als sie im Nachhinein einzuschränken.

Der VR Android File Manager ist unter dem Namen XR Native Android File Manager frei im Netz verfügbar. Ist die App einmal per Sideloading installiert, entfallen Metas Hürden für das Sideloading weiterer APKs.

(tobe)

Die US-amerikanische Verkehrssicherheitsbehörde NHTSA (National Highway Traffic Safety Administration) hat eine Untersuchung gegen Tesla eingeleitet. Grund: Das Unternehmen soll Unfälle, die sich im Zusammenhang mit seinen Fahrassistenz- und Selbstfahrfunktionen wie „Autopilot“ ereigneten, viel zu spät gemeldet haben. Anstatt die Vorfälle, wie vorgeschrieben, innerhalb von fünf Tagen zu melden, reichte Tesla die Berichte erst Monate nach den Unfällen ein.

Die Behörde konzentriert sich laut einer Meldung der Nachrichtenagentur Associated Press (AP) bei ihrer Prüfung auf die Frage, warum die Meldungen so lange verzögert wurden, ob die Berichte vollständig waren und ob es womöglich noch weitere bisher unbekannte Unfälle gibt. Tesla selbst gab an, die Verzögerungen seien „auf ein Problem mit Teslas Datenerfassung zurückzuführen“, das man inzwischen behoben habe.

Diese neue Untersuchung kommt zu einem kritischen Zeitpunkt: Tesla hat erst vor Kurzem in Austin einen Service mit selbstfahrenden Taxis gestartet. Der Konzern von Elon Musk plant, Robotaxi-Dienste bald landesweit anzubieten. Ferner will der E-Autobauer Millionen von Fahrzeugen mit Software-Updates ausstatten, die autonomes Fahren ermöglichen sollen.

Nicht die erste US-Untersuchung bei Tesla

Obwohl die Umsätze und Gewinne von Tesla aufgrund von Boykotten wegen Musks langzeitige Unterstützung für US-Präsident Donald Trump und rechtsextreme Politiker in Europa sinken, hält sich der Aktienkurs des Unternehmens weiterhin auf hohem Niveau. Analysten führen dies auf die Begeisterung der Investoren für die „Autopilot“-Pläne des Konzerns zurück.

Die aktuelle Prüfrunde ist nicht die erste: Bereits im Oktober startete die NHTSA eine Untersuchung wegen möglicher Probleme mit Teslas „Autopilot“-System bei schlechter Sicht. Diese betrifft 2,4 Millionen Fahrzeuge und steht im Zusammenhang mit mehreren Unfällen, darunter einem tödlichen. Ein US-Geschworenengericht entschied jüngst: Tesla trägt eine Mitschuld an diesem Crash mit Todesfolge. Das Unternehmen soll Schadenersatz von insgesamt mehreren hundert Millionen US-Dollar zahlen, wehrt sich vor Gericht aber gegen diesen Beschluss. Seit Juni analysiert die NHTSA zudem Tesla-Vorfälle mit potenziellen Verstößen gegen Verkehrsregeln.

Sinkende Einnahmen: „Autopilot“ soll es richten

Seit 2021 müssen Fahrzeughersteller in den USA Unfälle mit teilautomatisierten Fahrsystemen (SAE-Stufe 2) melden. Von den insgesamt über 2600 gemeldeten Crashs in den Vereinigten Staaten entfallen mit 2308 die meisten auf Tesla. Die NHTSA weist jedoch darauf hin, dies liege auch daran, dass das Unternehmen der größte Hersteller von teilweise selbstfahrenden Autos auf dem US-Markt ist.

Tesla bot in Austin bisher nur einem ausgewählten Kreis von Fahrgästen Robotaxi-Fahrten an. Ab September soll mit einer neuen Offensive allen zahlenden Kunden die Nutzung solcher Shuttles möglich sein, wie Musk auf X Anfang August ankündigte. Tesla hat außerdem begonnen, in San Francisco eingeschränkte Robotaxi-Dienste mit Fahrern am Steuer zuzulassen, um den kalifornischen Vorschriften zu entsprechen. Als größter Konkurrent gilt die Google-Schwester Waymo, die bereits über eine Million Fahrten pro Monat mit Robotaxis absolviert. Auch Europa hat Musk bei solchen Fahrten im Visier, wenn die Behörden die neuen Versionen der „Autopilot“-Software abgenickt haben.

(nie)

Microservices, Container und Cloud-Technologien machen Software-Entwicklung zu einem immer komplexeren Geschäft. Vorkonfigurierte Entwicklerplattformen, die sogenannten Internal Developer Platforms (IDP), versprechen da Abhilfe. Als Selbstbedienungsportale für die benötigte Infrastruktur sollen sie kognitive Last verringern und mehr Konzentration auf den Code erlauben. Guido-Arndt Söldner, Titelautor der neuen iX 9/2024, erklärt, was hinter dem Heilsversprechen steckt und wann sich eine solche Plattform tatsächlich lohnt.

Was genau ist denn eine Internal Developer Platform (IDP)?

Eine Internal Developer Platform ist eine zentrale Plattform, die von einem Platform-Engineering-Team erstellt wird, um Entwicklern standardisierte und bewährte Wege für die Softwareentwicklung zu bieten und Self-Service-Funktionen zu ermöglichen. Sie umfasst eine Sammlung von Tools und Services, die die Produktivität der Entwickler steigern, die Softwarebereitstellung beschleunigen und manuelle Operationen reduzieren. Im Kern abstrahiert eine IDP die Komplexität der zu Grunde liegenden Infrastruktur, sodass Entwickler sich auf das Coden konzentrieren können, ohne sich mit Details wie Deployment, CI/CD oder Environment-Management auseinandersetzen zu müssen.

IDPs fördern auch eine bessere Developer Experience, senken Kosten und sorgen für Konsistenz in der Organisation. In jüngster Zeit halten IDPs auch in der Infrastruktur-Automatisierung ein, um klassische Ticket-Ops Aufgaben wie Ressourcen-Anlage, Firewall Management, Rechte-Vergabe oder ähnliches zu automatisieren.

Über welche Tools sprechen wir? Geht es um lokale Programme oder das Backend?

Bei IDPs geht es primär um Backend-Tools und -Services, nicht um lokale Programme auf dem Entwickler-Rechner. Lokale Tools wie IDEs (z. B. VS Code) oder einfache Skripte spielen eine untergeordnete Rolle; stattdessen fokussiert sich eine IDP auf cloud-basierte oder interne Backend-Systeme, die Infrastruktur automatisieren und skalierbar machen. Sie dient als Frontend und Self-Service Portal für einen typische Platform Engineering Stack, der aus Komponenten wie CI/CD-Pipelines, Infrastruktur-Management, Observability und Monitoring sowie Security und Governance besteht.

Für welche Organisationen lohnt es sich, eine IDP aufzusetzen? Wie kompliziert ist das Aufsetzen einer IDP?

IDPs lohnen sich vor allem für mittelgroße bis große Organisationen, in denen die Softwareentwicklung skaliert werden muss und Komplexität zunimmt. Kleine Startups oder Teams mit niedriger Komplexität brauchen oft keine IDP, da sie teuer und übertrieben sein kann – stattdessen reichen einfache DevOps-Praktiken. Sie sind ideal bei großen Developer-Teams so ab 50 und mehr Entwicklern, um Produktivität zu steigern und Cognitive Load zu reduzieren. Sie helfen, wenn Tool-Sprawl und Silos ein Problem darstellen, etwa in Unternehmen mit einer Multi-Cloud-Strategie und wenn schnelle Release-Zyklen gewünscht sind. Sie helfen auch Visibilität über Tools und Cloud-Umgebungen herzustellen.

Das Aufsetzen und Administrieren einer IDP kann größere Aufwände mit sich ziehen. Es lohnt sich, zu überlegen, ob man alles selber entwickeln und betreiben will oder mittels externer Hilfe beziehungsweise fertigen Lösungen und dedizierten Plugins schneller zum Ziel kommen kann. Insgesamt gibt es eine Vielzahl von IDP-Projekten, die sich in Offenheit, Fokus, Komplexität und Features unterscheiden. Open Source IDPs wie Backstage kann man als SaaS-Dienst oder auch im eigenen Rechenzentrum souverän betreiben. Sie bieten oft eine hohe Flexibilität, können leicht angepasst werden und haben eine sehr große Community. Es gibt immer mehr fertige Lösungen für unterschiedliche Use Cases.

Im Eigenbetrieb kann aber ein höherer Overhead entstehen. Kommerzielle Portal-Lösungen glänzen mit schnellem Onboarding und weniger Betriebsaufwänden, sind aber oft inflexibler hinsichtlich Erweiterungen.

Guido-Arndt, vielen Dank für die Antworten! Einen Überblick zu Internal Develeoper Platforms gibt es in der neuen iX. Außerdem vergleichen wir IDPs für Kubernetes – und werfen einen Blick auf die Praxis mit der populären Plattform Backstage. All das und viele weitere Themen finden Leser im September-Heft, das ab sofort im heise Shop oder am Kiosk erhältlich ist.

In der Serie „Drei Fragen und Antworten“ will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.

(axk)