In den vergangenen Monaten häuften sich die Berichte über Batterieprobleme bei mehreren Pixel-Modellen. Neben dem Pixel 4a und 6a war auch das Pixel 7a betroffen. Nun beschweren sich einige Besitzerinnen und Besitzer der Modelle Pixel 7 und 7 Pro über aufgeblähte Akkus, die den Bildschirm aus dem Gehäuse drücken können.

Auch Pixel 7 mit Akkuproblemen

Wie PiunikaWeb und Android Authority berichten, kann einer der ersten Fälle zum Pixel-7-Pro-Problem auf Anfang Mai dieses Jahres zurückdatiert werden. Damals schrieb ein Nutzer im Google-Support-Forum:“Ich schreibe Ihnen, um ein ernstes Problem mit meinem Pixel 7 Pro zu melden, das ich vor etwa zwei Jahren gekauft habe. Vor kurzem habe ich festgestellt, dass sich die Seitenabdeckung des Geräts zu lösen beginnt, wie auf dem beigefügten Foto deutlich zu sehen ist.“

Der Beitrag sammelte bislang über 140 Stimmen von Personen, die offenbar mit dem gleichen Problem konfrontiert sind. Zudem teilten unter dem Post weitere Nutzer Bilder ihrer Pixel-7-Geräte mit aufgeblähten Akkus.

Begleiterscheinungen: Displaytausch und kurze Laufzeit

Ein weiterer betroffener Nutzer schrieb, dass er sein Pixel 7 Pro mit aufgeblähtem Akku zu einer renommierten Reparaturkette gebracht hätte. Die Reparaturwerkstatt teilte ihm mit, dass wegen der Ablösung des Bildschirms mit hoher Wahrscheinlichkeit auch der Bildschirm ausgetauscht werden müsse.

Zum Begleiteffekt der aufgeblähten Akkus des Pixel 7 und 7 Pro gehört den Berichten zufolge auch eine rapide Abnahme der Laufzeit, wobei es ohnehin ratsam ist, die betroffenen Geräte besser nicht mehr zu verwenden. Einige berichten zudem, dass einige Geräte trotz vollem Akku nicht mehr einschaltbar seien.

Kommentare im Google-Forum deuten darauf hin, dass das Support-Team bei der Bearbeitung der Nutzerbeschwerden keine einheitliche Vorgehensweise hatte. In einigen Fällen seien Kunden gebeten worden, dem Support Fotos von allen Seiten ihres Smartphones zuzusenden. Ein Nutzer erhielt etwa eine Erstattung für den Austausch des Akkus durch einen Drittanbieter. Ein anderer gab an, dass Google ihm eine kostenlose Reparatur angeboten und versprochen hätte, das aufgeblähte Pixel 7 durch ein generalüberholtes Gerät zu ersetzen, falls die Reparatur nicht erfolgreich sein sollte.

Von Google gab es bislang noch keine offizielle Stellungnahme zu der neuen Akkuproblematik. Wir haben Google Deutschland um ein Statement gebeten. Angesichts der sich offenbar häufenden Stimmen dürfte der Konzern alsbald reagieren.

Nicht die ersten Pixel mit Akkuproblemen

Es ist leider nicht das erste Mal, dass Chargen von Googles Pixel-Geräte mit Akku-Problemen zu kämpfen haben. Im April startete der Konzern ein kostenloses Akku-Austauschprogramm für Pixel-7a-Geräte und räumte ein, dass sich die Akkus bei einigen Geräten aufblähen können. Je nach Garantiestatus und Region bietet Google auch eine andere Kulanzleistung von bis zu 400 Euro an.

Neben dem Pixel 7a bestätigte Google auch Akkuprobleme beim Pixel 6a, für das der Hersteller im Juli ein Softwareupdate zur Reduzierung der Batteriekapazität wegen möglicher Überhitzungsprobleme veröffentlicht hatte. Nutzer, die bei ihren Pixel-Geräten einen aufgeblähten Akku feststellen, sollten die Richtlinien im Support-Bereich studieren und den Kundendienst kontaktieren.

(afl)

Die Sonnenaktivität ist seit 17 Jahren kontinuierlich gestiegen, sollte dieser Trend anhalten, könnten Sonnenstürme und Sonneneruptionen unabhängig vom jeweiligen Sonnenzyklus häufiger werden. Das haben zwei Forscher der NASA ermittelt, die verschiedene Entwicklungen beim Verhalten unserer Sonne ausgewertet haben. Demnach hat ein in den 1980er-Jahren begonnener Trend der abnehmenden Sonnenaktivität 2008 geendet, aber das damals erwartete Verharren auf diesem niedrigen Niveau sei nicht eingetreten. Stattdessen habe die Sonne den Kurs gewechselt und sei immer aktiver geworden. Das könnte künftig nicht nur Folgen für die Raumfahrt haben.

Dass die Sonne bei ihrer Aktivität einen ungefähr elfjährigen Zyklus durchläuft, ist seit mehr als 200 Jahren bekannt. Die wurden von dem Schweizer Astronomen Rudolf Wolf im 18. Jahrhundert bis zum Jahr 1749 zurückgerechnet, dem Maximum des sogenannten 0. Zyklus. Inzwischen wurde der Elfjahreszyklus anhand von Baumringen sogar lückenlos für die vergangenen 1000 Jahre bestätigt und bis ins Jahr 969 zurückverfolgt. Gleichzeitig durchläuft die Sonne aber langfristigere Veränderungen, die dafür sorgen, dass die Aktivität unabhängig von den Zyklen zu- oder abnimmt. Am inaktivsten war die Sonne beispielsweise aus bislang ungeklärten Gründen im 17. Jahrhundert und dann noch einmal am Anfang des 19. Jahrhunderts. Am Beginn des Raumfahrtzeitalters war sie dann so aktiv wie lange nicht mehr.

Sonnenaktivität mit konkreten Folgen auf der Erde

Dass der aktuelle 25. Sonnenzyklus stärker ausgefallen ist als erwartet, war bereits bekannt. Auch sein Maximum hat er früher erreicht. Die beiden NASA-Forscher haben nun aber bestätigt, dass das Teil eines größeren Trends ist: „Die Sonne wacht langsam auf“, meint Studienleiter Jamie Jasinski vom Jet Propulsion Laboratory der NASA. Insgesamt sei das eine Überraschung gewesen, denn eigentlich habe alles darauf hingedeutet, dass die Sonne in eine längere Phase geringer Aktivität eingetreten ist. Dass dem nicht so ist, hat er mit Marco Velli unter anderem anhand von Daten zum Sonnenwind und zum Magnetfeld ermittelt. Ihre Forschungsarbeit haben sie in den Astrophysical Journal Letters veröffentlicht.

Die kontinuierliche Beobachtung und Vorhersage der Sonnenaktivität sind nicht nur für die Erforschung unserer Sonne von Belang, Phasen besonders hoher Aktivität können ganz konkrete Folgen auf der Erde haben. Schlimmstenfalls kann eine besonders aktive Sonne – also eine mit vielen Sonnenflecken und großen Ausbrüchen auf der Oberfläche – technische Systeme wie etwa Satelliten beschädigen oder gar zur Gefahr für Astronauten werden. Eine besonders starke Sonneneruption könnte sogar eine „Internet-Apokalypse“ auslösen. Zudem hat erst vor wenigen Monaten ein Forschungsteam herausgefunden, dass sogenannte Superflares unserer Sonne viel häufiger sind als angenommen. Dabei handelt es sich um gigantische Eruptionen auf der Sonne mit potenziell verheerenden Folgen für moderne Infrastruktur.

(mho)

Viele Benutzeroberflächen entstehen auf Basis von Webtechnologien. Dennoch sind native Applikationen weiterhin für viele Anwendungsfälle der bessere Ansatz oder sogar alternativlos. Sowohl Desktopprogramme mit Hardwareanbindungen als auch mobile Apps fordern die Entwicklung für ein bestimmtes Betriebssystem.

Native Applikationen haben Vorteile wie gute Performance, natives Look and Feel und direkten Zugriff auf angeschlossene Hardware. Zu den Nachteilen gehören spezifische Codebasen für jedes Betriebssystem, Unterschiede zwischen den nativen APIs und eine umständliche Installation der Software.

Die Idee von Cross-Plattform-Frameworks ist, zumindest den ersten beiden Nachteilen zu begegnen. Besonders für schnelle Ergebnisse mit wenig Aufwand sind Frameworks eine gute Wahl. Dynamische Sprachen ermöglichen schnelle Ergebnisse. Soll die Applikation lediglich für ein, zwei Jahre laufen, können Entwicklungsteams bedenkenlos zu solchen Frameworks greifen.

Will ein Team aber eine Anwendung zehn oder mehr Jahre weiterentwickeln, muss es verschiedene Aspekte kritisch hinterfragen: Wie lange entwickelt der Hersteller das Framework weiter? Genügt die Unterstützung von Android, iOS und Web? Reicht die Performance einer Web View? Soll die Anwendung neu aufkommende UI-Technologien oder Betriebssysteme integrieren? Wie laufen (automatisierte) Tests, um die Qualität hochzuhalten?

Langlebigkeit durch einen herausgelösten Core

Da sowohl Cross-Plattform-Frameworks als auch UI-Technologie einem schnellen Wandel unterliegen, liegt es nahe, das UI vom beständigen Teil zu trennen. Diese Idee ist durch die hexagonale Architektur bekannt. Mit dieser können sich Entwicklerinnen und Entwickler auf die Kernfunktionen konzentrieren und technische Notwendigkeiten als Ports definieren, die von außen an den Core andocken. Bei einer Cross-Plattform-Anwendung ergeben sich Ports für die Benutzeroberfläche und andere plattformspezifische APIs. Beispiele für APIs sind Zugriffe auf die Kamera oder das Dateisystem. Der Core beinhaltet die vollständige Geschäftslogik und alle weiteren Teile der Applikation, die Bestand haben und lange leben sollen.

Auswahl der Core-Programmiersprache

Der herausgelöste Core muss auf allen anvisierten Plattformen laufen. Als Beispiel für Zielplattformen seien Android, iOS, Windows, macOS und Raspberry Pi definiert. Als Kriterien einer für den Core geeigneten Sprache sind Stabilität, Robustheit, Langlebigkeit und Flexibilität wichtig.

Eine Programmierumgebung gilt als stabil, wenn sie produktionsreif ist und nur noch wenigen grundlegenden Änderungen unterliegt. Robustheit bezieht sich auf den in der Programmiersprache geschriebenen Code. Die Sprache soll weiterhin ermöglichen, den Code zu erweitern, umzuschreiben und für die nächsten zehn Jahre verständlich zu halten.

Dafür muss auch die darunterliegende Sprache langlebig sein. Auch soll sie sich möglichst flexibel verwenden lassen und am besten alle großen Betriebssysteme, Single-Board-Computer, Mikrocontroller und den Browser abdecken. Für diesen Artikel fiel die Wahl auf die Programmiersprache Rust, die sich für zahlreiche Plattformen verwenden lässt.

Rust für den Core

Rust ermöglicht mit vertretbarem Aufwand die Gestaltung eines wartbaren und performanten Core für flexible Einsatzgebiete. Die Sprache läuft auf allen Desktop-Betriebssystemen, mobilen Endgeräten, Single-Board-Computern, vielen Mikrocontrollern und via WebAssembly durch kompakte wasm-Module auch gut im Browser.

Die explizite Syntax von Rust begünstigt die Entwicklung robuster, lange wartbarer Software. Nachteilig sind die Komplexität, die steile Lernkurve und die im Vergleich zu JavaScript oder C++ kleinere Community. Allerdings wächst die Beliebtheit von Rust und damit auch die Community. Das zeigt sich auch durch die an vielen Stellen verlautete Migration von C zu Rust.

2021 wurde die Rust Foundation von AWS, Google, Huawei, Microsoft und Mozilla gegründet. Heute unterstützen viele weitere Firmen die Foundation, darunter Meta, JetBrains und Threema. Die Unternehmen sind daran interessiert, die ursprünglich von Mozilla ins Leben gerufene Sprache lange zu pflegen.

Architektur des Core

Nach der Auswahl der Sprache ergibt sich die Frage der Architektur für den Core. Je größer der Anteil der Anwendung im Core ist, desto stärker wiegen die Vorteile des Architekturansatzes, ohne weiteren Aufwand verschiedene Plattformen abzudecken. Das bezieht sich insbesondere auf Logik und Zustand, aber auch auf Übersetzungen für die Mehrsprachigkeit.

Um die Idee der Architektur besser begreifen zu können, dient im Folgenden als Beispiel eine simple App für das Speichern von Namen und E-Mail-Adressen.

Die auf der Benutzeroberfläche zu rendernden Daten muss man ebenso vorbereiten wie die an Buttons oder Eingabefelder gebundenen Aktionen. Wenn Anwender die E-Mail-Adresse ändern und durch Drücken eines Buttons speichern, soll der Core Schnittstellen für die aktuellen Daten, die Änderungen und für den Bestätigungstext bereitstellen, die sich direkt an den Oberflächencode anschließen lassen.

Klare Trennung durch MVVM

Im Entwurfsmuster MVVM (Model View ViewModel) kapselt das Modell die fachlichen Daten – und gegebenenfalls den Zustand. Das ViewModel enthält eine Aufbereitung dieser Daten, um sie in der View (Benutzeroberfläche) ohne weitere Bearbeitung einbinden zu können. Der Core stellt das ViewModel bereit. In Rust definiert kann es ein einfaches Struct sein:

ViewModel {
    name: String,
    email: String
}

UI-Aktionen als fachliche Aktionen

Bei der UI-Entwicklung lösen native Elemente wie Widgets und Controls technische Events aus, beispielsweise buttonXYClicked(). Diese Events führen zu fachlichen Aktionen wie „ändere E-Mail-Adresse“. Der Core stellt Schnittstellen für diese Aktionen zur Verfügung. Die Aktionen sind so gestaltet, dass eine Anwendung sie direkt an die UI-Elemente anbinden kann. Somit ergeben sich Aktionen, die optimal für das UI und gleichzeitig fachlich geschnitten sind.

In Rust kann die Liste an Aktionen ein Enum sein:

pub enum Actions {
    ChangeName(String),
    ChangeEmail(String),
    ApplyChanges,
}

Verwaltung des Zustands

Auch den Zustand verwaltet der Core. Das UI bleibt zustandslos: Es schickt Aktionen an den Core und reagiert auf die Änderungen im ViewModel. Der Zustand kann ein einfaches Struct sein, das im Speicher gehalten wird:

pub struct ViewModel {
    pub name: String,
    pub email: String,
}

pub enum Actions {
    ChangeName(String),
    ChangeEmail(String),
    ApplyChanges
}

struct State {
    name: String,
    email: String
}

impl Default for State {
    fn default() -> Self {
        State {
            name: "".into(),
            email: "".into()
        }
    }
}

pub struct App {
    state: State
}

impl App {
    pub fn new() -> App {
        App {
           state: State::default()
        }
    }

    pub fn do_action(&mut self, action: Actions) -> ViewModel {
        match action {
            Actions::ChangeName(name) => {
                self.state.name = name;
            }
            Actions::ChangeEmail(email) => {
                self.state.email = email;
            }
            Actions::ApplyChanges => {}
        }
        self.render_view_model()
    }

    pub fn render_view_model(&self) -> ViewModel {
        ViewModel{
            name: self.state.name.clone(),
            email: self.state.email.clone()
        }
    }
}

impl Default for App {
    fn default() -> Self {
        Self::new()
    }
}