Google-ingenieurs hebben onlangs een AMA op Reddit gedaan. De AMA ging over de Android Q-bèta. Hier volgt een samenvatting van wat we uit hun antwoorden hebben geleerd.
Vorig jaar organiseerde het Android-team van Google een Ask Me Anything (AMA) op de /r/AndroidDev-subreddit van Reddit om vragen te beantwoorden over de Preview voor Android P-ontwikkelaars. Dit jaar beantwoordde het technische team dat aan de Android Q-bèta werkte vragen op Reddit. De AMA begon op 1 augustus om 12:00 uur PST en eindigde ongeveer anderhalf uur later. Bij de AMA waren 33 Google-ingenieurs betrokken, die in de korte tijd dat de AMA duurde een heleboel vragen beantwoordden. Hier is onze samenvatting van alle nieuwe informatie die we hebben geleerd.
Android Q AMA: Alles wat we van Google hebben geleerd
Deelnemers van het Android Q-bètateam
- Adam Cohen: TLM op Android Launcher / Systeem-UI
- Adam Powell: TLM op UI-toolkit/framework; views, levenscyclus, fragmenten, ondersteuningslibs
- Alan Viverette: TLM, Jetpack/AndroidX
- Allen Huang: PM voor UI, launcher, meldingen, zoekintegraties en meer!
- Andrew Sappirstein: TLM op Android-instellingen
- Brahim Elbouchikhi: PM Director voor Android Machine Learning en Camera (NN API, ML Kit, CameraX, Camera Platform)
- Tsjaad Brubaker: Software-ingenieur, Android-platformbeveiliging
- Charmaine D'Silva: PM voor privacy
- Chet Haase: Android-hoofdadvocaat, ontwikkelaarsrelaties
- Diana Wong: PM, app-compatibiliteit, niet-SDK API-gebruik, ART, NDK
- Dianne Hackborn: Manager van het Android-frameworkteam (bronnen, vensterbeheer, activiteitenmanager, meerdere gebruikers, afdrukken, toegankelijkheid, enz.)
- E.K. Chung: Directeur van UX
- Ian-meer: Software Engineer, Jetpack (fragmenten, navigatie, architectuurcomponenten)
- Iljan Malchev: Hoofdsoftware-ingenieur, Project Mainline
- Jacob Lehrbaum: Directeur ontwikkelaarsrelaties voor Android
- Jake Wharton: Software-ingenieur, Jetpack
- Jamal Eason: PM, Androidstudio
- Jeff Bailey: TLM, Android Open Source-project (AOSP)
- Jeff Sharkey: Software-ingenieur, Android Framework
- Jeffrey van Gogh: Android Studio, compilers
- Jen Chai: PM, locatie en context, authenticatie, automatisch aanvullen, niet-SDK API-gebruik, ART
- Karen Ng: Groeps-PM voor Android Developer Tools, Android Studio, Android Tookit en Jetpack
- Paul Bankhead: Directeur productbeheer, Google Play
- Rohan Sjah: Productmanager, Android-systeemgebruikersinterface
- Romain Guy: Manager van het Android Toolkit/Jetpack-team
- Sagar Kamdar: Directeur Productmanagement, Android
- Za K: Directeur Techniek, Android-connectiviteit
- Selim Cinek: Software-ingenieur, gebruikersinterface van Android-systeem
- Stephanie Saad Cuthbertson: Senior directeur productmanagement, Android
- Soemir Kataria: Software-ingenieur, Jetpack (WorkManager)
- Travis McCoy: PM, Android-platform
- Trystan Upstill: Distinguished Engineer, hoofd voor Android-systeeminterface en intelligentie
- Vinit Modi: PM, Android-camera
Lees verder
OEM's kunnen apps niet langer beëindigen wanneer de gebruiker ze in recente versies wegveegt
Als je ooit een smartphone van een Chinees merk hebt gebruikt, heb je waarschijnlijk wel eens te maken gehad met vervelende ‘batterijoptimalisatie’-functies die dood al je favoriete apps op de achtergrond. Dit gedrag is niet alleen vervelend voor gebruikers die verwachten dat bepaalde apps om welke reden dan ook op de achtergrond blijven draaien, maar het is ook vervelend voor ontwikkelaars die te maken krijgen met slechte recensies van gebruikers die niet begrijpen dat het niet aan de app ligt schuld. Terwijl Google dat wel is nog steeds deze kwestie niet volledig aan de orde stellen (ze wuifden het probleem met de hand weg door te stellen dat dit gedrag wel zo is waarschijnlijk al in strijd met de vereisten van het Android Compatibility Definition Document). is actie ondernemen tegen een ‘batterijbesparende’ gedragsverandering die door sommige OEM’s wordt toegepast.
"Om deze situatie te helpen hebben we een CTS-test toegevoegd aan Android Q om ervoor te zorgen dat een app niet wordt gedood als deze uit Recents wordt geveegd."
Android R brengt mogelijk meer wijzigingen in schermafbeeldingen met zich mee dan we hadden verwacht
Google is van plan om toe te voegen schermafbeeldingen scrollen in Android R, maar tegelijkertijd de Android-team is "We bekijken goed hoe [ze] de hele scherm-[X]-ervaring voor R kunnen verbeteren." Zo mogen wij zie andere verbeteringen aan het gedrag van screenshot (EN screencast) in de volgende grote Android-versie.
Verduidelijking van de nieuwe bureaubladmodus van Android Q
De eerste publieke bètaversie van Android Q bracht een verborgen desktopmodusinterface naar de AOSP en Pixel Launcher. Hoewel Google kort ingegaan op de functie tijdens een Google I/O-sessie hebben we nog nooit rechtstreeks van Google gehoord hoe de nieuwe functie in het Android-ecosysteem past. Googlen verduidelijkt nu:
"In Q AOSP is 'desktopmodus' een ontwikkelaarsoptie gericht op applicatie-ontwikkelaars. Hiermee kunnen ze hun apps testen in omgevingen met meerdere schermen en vrije vormvensters. Voorheen was er geen handige manier om app-gedrag te testen op een secundair scherm en met vrij aanpasbare vensters op stock-Android. Deze functie is niet op zichzelf ontwikkeld en is momenteel niet bedoeld voor gewone gebruikers. Niettemin is het de basis van het Android-platform voor OEM's om te innoveren en geweldige producten te maken."
We kunnen dus verwachten dat OEM's zullen voortbouwen op de native desktopmodus van Android Q. Bijvoorbeeld de OnePlus 7 Pro ondersteunt weergave via HDMI, dus dat kan OxygenOS 10 gebaseerd op Android Q zal in de toekomst zijn eigen desktopmodusinterface hebben. We hopen ook dat Google voortbouwt op de functie voor de komende tijd Pixel4.
Op tijd gebaseerde donkere modus
Android Q brengt eindelijk een veelgevraagde feature: systeembrede donkere modus. Momenteel kan de donkere modus handmatig worden ingeschakeld in Instellingen of via een tegel Snelle instellingen, of deze kan automatisch worden geactiveerd wanneer Batterijbesparing is ingeschakeld. Vóór Android Q was er een optie om de donkere modus in te schakelen gebaseerd op het tijdstip van de dag, maar die optie is verouderd. Volgens Chris Banes:
"Er zijn een paar redenen waarom dit verouderd is (niet verwijderd) in AppCompat v1.1.0: het vereist dat apps locatierechten nauwkeurig zijn, en zelfs met een geldige locatie kunnen de berekeningen van de zonsopgang-/zonsondergangstijd kloppen buggy."
Wanneer hem naar deze bugs wordt gevraagd, zegt de heer Banes dat “het berekenen van zonsopgang/zonsondergangen notoir moeilijk is, vooral voor locaties dichtbij noord-/zuidpool." Een gebruiker laat zien dat Nachtlicht, beschikbaar sinds Android 7.1 Nougat, automatisch kan worden geschakeld op basis van zonsondergang/zonsopgang schema's. De heer Banes stelt vervolgens dat Night Light gebruik maakt van CalendarAstronomer van ICU4J, gebruikt het een "groot stuk code waarvan we niet willen dat AppCompat afhankelijk is." Het team doet dat echter wel staat dat deze functie "iets is waar [ze] naar zullen kijken."
Verplichte Camera2 API/Camera HAL3-ondersteuning voor Android Q-startapparaten
Google heeft de Camera2 API geïntroduceerd om beter te definiëren hoe apps kunnen communiceren met de afzonderlijke camera's die op uw smartphone zijn aangesloten. Terwijl Google moedigt aan smartphoneleveranciers om ‘al hun fysieke camera’s aan ontwikkelaars bloot te stellen’, kiezen veel leveranciers ervoor dit niet te doen, ook al is ‘de API zelf dat niet’ waardoor ze vandaag de dag niet meer voorkomen." Dit betekent dat veel camera-apps van derden de secundaire of tertiaire cameramodules op moderne apparaten niet kunnen gebruiken smartphones. Er wordt echter vooruitgang geboekt nu Android Q is verbeterd LOGISCHE_MULTI_CAMERA, een API die ontwikkelaars betere toegang geeft tot alle camera's op een apparaat en die OEM's controle geeft over het energieverbruik en het beheer van meerdere camerastatussen.
Bovendien zegt Google dat ze eisen hebben toegevoegd aan alle apparaten die met Android Q worden gelanceerd, om Camera2 API/Camera HAL3 te ondersteunen. Volgens Vinit Modi:
"Vanaf Android P zijn nieuwe apparaten met 1 GB of meer RAM vereist om standaard HALv3/camera2 te kunnen gebruiken. Vanaf Android Q moeten alle nieuwe apparaten standaard HALv3/camera2 ondersteunen. Helaas zijn upgrades van HALv1 naar HALv3 vrij complex via de ether en kunnen onverwachte gevolgen hebben. Daarom moesten we de reikwijdte beperken tot nieuwe apparaten."
Interessant is dat Modi's verklaring over normale RAM Android P-lanceerapparaten is tegenspreekt wat Google ons eerder heeft verteld en wat er online op de Image Test Suite-pagina is gepubliceerd.
Dynamisch app-thema met Jetpack Compose
Sony's OMS-themaframework is een flink aantal releases geleden aan AOSP toegevoegd, maar dat is slechts het geval bedoeld voor OEM's om op voort te bouwen. Dat weten wij al Google is tegen het gebruik van runtime resource-overlays door gebruikers voor thema-apps, maar voor ontwikkelaars is het bedrijf dat wel hopend dat is het Jetpack Compose-gebruikersinterface raamwerk zal "interessante benaderingen van dynamische thema's" naar voren brengen.
Vulkan-backend voor Skia om de gebruikersinterface weer te geven
Afgelopen jaar, we zagen een discussie onder Google-ingenieurs die praten over hun plannen om het Android-framework de Vulkan grafische API te laten gebruiken voor UI-rendering. Hoewel het nu mogelijk is om de hardwareversnelde Vulkan-backend in te schakelen zonder je telefoon crashen, hebben we geen concrete plannen van Google gehoord over wanneer ze van plan zijn deze uit te rollen veranderingen. Deze AMA geeft geen antwoord op die vraag, maar we hebben in ieder geval de bevestiging dat er nog aan wordt gewerkt. Volgens Romain Guy:
"Het team heeft gewerkt aan een Vulkan-backend voor Skia, de 2D-renderer die door Android wordt gebruikt, maar deze is momenteel niet standaard ingeschakeld. De gebruikersinterface en Canvas lopen nog steeds via OpenGL ES."
De gebarenbalk van Android Q dynamischer maken
Sommigen op XDA denken dat nog steeds De nieuwe gebaren van Android zijn een puinhoop, maar persoonlijk vind ik ze prima. Als je echter een beetje met de nieuwe gebaren in Android Q speelt, zul je merken dat de gebarenbalk niet met je vinger beweegt. Het blijft ook hangen op schermen waar het niet nodig is, zoals het startscherm of het overzicht van recente apps. Allen Huang zegt dat ze het er ‘helemaal mee eens zijn dat er mogelijkheden zijn’ om de ‘navigatielijn minder statisch te maken’. Hij zegt verder dat "dit iets is waar we aan werken, maar ook aan het balanceren, zodat het niet afleidt verschijnen/verdwijnen."
Verbeteringen aan het Storage Access Framework
De vele veranderingen in Android Q hebben de weergave aanzienlijk verbeterd veiligheid en privacy van het platform. Eén zo'n verandering, genaamd "Scoped Storage", beperkt de toegang van apps tot bestanden op de externe opslag op een zinvolle manier; muziek-apps hoeven bijvoorbeeld uw galerij niet te zien. Bestandsbeheer-apps die in Android Q draaien, moeten een API gebruiken, het Storage Access Framework genaamd, om normaal te kunnen blijven werken, maar sommige ontwikkelaars beschouwen deze API als inferieur naar wat voorheen beschikbaar was. Jeff Sharkey van Google zegt het team heeft enkele van de klachten van deze ontwikkelaars aangepakt:
"We hebben enkele SAF-prestatieverbeteringen aangebracht in de nieuwste Android Q Beta-releases; Kunt u uw benchmarks vergelijken met de nieuwste bèta? Zorg er ook voor dat u een ContentProviderClient gebruikt wanneer u bulkbewerkingen uitvoert."
Project Treble verbeterde de adoptie van Android Pie ten opzichte van Android Oreo
We hebben al gezien hoe Project Treble, een ingrijpende herinrichting van het Android-framework op laag niveau, de adoptie van nieuwere Android OS-versies heeft verbeterd. Google crediteert Treble achter de hele reeks smartphoneleveranciers die zich bij de Android P-bèta vorig jaar en Android Q-bèta dit jaar. Iliyan Malchev, de leiding van Project Treble en Hoofdlijn ingenieur, zegt dat de adoptie van Android Pie eind 2018 "drie keer" zo groot was als die van Android Oreo.
In hetzelfde commentaar plaagt Dick Dougherty dat er meer bruikbare statistieken in de maak zijn voor de distributiegrafiek van de Android-versie. De grafiek was laatst bijgewerkt in mei, maar de gegevens zijn nuttiger voor journalisten dan voor app-ontwikkelaars.
Schermopname is nog steeds een WIP
Vroege Android Q-bèta's voegden een functievlag toe voor een eenvoudige schermrecorder, maar het platform zelf heeft de bruikbaarheid van schermopname aanzienlijk verbeterd door waardoor apps de audio van andere apps kunnen vastleggen. Stephanie Saad Cuthbertson zei dat het team aan het nadenken was "hoe we het gisteren nog beter konden doen op het gebied van schermopnamen." Andere smartphonemerken zoals OnePlus, ASUS, Huawei en Samsung hebben robuuste schermrecorders die de interne audio kunnen opnemen, dus Google zal hier een inhaalslag maken.
Donker thema Alle dingen!
Voor het geval je het gemist hebt: Google voegt de donkere modus toe aan de meeste van hun apps. Stephanie Saad Cuthbertson zegt te verwachten dat alle "grote apps" een donker thema zullen ondersteunen "bij de officiële [Android Q] release." Zelfs Google Chrome, die momenteel dwingt het opnieuw laden van de pagina wanneer het systeembrede donkere thema is ingeschakeld, wordt bijgewerkt om niet langer te vernieuwen wanneer het thema is ingeschakeld veranderd.
Ja, Launchers van derden zullen werken met gebaren (uiteindelijk)
De gebaren van Android zijn nogal kapot wanneer u een opstartprogramma van derden gebruikt. Dat komt omdat de gebruikersinterface van recente apps zich in de Stock Launcher-app bevindt, en Google nog niet een manier uitgewerkt om dezelfde naadloze overgangen te krijgen die we zien bij het gebruik van gebaren met de standaard Pixel Lanceerder. Adam Cohen bevestigt De plannen van Google om deze problemen "zo snel mogelijk na de release" aan te pakken. Dat zegt hij verder de incompatibiliteit "zal worden aangepakt in de post-Q-update, en backported voor nieuwe apparaten die ermee worden gelanceerd Q."
Dynamische/logische partities zijn er niet om aangepaste ROM's te vernietigen
Om te ondersteunen Dynamische systeemupdates in Android Q maken bepaalde apparaten zoals de Google Pixel 3 en Pixel 3 XL gebruik van logische partities. Het formaat van deze partities kan dynamisch worden aangepast. Deze verandering heeft bewezen een uitdaging om root-toegang werkend te krijgen, en sommige ontwikkelaars zijn bezorgd dat aangepaste ROM's het doelwit zijn. Iliyan Malchev verzekert ons dat het niet de bedoeling is om aangepaste ROM's te beperken. Als hij legt uit:
"Dynamische partities zijn niet bedoeld om te beperken wat je kunt doen met aangepaste ROM's. Ze zijn gewoon een oplossing voor het probleem van vaste partitiegroottes en het ontbreken van een veilige manier om apparaten opnieuw te partitioneren OTA. Voorafgaand aan dynamische partities, als een OEM een fout heeft gemaakt bij het dimensioneren van b.v. de systeempartitie en vervolgens zij zou door die keuze worden beperkt, waardoor het praktisch onmogelijk wordt om een apparaat na een bepaalde tijd te upgraden punt. Sommige OEM's herpartitioneren hun apparaten in de praktijk wel op OTA, maar dit wordt a) niet officieel ondersteund in Android, en b) het wijzigen van de partitietabel wordt als behoorlijk riskant beschouwd. Dynamische partities zijn bedoeld om het probleem te verlichten door een niveau van indirectie te introduceren tussen de fysieke partitietabel en het besturingssysteem. Hierdoor kunnen we de partitiegroottes op OTA veilig aanpassen. Wat aangepaste ROM's betreft, zou u in het geheel niet meer beperkt moeten worden dan nu het geval is met wat u kunt doen. Het ondersteunen van aangepaste ROM's is en blijft iets dat elke individuele OEM besluit in te schakelen."
Project Mainline - ART-module en ondersteuningslengte
Mainline is een nieuw initiatief van Google dat tot doel heeft bepaalde bibliotheken en pakketten te standaardiseren, zodat ze onafhankelijk van platformupdates kunnen worden bijgewerkt. Sommigen hebben zich afgevraagd waarom de Android Runtime (ART) nog geen Mainline-module is, maar mij werd bij Google I/O verteld dat de complexiteit die gepaard gaat met het modulariseren van ART weerhield hen ervan het op te nemen als een van de oorspronkelijke APEX-pakketten. Als uitgelegd door zowel Iliyan Malchev als Diana Wong:
"Het maken van updates voor de Runtime (vooral prestatie- en GC-fixes en kernbibliotheken) is zeker iets dat we onderzoeken in de context van de hoofdlijn. We zien veel voordelen als we deze updates consistent kunnen maken op alle apparaten en in meerdere releases met Mainline. Het is ook een enorme technische uitdaging als we nadenken over hoe we dit het beste kunnen doen voor ontwikkelaars, en waarschijnlijk een inspanning van meerdere jaren. Het is niet iets wat Mainline momenteel kan doen, maar zeker iets waar we over nadenken.”
Als je de AOSP Gerrit volgt, zie je dat Google dat toch is geweest hard aan het werk het maken van een Runtime-APEX. Momenteel lijken ze dat wel te zijn het splitsen van Bionic en ART/libcore in afzonderlijke APEX-modules.
Wat betreft het voordeel van Project Mainline vroeg een gebruiker naar de lengte van Mainline-updates. Als reactie daarop Iliyan Malchev zegt dat "dit een beleidsvraag is die we nog aan het evalueren zijn, maar we willen Mainline-modules op een apparaat zo lang mogelijk updaten." XDA erkende ontwikkelaar luca020400 informeerde of er vooraf gebouwde Mainline-modules zullen worden geleverd, zodat ontwikkelaars van aangepaste ROM-updates updates kunnen samenvoegen, en als reactie hierop zei Jeff Bailey herhaalt dat "de modules die zich afsplitsen van AOSP bronreleases zullen hebben die overeenkomen met elke modulerelease." We kunnen al de voortgang zien van nieuwe APEX-modules in AOSP, zoals één voor de Neurale netwerken-API.
CameraX ontmoet ML Kit
Op I/O dit jaar introduceerde Google de CameraX Jetpack-bibliotheek. Deze bibliotheek is ontworpen om het voor ontwikkelaars gemakkelijker te maken de Camera2 API van Android te ondersteunen, terwijl de compatibiliteit tot aan Android Lollipop behouden blijft. Vinit Modi plaagt waarmee het bedrijf werkt aan de integratie van CameraX ML-kit, de machine learning Firebase SDK van Google, zodat ontwikkelaars afbeeldingsframes in ML Kit kunnen invoeren voor analyse.
CameraX-leveranciersextensies en releasedatum
De ontwikkelaar van een camera-app betreurt het feit dat geavanceerde camerafuncties zoals Night Sight van Google Pixel niet toegankelijk zijn voor camera-apps van derden. Dit zou oplosbaar moeten zijn met CameraX-leveranciersextensies, waartoe Jeff Sharkey van Google behoort zegt dat "alle Pixel-apparaten zijn geoptimaliseerd voor CameraX Core." Hij plaagt dat “het Extensies-aspect zal worden ondersteund op nieuwe en aankomende apparaten.” Bovendien is Google dat "We werken samen met verschillende fabrikanten om de mogelijkheden van hun apparaten beschikbaar te maken voor zowel ontwikkelaars als gebruikers." Hoewel dit niet direct bevestigd is, is het mogelijk dat we kenmerken zien leuk vinden Nachtzicht op de Google Pixel4 beschikbaar worden voor camera-apps van derden die de CameraX-bibliotheek gebruiken.
De heer Sharkey stelt dat Google mikt op een bètaversie voor het einde van dit jaar.
Verbeteringen in geheugenbeheer in Android Q
De Pixel 3 werd bekritiseerd omdat hij deze had Talrijke problemen na de lancering, maar Google heeft veel gedaan om deze problemen via talloze oplossingen aan te pakken updates na de lancering. Geheugenbeheer was een van de zwakste aspecten van de Pixel 3, maar in de Android Q-release zouden de zaken iets beter moeten zijn. Volgens Selim Cinek:
"In SystemUI hadden we bijvoorbeeld verschillende grote refactoring-inspanningen in Q om het RAM-gebruik van meldingen en andere oppervlakken te verminderen."
Zullen we eindelijk draadloze ADB krijgen?
Als u uw telefoon draadloos wilt debuggen, moet u uw apparaat rooten. Jamal Eason van het Android Studio-team zegt dat ze momenteel de haalbaarheid van deze functie onderzoeken.
Test Google nog steeds op tablets?
XDA erkende ontwikkelaar Luk1337 gevraagd of Google AOSP UX nog steeds test op tablets. Het is een terechte vraag, gezien de gebrek aan goede Android-tablets en de aanwezige bugs in huidige releases. Allen Huang zegt dat Google nog steeds "elk jaar tests en reparaties uitvoert" en dat het bedrijf nauw samenwerkt met partners "om een goede Android-tabletervaring te garanderen."
Er zijn veel meer berichten in de volledige thread op Reddit. Wat ik hier heb behandeld, is een samenvatting van alle nieuwe informatie die we hebben geleerd, maar van verschillende Googlers (vooral Dianne Hackborn) gaan in op hun redenering achter het schrappen van de X-functie of het niet implementeren van Y toestemming. Ik raad je aan de volledige AMA te lezen als je de besluitvorming van het Android-team wat beter wilt begrijpen.
Lees de volledige AMA op /r/AndroidDev