Inhoudsopgave:
We hebben het grootste deel van de dag besteed aan het doorgronden van de innerlijke werking van de eerste release van de Android N Developer Preview, en we hebben een paar dingen geleerd. De eerste daarvan is eenvoudig - dit is een super-bètaversie (als dat geen woord is, het moet zijn) de versie van software met bugs bovenop bugs. Velen van ons hebben het geflitst en genieten van de nieuwe smaak, maar je moet voorzichtig zijn als je elke dag de telefoon wilt proberen die je nodig hebt. Dingen zijn kapot, en sommige dingen zullen meer kapot zijn in de volgende update. Deze preview is voor ontwikkelaars om aan hun apps te werken om ze Android N-compatibel te maken, en voor mensen die graag bugs melden. Het zegt het precies op het blik.
Het tweede wat we zien is het interessantere, hoewel we nog niet helemaal zeker zijn waar het om gaat.
Grote dingen zijn misschien goed voor Android.
Android heeft een groot (en niet geheel onjuist) beeldprobleem als het gaat om het op de huidige software houden van apparaten. We kunnen er ruzie over maken, proberen het ene bedrijf meer de schuld te geven dan het andere, of onze bal inpakken en naar iMore gaan. Niets van dat helpt als je meer dan 1, 5 miljard dingen hebt die Android draaien - en weinigen van hen draaien exact dezelfde software. Uiteindelijk is het Google die de hitte moet nemen omdat hun naam op het product staat. Het is een discussie die doodgeslagen is en nog wat - en de afranselingen zullen doorgaan.
Google weet dit en doet "dingen" onder de motorkap van Android om het voor de mensen die telefoons bouwen gemakkelijker te maken om alles bij elkaar te krijgen. En deze eerste Developer Preview (er zullen er nog een aantal zijn voor de publieke release later dit jaar) laat het zien. We weten niet precies waar Google naar toe gaat en wat het heeft gepland, maar kleine wijzigingen in de bestandsstructuur en partitionering in de eerste fabrieksafbeeldingen van apparaten zijn aanwijzingen voor hoe dingen goed zouden kunnen werken. We zien meer dingen die in de leverancier- en OEM-partities worden geplaatst - dingen die kunnen (en doen) de "standaard" Android-versies overschrijven die zich in de systeempartitie bevinden wanneer de telefoon opstart. En ondersteunen niet alleen bibliotheken en kernelobjecten - er zijn volledige apps die door de leverancier worden geleverd (in dit geval die verkoper is Google) die grote invloed kunnen hebben op de werking van de telefoon en de manier waarop u ermee werkt.
Stel je een wereld voor waarin Samsung zijn visie op Android kan hebben, terwijl de diepe systeemprocessen onaangeroerd blijven.
Stel je een wereld voor waarin Samsung zijn visie op Android kan laten draaien zoals hij het leuk vindt, terwijl diepe systeemprocessen - zoals de beruchte Stagefright-bibliotheek - gescheiden en onaangeroerd zijn. Dat zou betekenen dat Samsung of Google wijzigingen in hun afzonderlijke delen van het systeem veel gemakkelijker (en veel sneller) zouden kunnen doorvoeren dan ze vandaag kunnen zonder de andere helft van het systeem te verstoren. (Met API's en bibliotheken om de kloof te overbruggen.) Alleen al door de mankracht die zich in deze situatie voordoet, zijn er meer mensen beschikbaar om de Samsung-ervaring te verbeteren zonder zich zorgen te hoeven maken over de onderliggende Android-code.
Met Android N is Google in wezen begonnen Android in twee secties te verdelen: het kernbesturingssysteem (het framework dat alles werkt) en de interface (de apps, het opstartprogramma, de meldingen en al het andere waarmee de gebruiker communiceert).
Ga nog een stap verder en overweeg een kleiner bedrijf zonder de ogenschijnlijk bodemloze bronnenpool van Samsung en bedenk hoe dit helpt. Een meer "op zichzelf staand" systeem dat op deze manier is gebouwd, is beter voor iedereen - en vooral dat betekent dat u en ik.
Laten we nog dieper gaan
Android als framework in plaats van een besturingssysteem betekent dat het eenvoudiger is om gebruikersgerichte functies te wijzigen.
Android als framework in plaats van een besturingssysteem betekent dat het eenvoudiger is om de gebruikersgerichte functies te wijzigen. Ik denk terug aan de "blokkeermodus" op recente Samsung-telefoons of Moto Display op de originele Moto X. Ze zijn zeker niet beter gemaakt met Android-updates en wat we van Google hebben om ze te vervangen, is niet zo goed als de originelen. Een manier voor een leverancier om toegang te krijgen tot de systeemprocessen met zijn eigen interface - en systeemprocessen die tussen versies hetzelfde blijven - laat Samsung bepalen hoe u meldingen onder controle houdt. Of het laat Lenovo / Moto dingen op het vergrendelscherm weergeven op de manier waarop ze het willen doen, zonder alles opnieuw te moeten ontwerpen telkens wanneer een nieuwe versie uitkomt.
Het betekent ook dat wat we vandaag zien misschien nooit de telefoon die je in handen hebt, zal bevallen.
Nexus-telefoons zijn een merk. Nexus-telefoons werken niet op onvervalste open-source Android - vrijwel niets doet dat. Google neemt de code en wijzigt deze naar wens en installeert vervolgens die versie van Android op de telefoons die het verkoopt - en dat is precies wat HTC en LG en Samsung doen. Google raakt minder van het systeem dan de meeste fabrikanten (hoewel de HTC One A9 heel dichtbij was), maar het is nog steeds niet de puur open source Android die je zelf kunt downloaden en bouwen.
Als we deze nieuwe ideeën aannemen - en vergis je niet dat ze op dit moment alleen maar ideeën zijn - en een jaar of zo vooruit denken, betekent dit dat dingen zoals nieuwe meldingsladen of donkere modi of meerdere vensters precies zijn hoe Google wil communiceren met het systeem op zijn visie van Android. Samsung of Huawei zijn vrij om hun eigen ding te doen - en dat zullen ze doen - en het komt niet overeen met het ding van Google. Maar belangrijker is dat het niet zo gemakkelijk dingen gaat breken. Het systeem laat je gewoon een kleur kiezen voor de interface. "Dark Theme" is een gebruikersinterface-idee dat iedereen kan implementeren hoe dan ook.
Het grootste voordeel zou zijn als het gaat om beveiligingsupdates. We kiezen veel voor Samsung als het gaat om maandelijkse beveiligingspatches, omdat dit het bedrijf is waar we het meest van verwachten. De grote hond zijn betekent dat je de meeste controle krijgt. Samsung heeft redenen waarom slechts enkele modellen tijdige beveiligingsupdates ontvangen en we denken dat de meeste ervan draaien rond ontwikkelingskosten of pure mankracht. Als Android meer een framework wordt dan een volledig besturingssysteem, is het gemakkelijker om dat framework sneller op meer telefoons te updaten.
Hopelijk stuurt Google het Android-schip op een manier om het grootste probleem op te lossen.
Laat Google zich zorgen maken over het patchen van Widevine of Stagefright, en Samsung kan zich zorgen maken over zijn eigen software - het ding dat het het beste kent. Samsung kan Google met recht laten vallen als het gaat om native Android-bugs. Zelfs de Evil Cabal of North American Carriers kan het beveiligingspatchproces verlaten. Iedereen wint.
We speculeren hier veel op basis van enkele relatief kleine wijzigingen in de interne werking van de Android N Developer Preview. Dat is wat we nu kunnen doen zonder broncode of officiële woorden van Google HQ. Maar we weten wel dat Google altijd een reden heeft voor de wijzigingen die het aanbrengt (hoewel we het vaak niet eens zijn), en deze kleine veranderingen in de manier waarop de leveranciers- en OEM-secties van Android werken, waren geen ongelukken.
We verwachten veel meer te leren over Google I / O, en hopelijk stuurt Google het Android-schip op een manier om het grootste probleem op te lossen.
