Installation von FreeBSD ARM auf altem Mobiltelefon möglich?

[cabriofahrer]

Ich habe ein altes Mobiltelefon (LG II 430) herumfliegen, dass ich seit Jahren schon nicht mehr benutze. Da Mobiltelefone ja angeblich ARM-Architektur haben sollen, wollte ich mal wissen, ob es denn möglich wäre, FreeBSD für ARM zu installieren. Hintergedanke wäre eine Nutzung ähnlich wie bei einem Raspberry z.B. als kleiner Fileserver, der 24/7 läuft. Man könnte sicherlich mit einem USB Hub mit Stromversorgung dann auch eine externe Festplatte anschließen oder was auch immer. Wenn ich das Teil am PC einstöpsele, bekomme ich folgende Ausgabe:

ugen7.3: <LGE LG-E430> at usbus7
umodem0 on uhub6
umodem0: <LGE LG-E430, class 239/2, rev 2.00/2.33, addr 3> on usbus7
umodem0: data interface 1, has no CM over data, has no break
$

$ df -h
Filesystem      Size    Used   Avail Capacity  Mounted on
/dev/ada0s1a    898G    807G     20G    98%    /
devfs           1.0K    1.0K      0B   100%    /dev
procfs          4.0K    4.0K      0B   100%    /proc
linprocfs       4.0K    4.0K      0B   100%    /compat/linux/proc
linsysfs        4.0K    4.0K      0B   100%    /compat/linux/sys
tmpfs           9.9G    4.0K    9.9G     0%    /compat/linux/dev/shm
/dev/ada1p1     226G    184G     23G    89%    /Disk2
fdescfs         1.0K    1.0K      0B   100%    /dev/fd
devfs           1.0K    1.0K      0B   100%    /compat/linux/dev
fdescfs         1.0K    1.0K      0B   100%    /compat/linux/dev/fd
tmpfs           9.9G    4.0K    9.9G     0%    /compat/linux/dev/shm
df: File system /media/LG-E430 does not have a block size, assuming 512.
/dev/fuse       895M    610M    285M    68%    /media/LG-E430
$

Wäre es möglich, z.B. mit dd das FreeBSD Image für ARM draufzuschreiben?

 

[-Nuke-]

Nein das wird nichts. Smartphones sind keine PCs und brauchen immer speziell auf den verbauten SoC angepasste Betriebssysteme.

 

[cabriofahrer]

und brauchen immer speziell auf den verbauten SoC angepasste Betriebssysteme.

Ist das denn wirtschaftlich sinvoll? Für fast alle anderen Produkte auf dieser Welt gilt seit Jahren das Motto "Standardisierung"...

 

[CommanderZed]

Ist das denn wirtschaftlich sinvoll? Für fast alle anderen Produkte auf dieser Welt gilt seit Jahren das Motto "Standardisierung"...

Du hast gerade die über viele hunderte eng beschriebener A4 Seiten geführte nachhaltigkeitsdebatte zum Thema Smartphones & viele andere moderne Technik in einem Satz tatsächlich gut zusammengefasst.

Wirtschaftlich sinnvoll ist das aber schon, denn das intersse der Hersteller ist ja nicht das du das Produkt möglichst lange verwendest sondern das du dir gefälligst alle 2 Jahre ein neues kaufst, natürlich das absolut gegenteil von Nachhaltigkeit

/edit Kleine Ergänzung: Genau deswegen gibt es ja bestrebungen innerhalb der EU eine richtlinie zu erstellen das solcherlei Hardware zumindest vom Hersteller relativ lang mit Updates versehen werden - damit kann man zwar noch immer kein eigenes OS installieren, aber zumindest wäre die "normale" Nutzung wesentlich länger und ggf. Umweltfreundlicher - mal schauen ob das kommt

 

[-Nuke-]

Ist das denn wirtschaftlich sinvoll? Für fast alle anderen Produkte auf dieser Welt gilt seit Jahren das Motto "Standardisierung"...

Gemacht werden muss es so oder so. Auf einem PC wird auch pro Mainboard / Chipsatz / Prozessor eine Firmware erstellt (bzw. eine Sammlung davon), die quasi nur auf der Hardware funktioniert für die sie gemacht ist. Nur startet dein PC nicht direkt das Betriebssystem, sondern erst mal ein Zwischenlayer -> EFI (Extensible Firmware Interface). Bevor es EFI gab, war es das BIOS (Basic Input Output System) was gestartet wurde.

Dies stellt dann für das Betriebssystem wie DOS, Windows, Linux oder BSD eine Umgebung bereit, damit diese auf möglichst vielen unterschiedlichen Varianten funktioniert, solange das BIOS/EFI korrekt funktioniert (was es auch gerne mal nicht tut und es dann unter allem was nicht Windows ist Probleme gibt).

Auf einem Smartphone ist es aber gar nicht vorgesehen (und auch gar nicht gewollt), dass du dein Betriebssystem wechselst oder gar irgendwas an der Hardware austauschst. Warum sollte man sich also den Aufwand machen dort so einen Zwischenlayer zu implementieren? Es ist jetzt auch nicht so, dass die Anpassungen an das Betriebssystem groß sind, abseits der Treiber die man eh braucht. Die Änderungen werden halt nur benötigt. Von daher ja, es ist so einfach billiger.

 

[Andy_m4]

Dies stellt dann für das Betriebssystem wie DOS, Windows, Linux oder BSD eine Umgebung bereit, damit diese auf möglichst vielen unterschiedlichen Varianten funktioniert, solange das BIOS/EFI korrekt funktioniert

Naja. Ganz so ist das heutzutage nicht mehr. Ja. Früher bei DOS da war das noch so. Da hat DOS lediglich die BIOS-Funktionen angesprochen um auf z.B. Disks zuzugreifen. Das wurde dann aber mit den 90er Jahren obsolet. Da begann man (schon aus Geschwindigkeitsgründen) via Treiber die Hardware direkt anzusprechen. Die BIOS-Funktionen wurden dann eigentlich nur noch benutzt um all das abzuwickeln was vor dem Betriebssystemstart nötig war.

Nichtsdestotrotz gibt es aber tatsächlich Funktionalitäten die bis heute über BIOS/UEFI abgewickelt werden. Zum Beispiel sind diese Grafik-VESA-Modes (bzw. deren UEFI-Entsprechungen) so eine Sache. Die Treiber die das verwenden funktionieren auf jedem PC ohne an die Grafikhardware angepasste Treiber zu benötigen.

 

[CommanderZed]

Soviel ich weiß nutzen auch alle Bootloader, Windows, Grub1,2, die *BSD varianten etc sicher diese funktionen und auch die Kernel bis sie dann tatsächlich die umfangreicheren Treiber laden

 

[-Nuke-]

Naja. Ganz so ist das heutzutage nicht mehr. Ja. Früher bei DOS da war das noch so. Da hat DOS lediglich die BIOS-Funktionen angesprochen um auf z.B. Disks zuzugreifen. Das wurde dann aber mit den 90er Jahren obsolet. Da begann man (schon aus Geschwindigkeitsgründen) via Treiber die Hardware direkt anzusprechen. Die BIOS-Funktionen wurden dann eigentlich nur noch benutzt um all das abzuwickeln was vor dem Betriebssystemstart nötig war.

Nichtsdestotrotz gibt es aber tatsächlich Funktionalitäten die bis heute über BIOS/UEFI abgewickelt werden. Zum Beispiel sind diese Grafik-VESA-Modes (bzw. deren UEFI-Entsprechungen) so eine Sache. Die Treiber die das verwenden funktionieren auf jedem PC ohne an die Grafikhardware angepasste Treiber zu benötigen.

Das hab ich ja damit auch beschrieben. Das BIOS/EFI initialisiert so ziemlich die gesamte Hardware inkl. Arbeitsspeicher, stellt die ACPI Tabellen bereit, gruppiert die Geräte in ihre IOMMU Gruppen, initialisiert die Grafikausgabe und andere Firmware und startet deinen Bootloader. Auf dieser Basis und so ziemlich nur auf dieser Basis startet dann das Betriebssystem. Ansonsten würde es einfach nichts vorfinden und würde gar nicht wissen was da eigentlich gerade die Arbeit macht. Du würdest nicht mal ein Bild auf den Bildschirm kriegen.

Natürlich lädt das Betriebssystem dann hinterher konkrete Treiber, aber bis dahin ist schon verdammt viel passiert. Und genau das gibt's bei den meisten SBCs nicht und darum braucht es konkrete Anpassungen am Kernel die ihm ganz genau sagen was wo zu finden ist und was er tun muss.

 

[Andy_m4]

Ja. Es klang nur so, das würde man auch nach dem booten über BIOS/UEFI gehen die damit die Hardware wegabstrahieren. Und das ist eben nicht (mehr) so. Das wollte ich nur noch mal klarstellen und Du hast das ja mit Deinem Posting auch noch wunderbar ergänzt.

 

[cabriofahrer]

Das ist alles wirklich sehr interessant. Also letztendlich wird dann doch viel von der Hardware vom Betriebssystem selbst erkannt. Da stellt sich dann die Frage, was würde denn FreeBSD von einem Mobiltelefon an Hardware erkennen? Wäre es denn irgendwie möglich, FreeBSD von einem USB-Stick im Livemodus zu starten? Sprich, dass das Mobiltelefon beim Einschalten von einem externen USB-Stick startet wie bei einem PC, anstatt ins installierte Betriebssytem (Android)?

 

[Andy_m4]

Wäre es denn irgendwie möglich, FreeBSD von einem USB-Stick im Livemodus zu starten?

So ohne Weiteres nicht. Es gibt nicht unbedingt einen standardisierten Weg zum Bootup wie wir es auf der PC-Plattform haben. Das war auch auf dem Raspberry Pi früher zunächst ein Problem.

Also letztendlich wird dann doch viel von der Hardware vom Betriebssystem selbst erkannt. Da stellt sich dann die Frage, was würde denn FreeBSD von einem Mobiltelefon an Hardware erkennen?

Im Mobiltelefon ist üblicherweise keine Standardhardware für die es offene Treiber gäbe. Die Smartphone-Hersteller treiben da durchaus einiges an Aufwand um Android an ihr Phone anzupassen. Darin liegt ja auch die Update-Problematik begründet. Du kannst halt nicht einfach ein Vanilla-Android installieren sondern bist immer auf die angepasste Version des Herstellers angewiesen.

 

[turrican]

Wäre es denn irgendwie möglich, FreeBSD von einem USB-Stick im Livemodus zu starten?

du kannst kein (Android)Smartphone oder -Tablet so starten wie einen PC, so dass es vom USB Stick bootet; die im Device ab Werk eingebrachten Bootloader verhindern sowas bzw sehen so etwas nicht vor; es ist eine in sich geschlossene Welt (fast wie Äppel).

Um überhaupt ein (alternatives) Firmware-Image flashen zu können, muss man vorher meist den Bootloader entsperren bzw auch noch ein Hilfstool installieren (z.B. TWRP) - und da gibts auch nicht für jedes Device eine Herangehensweise;

Um ein Original-OS frisch drüber zu flashen (z.B. wenn ne LineageOS Installation fehlgeschlagen war), braucht man meist auch Hersteller Tools wie den Qualcomm Flash Image Loader (QFIL) für Devices mit Quälcomm SoC - welcher z.B. dann auch nur wieder unter Windows läuft - um das Device überhaupt dazu zu bringen, ein OS Image zu laden;

 

[CommanderZed]

So ohne Weiteres nicht. Es gibt nicht unbedingt einen standardisierten Weg zum Bootup wie wir es auf der PC-Plattform haben. Das war auch auf dem Raspberry Pi früher zunächst ein Problem.


Im Mobiltelefon ist üblicherweise keine Standardhardware für die es offene Treiber gäbe. Die Smartphone-Hersteller treiben da durchaus einiges an Aufwand um Android an ihr Phone anzupassen. Darin liegt ja auch die Update-Problematik begründet. Du kannst halt nicht einfach ein Vanilla-Android installieren sondern bist immer auf die angepasste Version des Herstellers angewiesen.

Ich versuche das mal einfacher zu beschreiben:

Idr. scheiterts schon daran das du einfach kein anderes OS Booten kannst aufgrund der eingeschränkten Boot-Firmware. Das wird bei mehr als 99,5 aller Smartphone Modelle so sein.

Selbst wenn so ein Boot des Kernels möglich ist fangen die Probleme erst so richtig an. Arm ist keine so standardisierte Plattform, es kann schon sein das die CPU an sich nicht richtig unterstützt wird, ganz zu schweigen das man irgendwo eine ausgabe bekommt oder gar die USB-Schnittstelle zum debuggen irgendwie verwendbar bekommt.
Und selbst wenn entwickler da richtig viel Zeit und energie reinstecken und irgendwoher geleakte (!) Dokumentation bekommen (Denn die ist ja anders als zb beim Raspberry nicht verfügbar), hat man einen gebooteten Kernel, USB - aber sonst noch nichts. Kein WLAN, kein X etc.

Kein Smartphone im engeren sinne, aber ich beschäftige mich ja immer noch gerne mit dem PinePhone - dort ist der Bootloader offen und es wurde bewusst möglichst Hardware ausgewählt fürfür die es zumindest ne Chance gibt auf nen frei verteilbaren Linux-Treiber.
Und selbst da hat es lange gedauert bis wirklich ein großteil der Komponenten halbwegs rund läuft. Selbst jetzt, 2 Jahre später sind Kamera und GPS noch immer wackelig. Und das ist ein Gerät das explizit entwickelt wurde um später Linux drauf zu installieren, also um ganze Welten leichter als das was du hier vorschlägst und trotzdem noch problematisch.

Und es gibt dort tatsächlich einen versuch OpenBSD drauf zu portieren (Nochmal für dich: Das ist NICHT vergleichbar mit einem LG II 430 das vom hersteller bewusst so ausgelegt ist keine anderen Betriebsysteme zuzulassen sondern ein Gerät das explizit dafür gedacht ist das Betriebsystem auszutauschen - so gibts zb einen Seriellen Port zum Debuggen in der Kopfhörerbuchse)

ExoticSilicon.com - Crystal installs OpenBSD on the Pinephone - Part 1

www.exoticsilicon.com

Wie man dort lesen kann war es schon ein Problem überhaupt die Stromverwaltung so umzusetzen das das Gerät nicht durch tief-entladung irgendwann komplett funktionslos wird etc.

ExoticSilicon.com - Crystal installs OpenBSD on the Pinephone - Part 6

www.exoticsilicon.com

 

[cabriofahrer]

Das wäre doch mal eine Geschäftsidee, ein Gerät mit einem Pico- oder Femto-ITX Board herzustellen und mit FreeBSD auszuliefern, welches automatisch beispielsweise in eine Gnome-Oberfläche bootet, die natürlich über die üblichen Anwendungen, wie Telefon, Adressbuch, Kamera, etc verfügt. Der unerfahrene Endkunde würde keinen großen Unterschied zu einem anderen Smartphone bemerken, der Kenner hätte unter der Haube direkt ein FreeBSD zur Verfügung, um alles Mögliche damit zu machen, im Zweifel auch irgend ein anderes Betriebssystem zu installieren...

 

[Azazyel]

Das wäre doch mal eine Geschäftsidee, ein Gerät mit einem Pico- oder Femto-ITX Board herzustellen und mit FreeBSD auszuliefern, welches automatisch beispielsweise in eine Gnome-Oberfläche bootet, die natürlich über die üblichen Anwendungen, wie Telefon, Adressbuch, Kamera, etc verfügt. Der unerfahrene Endkunde würde keinen großen Unterschied zu einem anderen Smartphone bemerken, der Kenner hätte unter der Haube direkt ein FreeBSD zur Verfügung, um alles Mögliche damit zu machen, im Zweifel auch irgend ein anderes Betriebssystem zu installieren...

Ich hoffe, du bringst viel Geld mit - das wäre kommerziell völlig aussichtlos.

Mit Pico-ITX oder Femto-ITX anstelle hochintegrierter Hardware hättest du ein vergleichsweise klobiges Gerät mit schlechter Laufzeit, dass unverhältnismäßig teuer wäre und einen noch deutlich kleineren Markt als die Linux-Smartphones bedienen müsste. Zumal GNOME - trotz passabler Touchscreen-Unterstützung - auf dem Smartphone Stand heute für Normalnutzer nicht mit Android oder iOS mithalten kann.

Von Faktoren wie der zusätzlich erstmal notwendigen Unterstützung von Wayland bei FreeBSD wollen wir mal gar nicht anfangen...

 

[CommanderZed]

Das wäre doch mal eine Geschäftsidee, ein Gerät mit einem Pico- oder Femto-ITX Board herzustellen und mit FreeBSD auszuliefern, welches automatisch beispielsweise in eine Gnome-Oberfläche bootet, die natürlich über die üblichen Anwendungen, wie Telefon, Adressbuch, Kamera, etc verfügt. Der unerfahrene Endkunde würde keinen großen Unterschied zu einem anderen Smartphone bemerken, der Kenner hätte unter der Haube direkt ein FreeBSD zur Verfügung, um alles Mögliche damit zu machen, im Zweifel auch irgend ein anderes Betriebssystem zu installieren...

Das was du beschreibst ist exakt die Idee des PinePhones, allerdings mit Linux als OS.

 

[cabriofahrer]

Das was du beschreibst ist exakt die Idee des PinePhones

Basiert das Pinephone denn auf dieser Standardhardware Pico- oder Femto-ITX? Und laut Deinem Bericht ist das Ergebnis ja nicht so zufriedenstellend, also es läßt sich nicht so ohne Weiteres alles Mögliche darauf installieren?

wie der zusätzlich erstmal notwendigen Unterstützung von Wayland bei FreeBSD

Wieso ist Wayland notwendig? Xorg wie gehabt, was sonst?

Zumal GNOME - trotz passabler Touchscreen-Unterstützung - auf dem Smartphone Stand heute für Normalnutzer nicht mit Android oder iOS mithalten kann.

Was ist denn so besonderes auf diesen grafischen Oberflächen enthalten? Also ich sehe nur irgendwelche Icons für irgendwelche Programme wie Telefon, Internet (meist Chrome), Kamera, Settings, etc...

 

[CommanderZed]

Basiert das Pinephone denn auf dieser Standardhardware Pico- oder Femto-ITX? Und laut Deinem Bericht ist das Ergebnis ja nicht so zufriedenstellend, also es läßt sich nicht so ohne Weiteres alles Mögliche darauf installieren?

Nein aber zumindest eine tauschbare Platine etc die man mit einem "freien" OS bespielen kann, da gibt es soweit ich weiß nur 2,3 alternativen. "Standardhardware" wäre auch absolut ungeeignet für den Zweck da nicht auf Stromverbrauch, ansteuerung von nicht-hdmi-bildschirmen, touch & Lte-Hardware, Wärmeabgabe, dicke etc ausgelegt.

Also die Probleme, was mir auch so nicht so bewusst war, sind durchaus komplex. Was "wir" garnicht so bemerken ist das inzwischen eine wirklich lange Entwicklungszeit bei Android und iOS vergangen ist und vieles was uns da "komisch" vorkommt manchmal auch einen technischen sinn hat.

Ich greif hier einfach mal 2 Punkte auf:

Einer der wichtigsten Punkte ist dabei sicher schlicht die Akkulaufzeit, Android kommt bei ähnlicher Hardware auf mehrere Tage Nutzungszeit - ein normaler Linux-Kernel + alles was so mindestens um OS herum gehört eher auf "wenige Stunden". Abhilfe schaft natürlich Standby, aber dann kann man zb keine Nachrichten Empfangen etc. - android bastelt sich da sehr geschickt drumherum.
Aber auch die Anwendungsprogramme selbst, beispielsweise der "Desktop" Browser zieht viel mehr Akku als das Android oder ios Pendant.

Ein zweiter wichtiger Punkt sind ganz schlicht passend skalierende Programme. Das kann ganz Banal der Browser sein bei dem schlicht wichtige Bedienelemente nicht anklickbar sind, oder wo es ein Problem ist das beim "Eingabefeld" dann auch die Bildschirmtastatur kommt etc. Bei vielen "Regulären" Programmen wie Audacious sieht das sogar oft noch wesentlich schlimmer aus.

Da kommt einiges zusammen auf mehreren ebenen.

Ist es komplett unbenutzbar? Nein, auf gar keinen fall. Es ist aber um große Welten weg von der "normalen" Smartphone Erfahrung. Und es wird tatsächlich besser.

Ich vermute vieles funktioniert unter *BSD in diesem Umfeld eher schlechter als besser.

 

[Azazyel]

Wieso ist Wayland notwendig? Xorg wie gehabt, was sonst?

Der Touchscreen-Support von X.org ist katastrophal (selbst mit Touchégg) - das kannst du nicht mal dem hartgesottensten Benutzer zumuten. Erst recht keinem normalen Smartphone-Nutzer, der Android oder iOS gewohnt ist und die Masse der Käufer unseres fiktiven FreeBSD-Smartphones ausmachen soll.

Wayland hat Touchscreens im Protokoll vorgesehen und ist dort um Größenordnungen besser, aber immer noch weit entfernt von Android oder iOS.

Was ist denn so besonderes auf diesen grafischen Oberflächen enthalten? Also ich sehe nur irgendwelche Icons für irgendwelche Programme wie Telefon, Internet (meist Chrome), Kamera, Settings, etc...

Hast du es mal ausprobiert? CommanderZed hat schon ein paar Beispiele genannt. Ich möchte noch die Gestenerkennung anführen, die unter GNOME/Wayland ausbaufähig und unter GNOME/X.Org eine Zumutung ist.

Beim Touchscreen als unterstützendes Element für Laptops - die man hauptsächlich mit Trackpad/Maus und Tastatur bedient - ist das Nutzererlebnis mit GNOME/Wayland Stand heute akzeptabel. Beim Smartphone ist es sehr grenzwertig. Es wird aber zumindest jedes Jahr besser.

Unter X.Org ist es so schlecht und ohne jegliche Chance auf Besserung (das gibt das Design von X11 auch gar nicht her), es steht auf völlig verlorenem Posten.

Wenn ein zentrales Element der Smartphone-Bedienung mit X.Org niemals funktionieren kann, ist das Projekt FreeBSD-Smartphone Stand heute von vornherein zum Scheitern verurteilt.

 

[CommanderZed]

Beim Touchscreen als unterstützendes Element für Laptops - die man hauptsächlich mit Trackpad/Maus und Tastatur bedient - ist das Nutzererlebnis mit GNOME/Wayland Stand heute akzeptabel. Beim Smartphone ist es sehr grenzwertig. Es wird aber zumindest jedes Jahr besser.

Unter X.Org ist es so schlecht und ohne jegliche Chance auf Besserung (das gibt das Design von X11 auch gar nicht her), es steht auf völlig verlorenem Posten.

Wenn ein zentrales Element der Smartphone-Bedienung mit X.Org niemals funktionieren kann, ist das Projekt FreeBSD-Smartphone Stand heute von vornherein zum Scheitern verurteilt.

Das ist eine echt gut zusammenfassung der Probleme, X.Org ist auch zumindest lt. diverser Foren und "grob" auch bei mir Energiefressender als Wayland.

Zumindest scheint das OpenBSD Team Wayland lt. den Mailinglisting "sich mal vorsichtig näher anzuschauen" - zumindest hab ich das aus dem ein oder anderen Post da rausgelesen - und OpenBSD läuft ja auch auf dem pinephone - ich hab noch (nicht erstnhafte) Hoffnungen

Aus verschiedenen Gründen lag das Pinephone die letzten Monate eher im Schrank, ich hab jetzt aber auch die Tastatur und wollte dem sxmo mit archlinux mal ne chance geben, in einem ersten Test hat mir die Oberfläche recht gut gefallen.

 

[foxit]

Zumindest scheint das OpenBSD Team Wayland lt. den Mailinglisting "sich mal vorsichtig näher anzuschauen" - zumindest hab ich das aus dem ein oder anderen Post da rausgelesen

Das wäre ja auch vom Thema Sicherheit sinnvoll. Fährt OpenBSD nicht einen eigenen X11 Fork?

 

[Andy_m4]

Fährt OpenBSD nicht einen eigenen X11 Fork?

Ja: http://xenocara.org/

 

[cabriofahrer]

Ich sehe schon, das sind natürlich alles Aspekte, derer ich mir nicht bewusst war. Und wie ist das hier nur möglich?

Einer der wichtigsten Punkte ist dabei sicher schlicht die Akkulaufzeit, Android kommt bei ähnlicher Hardware auf mehrere Tage Nutzungszeit - ein normaler Linux-Kernel + alles was so mindestens um OS herum gehört eher auf "wenige Stunden".

Wie kann es eine solche Diskrepanz im Stromverbrauch zwischen verschiedenen Betriebssystemen geben? Ich dachte, der Stromverbrauch sei hauptsächlich durch die Hardware selbst bestimmt. Ich kann z.B. die Akkulaufzeit verlängern, indem ich Piepstöne und Vibrationen für das Antippen eines jeden Buchstabens oder Zeichens deaktiviere. Oder auch für Benachrichtigungen von z.B. Whatsapp. Denn es ist klar, jedes Piepsen und jedes Vibrieren zieht in dem Moment Strom, was zu einer kürzeren Akkulaufzeit führt.
Aber eine Diskrepanz von mehreren Tagen zwischen einem normalen Linux-Kernels und Android?

 

[Andy_m4]

Wie kann es eine solche Diskrepanz im Stromverbrauch zwischen verschiedenen Betriebssystemen geben?

Ganz einfach deshalb, weil viele Stromsparmechanismen ja durch Betriebssysteme bestimmt werden. Nicht alles läuft unabhängig vom System rein in Hardware ab. Sowas simples für das bekannte runtertakten der CPU geschieht ja auch durch Software.

Aber eine Diskrepanz von mehreren Tagen zwischen einem normalen Linux-Kernels und Android?

Android macht ja noch wesentlich mehr. Zum Beispiel auch wie Apps ablaufen usw. ist ja durchaus zu dem verschieden, wie auf nem Desktop-System Programme ablaufen.
An Deinem WhatsApp-Beispiel kann man das mal näher erläutern:

Oder auch für Benachrichtigungen von z.B. Whatsapp. Denn es ist klar, jedes Piepsen und jedes Vibrieren zieht in dem Moment Strom, was zu einer kürzeren Akkulaufzeit führt.

Na wichtiger ist halt, wie die App auf Benachrichtigung wartet. WhatsApp kann natürlich die ganze Zeit selbst nachgucken, ob neue Nachrichten da sind um dem Benutzer das mitzuteilen. Aus Stromverbrauchssicht wäre aber ein solches Vorgehen eher ineffizient, da WhatsApp die ganze Zeit läuft und damit Hardware-Ressourcen beansprucht. Also legt Android WhatsApp schlafen (so das es nahezu keine CPU-Kapazität und damit kein Strom benötigt) und weckt es auf, wenn ein passendes Event eintrifft.
Das ist jetzt sehr vereinfacht und verkürzt erklärt, aber sollte klar machen, warum und wie ein System Stromverbrauch selbst optimieren kann.

 

[goblin]

Android hatte übrigens sehr lange Zeit Mechanismen zum Strom sparen, die nicht im allgemeinen Linux-Kernel verfügbar waren, sondern nur in den Forks von Google. Aber ich meine inzwischen wurde fast alles von Upstream aufgenommen, aber ist standardmäßig trotzdem nicht aktiv. Selbst ein Linux-Telefon mit Standard-Kernel kann also üblicherweise nicht mit Android mithalten, weil sie die Mechanismen nicht aktiviert haben. Ich weiß gerade aus dem Stegreif nicht mehr, wie sie alle heißen, mir fällt nur noch das wakelock ein. Im Endeffekt ist das Prinzip, wie Andy_m4 beschrieben hat, dass der Kernel möglichst oft in den Tiefschlaf geht um die Haupt-CPU schlafen zu legen. Aber damit das funktioniert müssen die Apps das entsprechend unterstützen, deswegen hat Android beispielsweise nicht den klassischen main() Einstiegspunkt für Programme, sondern verwendet ein stark integriertes Java-Framework, das darauf ausgelegt ist, jederzeit unterbrochen zu werden. Das ist jetzt aber alles stark vereinfacht