Software-update: LineageOS 23.0

LineageOS logo (79 pix)Versie 23 van LineageOS is beschikbaar gekomen. LineageOS is de opvolger van CyanogenMod en een opensourcebesturingssysteem voor smartphones en tablets. Het is gebaseerd op een kale versie van Android en voegt extra functionaliteit toe, waaronder snelkoppelingen in de notificatiebalk, een uitgebreid lockscreen en verschillende thema's voor de interface. Verder zijn er vaak prestatieverbeteringen waar te nemen ten opzichte van de software die een fabrikant zelf meelevert. LineageOS versie 23 is gebaseerd op Android 16 en de releasenotes voor deze uitgave zien er als volgt uit:

23 - Primetime Release

This last year has been a whirlwind to say the least, but we have remained dedicated to bringing an updated LineageOS based on Android 16 to the masses! We’ve been hard at work rebasing all of our changes and features since Android 16’s release in June. Android 16’s first release mainly contained iterative improvements and some UI/UX refinements, but due to our previous efforts adapting to Google’s UI-centric adjustments in Android 12 through 14, we were able to rebase onto Android 16’s code-base faster than anticipated. Yes you read that right: We’re early this year! Other components have complicated our release and security patching efforts, but we’ll get to that shortly. Google’s Patch Cadence, and LineageOS Going Forward.

Firstly, what even is an ASB? Or a QPR?
  • ASB (Android Security Bulletin) – Google’s monthly roundup of newly fixed security vulnerabilities across the Android ecosystem. Distributed as a list of patches and security branch updates for older but still supported Android versions, with the current version tagged monthly. These updates let projects like ours and OEMs stay aligned with Google’s security baseline.
  • QPR (Quarterly Platform Release) – Mid-cycle updates to a given Android version, landing every few months. QPRs bring not just security fixes but also bug fixes, performance improvements, and feature changes (like Material 3 Expressive in 16 QPR1).
Okay, why are you telling me this?

You’ll notice we are choosing to release LineageOS 23.0, and not 23.1. That’s because it’s based on Android 16’s initial release (what we’ll call QPR0), even though QPR1 has already rolled out to Pixels. The catch? Google never pushed QPR1’s source to AOSP. They’ve said it’ll come “in the coming weeks” (source), but right now only contracted partners have access. And to answer the immediate question, the likelihood that any custom ROM will ever be a contracted Google partner is near 0.

On top of that, Google’s handling of ASBs has shifted (source). July was empty for the first time since the program began, August had a single patch, and September omitted patches for several listed vulnerabilities, with fixes shared privately to partners under embargo. The result is that AOSP security updates are no longer released in full on a monthly basis. Instead, only vulnerabilities deemed “high risk” (i.e. actively exploited in the wild) will be published by Google in the monthly ASBs, and even then, the underlying patches are often not made public immediately.

On a quarterly cadence, Google now issues larger security bulletins that include patches for vulnerabilities originally discovered in prior months. These quarterly bulletins coincide with QPRs (Quarterly Platform Releases), which bundles those security fixes together with feature updates, but have so far not been pushed to AOSP at the time of release. This is why you’ve seen the LineageOS 22.2 security patch level remain reflective of August well into September. In short: this cadence is now the norm, and we need to adapt.

And I heard that Google stopped pushing Pixel source?

Yes, Google has pulled back here too. Pixel kernels are now only offered as history-stripped tarballs, available privately on request, with no device trees, HALs, or configs. Thanks to projects like CalyxOS, Pixels will likely remain well supported, but they’re no longer guaranteed “day one” devices for LineageOS. Pixel devices are now effectively no easier to support than any other OEM’s devices. In short, this just makes things harder, not impossible.

How does this affect LineageOS? And me?

It means we adapt. Instead of waiting indefinitely for QPR1’s source, we’re shipping 23.0 now on “QPR0”, with the publicly available ASB patches applied, and we’ll only attest to a security patch level once we have access to all of its fixes. When QPR1 (and future QPRs) eventually land in AOSP, we’ll merge or rebase as appropriate. This does mean some features (like Material 3 Expressive) aren’t here yet. But it ensures users get timely builds, the most complete security fixes we can legally access, and a clear path forward without being stuck in limbo. This will likely be the expected norm for Android 17 and beyond, so expect more .0 releases in the future!

TL;DR:
  • Google no longer pushes monthly tags and patches to AOSP; and most fixes/security patches are now pushed quarterly, if at all.
  • Security patch levels may occasionally lag: we only increment them once all patches are public.
  • LineageOS 23.0 is based on Android 16 “QPR0” because QPR1’s source isn’t public yet.
    • Because of this some headline features (like Material 3 Expressive) will come later, once sources drop.
  • Pixel support continues, but with reduced source access, they’re no longer guaranteed, let alone on day one.
Legacy Devices

The bad news extends a bit further here, though it’s less surprising than the earlier sections. Google’s increased reliance on newer eBPF features has made supporting devices with older Linux kernels increasingly difficult. Android 16 “QPR0” “requires Linux 5.4 and above, and at the time of writing, the necessary features have only been properly backported as far back as 4.14.

Unfortunately, LineageOS 22.2 still supports many devices running 4.4 and 4.9. As of now, no complete backports of the required features exist for these kernels. The silver lining is that, unlike the massive device loss we saw moving off LineageOS 18.1, these versions could be salvaged if someone were to take on the work of adapting the backports. If you do succeed, please reach out to devrel(at)lineageos.org, we’d be happy to review it! We’re currently targeting only shipping kernels that have 1:1 eBPF backports to make them feature equivalent to Linux 5.4 from here on out to avoid compatibility issues.

Back to the Good Stuff!
  • Security patches from September 2024 to August 2025 have been merged to LineageOS 20 through 23.0.
  • SeedVault and Etar have both been updated to their newest respective upstream version, with multiple fixes having been sent back to the relevant upstream repos!
  • WebView has been updated to Chromium 140.0.7339.51.
  • Contributor demon000 (Cosmin Tanislav) has started work on an awesome set of tools to assist maintainers in device bringups from scratch! They’re still in-progress, but are staged to make a lot of our efforts significantly easier and more streamlined - so stay tuned! Maybe a rare non-yearly blog post? ;)
  • Contributor 0xCAFEBABE has extended support for various VirtIO configurations (QEMU/crosvm/UTM/libvirt, etc.) targets! Though these aren’t supported officially, there is an awesome, comprehensive guide for building and utilizing these targets on the Wiki. There is even a newer one allowing you to run LineageOS in a UTM virtual machine on an Apple Silicon Mac!
  • Contributor 0xCAFEBABE has added support for Cuttlefish targets!
  • Contributor 0xCAFEBABE has extended support for devices booting Android on the mainline Linux kernel! This will allow us to in theory boot LineageOS on almost all devices supported by the Linux kernel. It’s in early phases, but very promising, with several successful device ports already available on the LineageOS GitHub organization! Check the search term “mainline” on the organization’s search bar.
  • LineageOS is now nearly Android.mk free! Google announced their move from make to soong many years ago, pushing developers to migrate from Android.mk to Android.bp, and has started blocking Android.mk in many locations of the source tree.
    • While converting these is a seemingly simple task - in practice it involved countless hours of converting conditional checks, regression testing, and thousands of individual patches. As of this writing, LineageOS introduces less than 10 Android.mk files at a platform level, and many of these are in the process of being converted. In short - we’re ready for when Google kills support for Android.mk.
    • 0xCAFEBABE also created a build target for converting from mk to bp, a WIP feature to assist developers in migrating to soong!
  • Both the Charging Control, and Fast Charge Control features have received many updates and improvements.
  • A new set of ringtones and alarms from Plasma Mobile have been included.
Application Updates

LineageOS isn’t just about the OS itself: our suite of core apps continues to evolve as well. This cycle brings some major improvements:

Aperture (Camera)

Our camera app, Aperture, has been rewritten from the ground up. The rewrite makes the app much easier to maintain, while also bringing new features:

  • Support for JPEG Ultra HDR, RAW, and simultaneous RAW+JPEG capture.
  • A redesigned notification island with dynamic colors, and new indicators (JPEG Ultra HDR, RAW, battery, thermal throttling).

Keep your system updated (or keep updating the app if you’re using the app standalone), since we plan to introduce more features and improvements over time (believe it or not, nowadays the only obstacle is Google’s CameraX library, which has slowed down the development of certain components which we use in Aperture). We do have some plans to overcome this though.

Twelve (Music Player)

Our music player, Twelve, didn’t need a full overhaul this year, but it did get some polish and some new features:

  • Added a “Play random songs” button for quicker library playback.
  • Updated the Now Playing screen with playback statistics (for the nerds and audiophiles out there).
  • Added the ability to rescan the local media store, so newly added music shows up without needing a reboot.
  • Expanded Jellyfin integration, including suggestions, favorites, and better thumbnail handling.
  • Added MIDI playback support.
New App, Again?

We’re excited to debut Catapult, our brand-new custom launcher for Android TV. Catapult is built with the same principles we bring to the rest of LineageOS: clean, simple, functional design, with thoughtful user experience at its core. Why build a new launcher? For years, Android TV and Google TV users have been stuck with preloaded launchers that aggressively push advertising and recommendations users can’t control. Catapult changes that. It strips away the clutter, gives you back your home screen, and lets you decide what belongs front and center.

With Catapult, you get a fast, intuitive interface that focuses on your apps and your content: no forced feeds, no “sponsored” rows, just a launcher that works the way you expect. We’re also planning to add more features in the future, you’ll see them appear as you keep your device up to date, stay tuned!

Extended QEMU-Based Virtual Machine Support

LineageOS has long been a favorite for developers and tinkerers, and with 23.0 we’ve expanded support for virtualized environments. Thanks to extended QEMU integration spearheaded by developer 0xCAFEBABE, it’s now easier than ever to run LineageOS in VMs for testing, debugging, or just exploration. This means developers can spin up consistent environments on their desktops without needing dedicated hardware, and testers can reproduce tricky issues with greater reliability. Whether you’re validating patches or just curious to see how LineageOS runs under the hood, the tooling is smoother and more accessible.

If interested, take a look on the Wiki. You can run LineageOS via libvirt on Linux/Windows, and on an Apple Silicon Mac with UTM. Additionally, LineageOS now supports Cuttlefish build configurations, which are similar to the emulator family of targets, but has extra emulated peripherals, so as to act more like a real device! You can view a list of all the differences here.

Mainline Kernel Support

Another big milestone in 23.0 is our improved support for devices running Linux mainline kernels. While Android has historically relied on heavily modified vendor kernels, the ecosystem is shifting toward mainline for long-term stability and maintainability.

With 23.0, developer 0xCAFEBABE has spearheaded an effort to extend compatibility for devices capable of booting the mainline Linux kernel, and we’ve made it easier for maintainers to bring their devices closer to upstream with inheritable common trees. The end result? For now, nothing, but in the future, we will hopefully be able to boot Android on almost any device that is supported by the mainline Linux kernel.

This effort should help keep devices alive well past the point where their proprietary components stop working with newer Android releases. See the following repos if interested! (1, 2, 3, 4)

Careful Commonization

Several of our developers have worked hard on SoC-specific common kernels to base on that can be merged on a somewhat regular basis to pull in the latest features/security patches to save maintainers additional effort. Go check them out and consider basing your device kernels on them!

Supported SoCs right now are:

SoC (system-on-chip) Kernel Version Android Version
Qualcomm MSM8998/MSM8996 4.4 13, 14, 15
Qualcomm MSM8953 4.9 13, 14, 15
Qualcomm SDM845 4.9 13, 14, 15
Qualcomm SM8150 4.14 13, 14, 15, 16
Qualcomm SDM660 4.19 13, 14, 15, 16
Qualcomm SM8250 4.19 13, 14, 15, 16
Qualcomm SM8350 5.4 13, 14, 15, 16
Qualcomm SM8450 5.10 13, 14, 15, 16
Qualcomm SM8550 5.15 13, 14, 15, 16
Qualcomm SM8650 6.1 14, 15, 16
Qualcomm SM8750 6.6 15, 16

Moreover, many legacy devices require interpolating libraries that we colloquially refer to as “shims” - these have long been device and maintainer managed, but this cycle we have decided to commonize them to make the effort easier on everyone and not duplicate effort! You can check it out here and contribute shims that you think other devices may need or add additional components to additional shims and compatibility layers provided via Gerrit!

Deprecations

Overall, we feel that the 23.0 branch has reached feature and stability parity with 22.2 and is ready for initial release. We will allow new LineageOS 21 submissions to be forked to the organization, but we will no longer allow newly submitted LineageOS 21 devices to ship. LineageOS 23.0 will launch building for a decent selection of devices, with additional devices to come as they meet the requirements specified by the Charter and are made ready for builds by their maintainer.

Upgrading to LineageOS 23.0

To upgrade, please follow the upgrade guide for your device by clicking on it here and then on “Upgrade to a higher version of LineageOS”. If you’re coming from an unofficial build, you need to follow the good ole’ install guide for your device, just like anyone else looking to install LineageOS for the first time. These can be found at the same place here by clicking on your device and then on “Installation”.

Please note that if you’re currently on an official build, you DO NOT need to wipe your device, unless your device’s wiki page specifically dictates otherwise, as is needed for some devices with massive changes, such as a repartition.

Lineage OS 19

Versienummer 23.0
Releasestatus Final
Besturingssystemen Android
Website LineageOS
Download https://wiki.lineageos.org/devices
Licentietype GPL

Door Bart van Klaveren

Downloads en Best Buy Guide

12-10-2025 • 09:00

28

Submitter: tszcheetah

Bron: LineageOS

Reacties (28)

Sorteer op:

Weergave:

Ik zit eens even die changelog door te te lezen maar ik vind dit allemaal wel zorgwekkend worden:
TL;DR:

Google no longer pushes monthly tags and patches to AOSP; and most fixes/security patches are now pushed quarterly, if at all.

Security patch levels may occasionally lag: we only increment them once all patches are public.
  • LineageOS 23.0 is based on Android 16 “QPR0” because QPR1’s source isn’t public yet.
Because of this some headline features (like Material 3 Expressive) will come later, once sources drop.

Pixel support continues, but with reduced source access, they’re no longer guaranteed, let alone on day one.
Ik ben benieuwd waar deze ontwikkelingen naar toe gaan en waarom Google er voor kiest de AOSP niet meer direct te voorzien van nieuwe code maar dit wel aan hun partners te geven. Juist doordat Android (maar ook bijvoorbeeld ook Chromium) open source is heeft het zoveel aan populariteit gekregen. Als ze dit langzaam aan het afbouwen zijn dan gaat dit wel gevolgen hebben voor de adoptie in de toekomst.
Dit lijkt me logisch toch?

Google is geen fan van alle alternatieve android versies, voornamelijk omdat die veel tracking en reclame uitzetten. Dus google maakt dat bewust moeilijker. Apps sideloaden is laatst al aangepakt. Nu pakken ze langzaam custom roms aan.

Betreft adoptie in de toekomst, waar ga je dan naartoe? Apple? Niet veel beter. Windows Phone? Bestaat niet meer.

Er is geen noemenswaardige andere telefoon software. Als je iets bouwt is je marktaandeel te klein om appmakers te overtuigen om voor jou software te ontwikkelen. Waardoor niemand je telefoon gaat kopen.
Nu staan we met de rug tegen de muur inderdaad. Maar als google support laat schieten dan zullen we naar andere oplossingen moeten gaan kijken. Denk aan:Dit soort projecten gaat allemaal een boost krijgen als google besluit te stoppen met AOSP.

Persoonlijk heb ik helemaal geen zin om sofware te moeten draaien van een partij waar ik zelf het eind product ben en gelukkig zijn er meerdere die er zo over denken.
Het probleem is mijn optiek dat de consument ook lui is geworden en iets koopt, wat ze over een aantal jaar toch weer weggooien.

Neem bijvoorbeeld al die cloud apparaat. De vendor stopt ermee, en alles wordt gewoon weggegooid. We zijn gewend een deurbel te kopen, waarbij ondersteuning stopt of het nieuwere model te kopen. De consument vind dat eenvoudiger, want ze kennen de maker en het werkt in hun ecosysteem. Ik noem nu een deurbel, maar je kan het ook zeggen over speakers, TVs, IoT, etc. We zijn gewoon een weggooi maatschappij geworden (kijk maar naar kleding).

Ditzelfde is dus ook op mobiel en desktop zo. Waarom zou je Linux installeren, als je Windows gewend bent (hoe ** het is ook geworden)? Waarom zou je iets anders als Android gebruiken, als het merendeel van je apps erop zitten? En wellicht ook het meeste van je kennisen.

Mensen vinden de overstap van Android naar iOS al super lastig (of visa versa). Begrijp mij niet verkeerd, ik wil heel graag meer concurrentie (geef er maar 4/5), maar de consument doet helaas gewoon geen moeite meer. We willen allemaal Europese alternatieven, gebruiken het èèn week, en zeggen dan 'ik ga wel weer terug naar Google'.

[Reactie gewijzigd door HollowGamer op 12 oktober 2025 10:37]

Dit soort projecten gaat allemaal een boost krijgen als google besluit te stoppen met AOSP.

Persoonlijk heb ik helemaal geen zin om sofware te moeten draaien van een partij waar ik zelf het eind product ben en gelukkig zijn er meerdere die er zo over denken.
Het is leuk hoor, als een paar nerds overstappen naar dat soort platformen. Maar zolang veel gebruikte apps als whatsapp/signal er niet op werken dan gaat er nooit een grote groep mensen over stappen.

Laat staan dingen als apps van de bank, social media, nieuws apps, 9292 (in nederland dan).

Blijft dus gerommel in de marge vrees ik.
Het zijn inderdaad message apps, bank apps, DigiD en de rest is wel af te vangen met een progressive web app.

Klinkt op zich toch ook niet heel spannend.

Maar als we het in Europa echt zo belangrijk vinden dat we soevereiniteit hebben en privacy belangrijk vinden dan is dit denk ik wel af te dwingen met een stukje wetgeving.

Maar dan moet Google wel echt stoppen met AOSP want anders gaat dit niet gebeuren. Vandaar ook dat ik me afvroeg of dit een trent is of dat google net genoeg opensource blijft leveren om de mensen "tevreden" te houden.
Als we de statistieken van LineageOS mogen geloven, gaat het hier om een druppel op de hete plaat. Ik geloof nier dat het Google ook maar iets kan schelen dat iemand een custom ROM maakt.

Het ondersteunen van de mogelijkheid voor het bouwen van custom ROM's en alles zo snel mogelijk open sourcen kost wel tijd en moeite. Daar lijken ze mee gestopt te zijn na een ontslaggolf en besparingsmaatregelen.

Hun vulnerability management lijkt nu gericht te zijn op business-to-business in plaats van open source. Het is voor partnerbedrijven een stuk makkelijker en voorspelbaarder om patches uit te brengen als er een gezamenlijk embargo voor dat soort patches is, zodat een Sony niet als de wiedeweerga een patch de deur uit moet duwen omdat Samsung een update heeft uitgebracht met de patch ingebouwd en de kwetsbaarheid dus op straat ligt.

Dit lijkt me minder een gevalletje "Google wil custom ROMs uitroeien" en meer "Google heeft geen zin meer om hun dure ontwikkelaars werk te laten doen waar alleen de open source community wat aan heeft". Ze zouden nog veel verder kunnen gaan (bijvoorbeeld Fuchsia als kernel nemen bij de volgende Pixel waardoor ze de kernel sources niet eens vrij hoeven te geven, of de mogelijkheid om de bootloader te locken na het flashen van custom ROMs op je Pixel uitzetten zoals alle andere merken hebben gedaan).
Als we de statistieken van LineageOS mogen geloven, gaat het hier om een druppel op de hete plaat. Ik geloof nier dat het Google ook maar iets kan schelen dat iemand een custom ROM maakt.
Ik ben het grotendeels met je verhaal eens, maar ik vraag me af of Google ook niet aan het voorsorteren is op ver(der)gaande maatregelen van de Trump-regering. Er is ook het narratief dat Chinese Android vendors die geen gebruik maken van Google Play Services etc. Amerikaanse intellectuele eigendom stelen (wat natuurlijk een nonsense-verhaal is, aangezien AOSP open source is). Deze stappen snijden Chinese fabrikanten die hun eigen app store e.d. hebben af van gratis gebruik van AOSP en in plaats daarvan of contracten met Google moeten afsluiten om een partner te worden of zelf de mankracht moeten leveren om een AOSP-fork te ontwikkelen.

Op een vergelijkbare manier vergroot dit B2B lock-in van devices die Android gebruiken zonder Google Play Services (bijv. appliances die geen Google Play Store nodig hebben). Vroeger kon je bijv. gewoon je eigen e-reader of wat dan ook maken op basis van AOSP, nu heb je een partnercontract nodig om op tijd security updates e.d. to krijgen en met zo'n contract kan Google voorwaarden opleggen.

Om maar te zeggen dat Google hier meerdere vliegen in één klap slaat.

[Reactie gewijzigd door danieldk op 12 oktober 2025 11:23]

Juist doordat Android (maar ook bijvoorbeeld ook Chromium) open source is heeft het zoveel aan populariteit gekregen. Als ze dit langzaam aan het afbouwen zijn dan gaat dit wel gevolgen hebben voor de adoptie in de toekomst.
99.99% van de gebruikers kan het absoluut niet schelen of het wel of niet open source is, laat staan dat ze weten wat dat überhaupt betekend. Google die zijn macht heeft gebruikt om partners binnen te harken en vervolgens ervoor te zorgen dat diezelfde partners geen kant meer op konden is wat Android zo populair heeft gemaakt. Niet meer, niet minder.

Google kan Android's source volledig achter gesloten deuren houden en het zou op een paar boze open source devs geen verschil maken. Want wat ga je doen? Overstappen naar een ander mobiel OS? Right...

Sterker nog, Google is al jaren Android meer en meer closed source aan het maken. Als je op Android zit omdat het open source is, dan ben je gewoon al enkele jaren (dan niet een decennia) niet meer mee met wat Google met Android doet. AOSP is praktisch een onbruikbaar zootje.
Als ze dit langzaam aan het afbouwen zijn dan gaat dit wel gevolgen hebben voor de adoptie in de toekomst.
Ze rekenen er bij google op dat men bijzonder zelden van os-ecosysteem wisselt, laat staan overstapt op een optie buiten de twee "big tech" systemen.

Kijk maar op tweakers: zelfs hier wordt overwegend meesmuilend gelachen als linux wordt genoemd als mogelijk alternatief voor "end of ten". Beeld je de reactie maar in bij het mobieltje, waar een eigen os installeren nóg "exotischer" is.
Het is jammer dat de play integrity bij custom roms niet meer werkt.
Nice. Mijn vier jaar oude toestel werd origineel geleverd met Android 11 en kwam officieel nooit verder dan Android 13. Nu draait Android 15 en straks gaat er Android 16 op dankzij LineageOS. Alleen nog even wachten totdat LineageOS with microG builds beschikbaar zijn.

[Reactie gewijzigd door The Zep Man op 12 oktober 2025 14:18]

Google heeft te veel macht en is veel te groot geworden.. wie had deze monopolie op mobiel, en met Chrome in de browser wereld, ooit zien aankomen? /s
Juist doordat Android (maar ook bijvoorbeeld ook Chromium) open source is heeft het zoveel aan populariteit gekregen.
Ik denk persoonlijk dat het grote publiek het geen bal uitmaakt of de broncode publiek is. Android en Chromium zijn financieel gratis te gebruiken, en gebruiksvriendelijk (subjectief). (En Android-apparaten bestaan ook in goedkopere edities.)
Het grote publiek inderdaad niet. Maar wel de devs. En uiteindelijk is het grote publiek afhankelijk van de devs.
En devs afhankelijk van het grote publiek. Sailfish, mooi OS, Europees, geen publiek. FirefoxOS, geen publiek, Ubuntu Touch, geen publiek. Het is een bijna gesloten feedback loop, publiek<->devs.
Maar dat is nu zo omdat er wel een AOSP is. Als Google dit project langzaam aan het afbouwen is zou er dan geen alternatief komen waar ineens wel publiek voor is?
Waarom zou dat een verschil maken? Ik zou zeggen dat dat heel naief is. Het kan devs geen bal schelen of iets open source is of niet. AOSP is nu al op het randje van de dood, en het mogen duidelijk zijn dat het niemand echt wat kan schelen. Tenzij Google zijn OEMs het mes in de rug steekt gaat er echt geen haar veranderen.
Ik neem aan dat het vooral de smartphone-makers zijn die Google's steeds sterkere grip op het Android-ecosysteem met argusogen volgen (en het dus wel wat kan schelen). Reken maar dat Samsung een draaiboek heeft liggen voor als ze vinden dat Google hun macht te ver inperkt. Er is een reden waarom ze een eigen app store hebben, een eigen Find netwerk, Samsung Pay, etc. Ze willen een eigen ecosysteem houden waar zij bepalen hoe ze er waarde uit kunnen extraheren, maar ook willen ze Google onder druk zetten met de nucleaire optie volledig van het Google ecosysteem te splitsen.

Helaas (voor de andere telefoon-makers) heeft alleen Samsung genoeg marktaandeel in het Westen en niet-Chinees Azië om Google onder druk te zetten en in het uiterste geval te forken. Verder geloof ik ook niet dat Samsung open source heel erg belangrijk vindt.
Is dat zo? Ik ken legio dev's die er geen probleem mee hebben om aan closed-source software te werken en de tools die ze gebruiken ook niet open-source zijn.

Of bedoel je dat niet ?
Ik bedoel hier echt het telefoon os. Omdat je telefoon toch wel het meest persoonlijke device is wat je maar kunt hebben.

Zelf voel ik me er al niet prettig bij dat de modem van mijn telefoon bestaat uit gesloten driver blobs. Als mijn gehele telefoon een gesloten apparaat zou zijn dan zou dit voor mij een reden zijn op zoek gaan naar een ander hand-held device om mijn berichtjes te kunnen typen en contact te kunnen leggen met andere mensen.
Dat is helaas wel het geval. Liever had ik dat niet meer gezien, opensource zit niet in gratis, het voordeel is dat je de broncode ziet en weet wat je kan verwachten als developer.

Voor werk gebruiken we bijvoorbeeld services, die volledig opensource zijn, maar neem je de dienst bij hun af. Sterker nog, ook vaak een feature gebouwd voor hun, omdat ik het nodig had en zij er blij mee waren. Het is een soort win-win voor beide partijen.

De nieuwe Intel ceo begrijpt dit bijvoorbeeld niet. Die zit opensource als kost, zelfde als Oracle en IBM. Het levert juist enorm veel op, omdat mensen je codebase kunnen snappen, en zelfs daarop weer tools bouwen. Betaalde ondersteuning is nog altijd mogelijk, en lijkt me beter dan de gekraakte versies die vroeger de standaard waren.

Android (dus Google) profiteert juist enorm van iets als GrapeneOS en ook met Lineage OS. Zij waren de eerste met de source, en haalde vaak ook de bugs eruit. Een gemiddelde vendor zal die code/exploit echt niet contributen terug.

[Reactie gewijzigd door HollowGamer op 12 oktober 2025 10:45]

Maar doel je hier dan op de ontwikkelaars van alternatieven zoals LineageOS of software in z’n algemeen?

Het leeuwendeel van de consumenten zal nooit een ander besturingssysteem op hun apparaten installeren. Voor haar grote publiek is open source ook indirect geen noodzaak. Kijk naar de populariteit van gesloten systemen zoals Windows, MacOS, iOS, enz. Allemaal gesloten systemen waar gigantisch veel software voor is, en dat gigantisch veel gebruikt wordt bij het grote publiek.

Ik zeg dus niet dat de filosofie achter open source niet goed is, of niets toevoegt, maar het grote publiek lijkt het niet te interesseren. Dat het financieel goedkoop/gratis is des te meer.
Ik doel in dit geval specifiek op een telefoon OS. Je telefoon is toch wel het meest geïntegreerde stukje hardware in je leven. En gelukkig zijn er devs die zich hard maken dat dit kan met FOSS.

Ik denk echt als google besluit te stoppen met AOSP dat een soort gelijke backlash gaat krijgen als VMware met broadcom. Mensen gaan massaal op zoek naar alternatieven omdat ze upstream niet vertrouwen.

Maar wellicht komt google (net als broadcom met esxi ondertussen - of Microsoft met zijn EOL op win10) wel terug op zijn besluit en/of is de enige impact voor nu dat AOSP een weekje of 2 later gereleased wordt en dan zal het allemaal wel blijven zoals het nu is.
Ik doel in dit geval specifiek op een telefoon OS. Je telefoon is toch wel het meest geïntegreerde stukje hardware in je leven.
Tenzij je een pacemaker hebt.
Ik denk echt als google besluit te stoppen met AOSP dat een soort gelijke backlash gaat krijgen als VMware met broadcom. Mensen gaan massaal op zoek naar alternatieven omdat ze upstream niet vertrouwen.
Wat komt overeen met VMWare en AOSP? Gebruikers zijn techneuten.

De massa is geen techneut en zal geen verschil merken.

[Reactie gewijzigd door The Zep Man op 12 oktober 2025 12:08]

Mijn punt is meer dat als techneuten/devs besluiten iets anders te gaan gebruiken dat er dan wel iets gaat veranderen.

Het zal de massa een rotzorg zijn op welke hypervisor hun applicatie draait. Maar als techneuten masaal hun applicatie op nutanix/hyperv/proxmox/kvm/virtualbox/whatever zetten, er toch wel degelijk veranderingen zijn in de markt.

En ditzelfde geldt voor Android. Als sailfish morgen besluit hun Android bridge gratis te maken en fabrikanten overgaan tot sailfish OEM installs ipv Android dan kan de markt er in een korte tijd ineens heel anders uitzien.

Kijk maar naar wat huawei in China doet nav de Amerikaanse sancties. Die zijn in no-time zelfstandig geworden.

Tel daar de playstore bruggen en de aurora playstore bij op en ineens zijn ze losgeweekt van Google.

Overigens moest ik wel lachen van je pacemaker voorbeeld ;)
Zou willen dat ik lineage en de nieuwe Android TV launcher op mijn Android TV kon flashen. (Typische rebranded Vestel meuk)

Dan maar wachten tot 23 naar Shield TV of Chromecast met Google TV geport is en zoiets scoren.
Ik zit zelf nog op Android 14 omdat mijn device uit 2018 komt, maar ik overweeg om mijn telefoon te upgraden naar Android 15. Aan de andere kant lijkt het me ook interessant om Linux, zoals Ubuntu, erop te zetten. Alleen vertrouw ik mezelf niet helemaal dat dit goed zal werken en dagelijks gebruik kan ondersteunen. Met LineageOS werkt alles nu wel lekker.


Om te kunnen reageren moet je ingelogd zijn