Belangrijkste Android 11-functies voor ontwikkelaars uitgelegd door Chet Haase

CHET HAASE Hallo, welkom bij What's New in Android. Ik ben Chet Haase van het Android Developer Relations-team. De vraag is: wat is er nieuw in Android? Om te beginnen is de locatie nieuw. Normaal gesproken krijg ik dit één keer per jaar. Ik ben bij Google I.O. Ik heb een paar medesprekers. Ik mis mijn medesprekers hier. Ik mis ook de locatie, dat prachtige podium. Maar de lezing is in wezen hetzelfde. Ik ga het vandaag in essentie over drie dingen hebben. Ten eerste: wat is er nieuw in de release? We gaan het hebben over functies in Android 11 die de moeite waard zijn om te weten voor ontwikkelaars. We gaan het ook hebben over dingen die we doen op het gebied van niet-platformgerelateerde zaken, zoals de tools en de ontbundelde bibliotheken. En bijna het belangrijkste: ik ga het hebben over een aantal andere bronnen die u kunt raadplegen voor meer informatie over alles waar ik het over heb, en nog veel meer. Laten we beginnen. Laten we beginnen met de gebruikersinterface, omdat ik dit gebied erg leuk vind. Ik heb hier veel mee gewerkt. Het is een interessant gebied.

Het gaat om de visuele aspecten, toch? Er zijn een paar interessante dingen gaande in de gebruikersinterface. Een daarvan is vensterinsets. Dit is een functie die al jaren in Android, in het platform, aanwezig is om informatie te krijgen over andere dingen op het scherm die van invloed zijn op de insets waar uw inhoud moet worden geplaatst om in dezelfde ruimte te kunnen bestaan, toch? Welnu, het toetsenbord wordt geanimeerd, waardoor de schermruimte kleiner wordt. Je app moet daarop reageren. Maar nu bieden we meer informatie. Traditioneel krijg je alleen wat geometrische informatie over insets, zonder echt te weten wat, hoe, wie en waarom. Nu hebben we de meeste methoden in de window insets-klasse afgeschaft en in plaats daarvan enkele toegevoegd die typespecifiek zijn, met name windowtypespecifiek. Nu kun je zeggen: waar is dat toetsenbord? Of waar is de navigatie- of statusbalk? Of wat zijn de insets voor dit specifieke venster? Heel interessant, heel goed mogelijk om op deze manier rijkere ervaringen te creëren. Ik kom daar nog op terug.

Zo werkt het. Je implementeert in feite een listener en binnen die listener krijg je de insets-informatie en met die insets kun je query's uitvoeren. Hé, is dat toetsenbord zichtbaar? Een verbluffende nieuwe mogelijkheid die je nog nooit eerder had: je kunt achterhalen of het toetsenbord zichtbaar is, of je kunt de specifieke insets voor het toetsenbord of een van de andere venstertypen ophalen die worden afgehandeld in de insets-API. Waarom maken we dat mogelijk? Nou, een van de redenen, behalve dat het nodig was, is dat IME-animaties veruit mijn favoriete functie zijn in de Android 11-release. De mogelijkheid om de inhoud van je applicatie daadwerkelijk te synchroniseren met de animatie van het toetsenbord. Dus als het toetsenbord tevoorschijn komt, zou het toch fijn zijn als je wist wanneer het tevoorschijn kwam, hoe snel het tevoorschijn kwam, en je applicatie daar soepel op kon inspelen. Dat kan nu op een aantal verschillende manieren. Je kunt luisteren naar veranderingen in het toetsenbord, zodat je tijdens de animatie kunt zien waar het zich bevindt en hoe groot het is. Al die insets-informatie wordt frame voor frame weergegeven en je kunt ermee synchroniseren of zelfs de animatie rechtstreeks aansturen. Als je naar het volgende voorbeeld aan de linkerkant kijkt, zie je dat we op een veld klikken, waardoor het toetsenbord op zijn plaats springt. Normaal gesproken zou het op zijn plaats klikken en zou de applicatie zich daarop aanpassen, maar je kunt zien dat het soepel met het toetsenbord meebeweegt omdat het die animatiegebeurtenissen onderweg ontvangt. Aan de rechterkant scrollen we fysiek door de inhoud in de applicatie, we vegen dat ding omhoog. En terwijl we dat doen, veegt het toetsenbord mee omhoog, omdat we de animatie direct en handmatig aansturen in de applicatiecode. Dit is hoe je dat doet.

Als u wilt luisteren naar animatiewijzigingen en wilt reageren op de automatische animatie van het toetsenbord, kunt u een callback-listener instellen en vervolgens die informatie ophalen naarmate elke stap van de animatie vordert en het juiste doen met uw inhoud. Als u in plaats daarvan de animatie rechtstreeks wilt aansturen, kunt u deze controlWindowInsets-methode aanroepen en deze aansturen. U stuurt deze dus aan voor een bepaald venster. Hier sturen we deze aan voor de IME. Voor het toetsenbord geven we deze een negatieve duur, wat betekent dat deze voor altijd blijft draaien, omdat we deze in principe stap voor stap aansturen op basis van waar dat gebaar zich op het scherm bevindt. U kunt deze bewegingsinterpolatie geven. U kunt annulering afhandelen als dat nodig is, en u kunt ook levenscyclusgebeurtenissen voor de animatie krijgen. Dus volledige controle over de animatie-ervaring en een volledig synchrone en naadloze overgang voor de gebruiker. Veel beter. Er zijn een paar verschillende plaatsen waar u meer informatie hierover kunt vinden. Een daarvan is het voorbeeld waarvan we screenshots hebben gezien en dat daar is gepost. Ga dus naar die URL om dat te bekijken. De andere is de recente ADB-podcast, aflevering 138.

We hebben gesproken met ingenieurs van het window manager-team. Zij hebben ons uitgelegd hoe we die API's kunnen gebruiken om effectieve animaties te krijgen en hoe alles onder de motorkap werkt, wat altijd interessant is. Gesprekken gaan over mensen, of mensen gaan over gesprekken. Veel van de veranderingen in de systeem-UI van Android 11 hebben te maken met het concept van mensen, de mensen in ons leven, en manieren waarop we gemakkelijker in contact kunnen blijven met die mensen. Een van die manieren is via gesprekken. In uw applicatie kunt u informatie plaatsen via het reeds bestaande meldingssysteem, zodat we deze informatie kunnen onderbrengen op een aparte plek in de gebruikersinterface die speciaal is bedoeld voor gesprekken. Dit heeft dus de hoogste prioriteit. De kans is groot dat u meer om mensen geeft dan om bijvoorbeeld een update van een app, toch? Waarom zou je die dan niet op een aparte plek zetten en mensen vervolgens de mogelijkheid geven om de informatie over elk van die gesprekken daadwerkelijk te wijzigen? Laten we zeggen dat het laatste gesprek dat met de schoolbesturen was. Misschien vind ik de informatie daar wel heel belangrijk. Dan wil ik je meer informatie geven over hoe het systeem mij op de hoogte moet stellen. En ik wil ook de prioriteit wijzigen. Dit is echt belangrijk.

Laten we dat dus naar de wachtrij met de hoogste prioriteit verplaatsen. Hierdoor verandert de volgorde in de categorie 'gesprekken' voor de melding. Om gesprekken te creëren, gaan we het bestaande meldingsmechanisme gebruiken met iets meer informatie. We maken een persoonsobject en we maken een snelkoppeling met informatie. Dit moet langdurig zijn, omdat de gebruiker terug moet kunnen keren naar dat gesprek, zelfs als de applicatie niet meer actief is. Vervolgens gaan we een dynamische snelkoppeling met al die informatie pushen. week. We gaan de berichtstijl gebruiken en een melding maken en pushen zoals we dat normaal ook zouden doen, maar dan met iets meer informatie. Oké, iets anders dat ook is ingeschakeld en hier nauw mee verband houdt, zijn bubbels. Linksboven in de schermafbeelding zie je een bubbel met informatie. Als je op die bubbel tikt, verschijnt er een soort mini-activiteit, zodat je direct in het gesprek terechtkomt dat eerder in de applicatie plaatsvond. Maar het gebeurt eigenlijk in de UI bovenop al het andere. Het is dus een heel gemakkelijke manier voor gebruikers om toegang te krijgen tot deze informatie over mensen, waar ze zich ook bevinden in de telefoon, in plaats van te moeten navigeren en klikken om terug te keren naar dat gesprek in een diepe link in je applicatie. Bubbels waren dus eigenlijk al ingeschakeld.

Ze waren aanwezig in Android 10, maar waren ingeschakeld als een ontwikkelaarsoptie. We werkten dus aan een Android 10. Het is niet helemaal gelukt. Dus hebben we het in de ontwikkelaarsopties gezet, zodat ontwikkelaars ermee konden gaan spelen. Maar in Android 11 is het ingeschakeld als een volledig uitgebrachte functie. Dus maak er gebruik van. Gebruik het vooral in plaats van het systeemwaarschuwingsvenster. Dat was voorheen de voorkeursmethode voor applicaties om dit soort UI te doen. In principe pop je een transparant venster bovenop de inhoud die op het scherm staat. En dan vul je dat met UI zoals deze bubbelobjecten. Gebruik echter geen systeemwaarschuwingsvenster. Gebruik de nieuwe Bubbles API, want je plaatst toch al meldingen met dit soort dingen, vooral als je wilt beginnen met de integratie met de gesprekken. Mogelijkheden van de systeem-UI, dus nu voeg je gewoon een beetje meer metadata toe om het de bubble-informatie te geven die het nodig heeft. De gebruikers kiezen ervoor om de bubble-ervaring te gebruiken als ze dat willen, en dan bied je een activiteit aan, deze mini-activiteit om vanuit de bubble naar toe te gaan.

De code ziet er dus als volgt uit: je maakt deze aanpasbare activiteit, omdat het weer een soort mini-activiteit bovenop de gebruikersinterface moet zijn, en vervolgens maak je de intent voor de activiteit die je voor je bubble hebt. Je vult die met snelkoppelingsinformatie, die je misschien al hebt gemaakt omdat je dit voor gesprekken doet. Je vult die met bubble-metadata, en vervolgens maak je een pushmelding met al die metadata, en je bent klaar. Bekijk de video, de lezing getiteld What's New in System UI voor meer details over al deze zaken. Bekijk het voorbeeld getiteld Bubbles, Colin en de Android-voorbeelden. Bekijk ook de ADB-podcastaflevering die op het moment dat ik dit opneem nog niet is gepost. We hebben een gesprek gehad met het Bubbles-team, en dat was voordat ik dit opnam, maar het is nog niet gepost. Ik denk dat het aflevering 140 wordt. Ik denk dat het Bubbles gaat heten. Ik kan het mis hebben, maar het zal iets in die trant zijn. Bekijk ze allemaal eens. En laten we het nu eens hebben over privacy. Ik weet niet eens zo goed wat ik hierover moet zeggen, maar laten we het er toch maar eens over hebben. We hebben in de laatste paar releases veel veranderingen doorgevoerd op het gebied van privacy, omdat het steeds duidelijker wordt dat het steeds belangrijker wordt dat de gegevens van gebruikers worden beschermd en dat zij begrijpen wat er met die gegevens gebeurt.

Sommige van de dingen die we in deze release hebben gedaan, hebben zowel betrekking op het beschermen van gebruikersgegevens als op het vergemakkelijken van het omgaan met deze veranderingen voor ontwikkelaars. Een van die gebieden is het controleren van gegevenstoegang. Als je een individuele ontwikkelaar bent en aan je eigen applicatie werkt, heb je alle code zelf geschreven, ken je deze door en door en heb je misschien niet het probleem dat je niet zeker weet hoe er toegang wordt verkregen tot persoonlijke gegevens. Dat is geen probleem voor u. Maar stel u nu eens voor dat u deel uitmaakt van een heel groot team, met heel veel ontwikkelaars, dat al jarenlang aan de code werkt, en... U ziet dat de gebruiker om toestemming wordt gevraagd voor een functie, terwijl u niet eens begrijpt waarom we die toestemming nodig hebben. Of misschien haalt de applicatie een externe bibliotheek binnen die om extra toestemmingen vraagt die volgens u niet nodig zijn. En het kan moeilijk zijn om dat op te sporen in een heel grote broncode, vooral als er externe bibliotheken worden gebruikt. Daarom hebben we een API gemaakt om specifiek met deze situatie om te gaan, van de complexiteit van deze enorme applicatie, wat er waar gebeurt, tot callbacks die je de informatie geven die je nodig hebt. Je registreert met name een callback zoals deze, en vervolgens krijg je informatie wanneer deze informatie wordt opgevraagd, waarna je kunt opsporen waar dat in de code gebeurt en daar het juiste aan kunt doen. In Android 10 hadden we dus een nieuw concept van machtigingen die konden worden verleend wanneer de applicatie op de voorgrond stond of voor altijd, zelfs wanneer deze op de achtergrond stond. We hebben die mogelijkheid uitgebreid met het idee van eenmalige machtigingen in Android 11. Dit is het concept dat... Misschien vindt de gebruiker het prima dat die applicatie op dit moment toegang heeft tot je locatie, maar als deze op de achtergrond draait, is dat niet nodig. Op dit moment begrijp ik waarom je het nu nodig hebt, maar dit is genoeg, toch? Dus we hebben deze eenmalige toestemming. Dus in principe is die toestemming prima wanneer de applicatie in de huidige sessie wordt gebruikt, maar daarna wordt de toestemming geweigerd en moet deze de volgende keer opnieuw worden aangevraagd. De vervolgvraag van alle ontwikkelaars is dan: oké, wat moet ik nu doen om hiermee om te gaan? Het antwoord is hopelijk niets. Als je toch al een best practice voor toestemmingen gebruikt, ben je terechtgekomen in deze nieuwe wereld waarin de gebruiker je op elk moment toestemming kan weigeren. Ze kunnen naar een instellingenvenster gaan en de toestemming die ze je eerder hebben gegeven, daadwerkelijk uitschakelen. Uw applicatie moet met die realiteit omgaan, toch? Als ze daarmee kan omgaan, kan ze ook hiermee omgaan. Het betekent gewoon dat de gebruiker toestemming gaat verlenen en dat het systeem die toestemming weer intrekt wanneer u niet langer op de voorgrond staat. Hopelijk hoeft u hier dus niets te doen, maar u moet zich wel bewust zijn van de situatie. De achtergrondlocatie wordt iets restrictiever. Dit is een soort voortdurende trend in de laatste paar releases. Voorheen kon je tegelijkertijd de voorgrond- en achtergrondlocatie opvragen. Nu zijn dat aparte bewerkingen. In plaats daarvan kun je de voorgrondtoestemming opvragen en als die wordt verleend, kun je een aparte stap nemen en om achtergrondtoestemming vragen. Daarbij wordt de gebruiker naar het instellingenvenster geleid. Deze toestemming wordt niet in de applicatie zelf verleend. In plaats daarvan wordt de gebruiker naar de instellingen geleid. Ook hier draait het weer om transparantie en om de gebruiker te laten weten welke gegevens hij deelt en hoe hij die deelt, en hem de mogelijkheid te bieden om die gegevens niet te delen als hij dat liever niet doet. Wat betreft locatie in de vorige release: als u locatie nodig had in een voorgronddienst, moest u dat aangeven in het manifest. We hebben die mogelijkheid uitgebreid naar camera en microfoon in Android 11. U moet nu dus hetzelfde kenmerk gebruiken, namelijk voorgronddiensttype, maar er zijn een paar nieuwe vlaggen voor camera en microfoon als u ook toegang nodig hebt in een voorgronddienst. Er zijn nog veel meer privacywijzigingen waar u kennis van moet nemen. Pakketzichtbaarheid: het is niet mogelijk om alle pakketten die op een apparaat zijn geïnstalleerd op te vragen. In plaats daarvan moet u in het manifest aangeven waartoe u toegang wilt hebben. Scope-opslag: daar zijn nog enkele wijzigingen doorgevoerd terwijl we doorgaan met de migratie naar die nieuwe wereld, waaronder zaken die het voor ontwikkelaars gemakkelijker maken, zoals toegang tot onbewerkte padnamen en de mogelijkheid om batchbewerkingen uit te voeren met de MediaStore API's.

Automatisch opnieuw instellen van machtigingen. Als een gebruiker een applicatie installeert, deze eenmaal uitvoert, bepaalde machtigingen verleent en deze vervolgens een paar jaar niet meer uitvoert, waarom heeft deze dan nog steeds toegang tot dezelfde machtigingen? Op een bepaald moment wordt er automatisch opnieuw ingesteld en moet de applicatie opnieuw om die machtigingen vragen. U kunt hierover en nog veel meer te weten komen in de lezing over privacywijzigingen in Android 11 en de lezing over moderne opslag op Android. Bekijk die dus eens. Iets anders dat we in Android 11 hebben toegevoegd, zijn verschillende functies om het leven van Android-ontwikkelaars gemakkelijker te maken, zodat het iets eenvoudiger wordt om geweldige Android-apps te schrijven. Bijvoorbeeld wifi-foutopsporing, want als er één universele waarheid is, dan is het wel dat er nooit genoeg USB-poorten beschikbaar zijn. Zou het niet fijn zijn als u in plaats daarvan via wifi verbinding kunt maken met uw apparaat? Dat kan nu. Het is voorlopig nog een beetje handmatig. Je schakelt in principe wifi-foutopsporing in en vervolgens moet je handmatig koppelen en verbinding maken met het apparaat, maar in de Android Studio 4.2 Canary-builds is het ingeschakeld om in plaats daarvan via de tool toegankelijk te zijn, wat het een beetje gemakkelijker maakt. Ook hebben we de afgelopen paar releases nullability-annotaties toegevoegd aan platform-API's, en dat hebben we deze keer nog meer gedaan. Er zijn twee categorieën. Er is de recente...

annotaties, recent nullable en recent non-null. Deze geven aan dat we ze net in deze release hebben toegevoegd en dat ze waarschuwingen zullen activeren als je wordt gefactureerd. Als je een Kotlin-ontwikkelaar bent, maakt dit het leven van Kotlin-ontwikkelaars dus een stuk gemakkelijker. Als je een Kotlin-ontwikkelaar bent en je roept deze code aan met een parameter die dit contract niet naleeft, krijg je een waarschuwing in je build en moet je dat oplossen. Aan de andere kant hebben we de volledige annotaties, niet recent, en. Deze zijn nullable en non-null, en als je deze aanroept met code die het verkeerde doet, geef je een potentieel null-parameter door aan een non-null API-aanroep, dan zal dat daadwerkelijk een build-fout veroorzaken en moet je dat probleem echt onmiddellijk oplossen. Dus als ze de vorige keer recent waren, is de kans groot dat ze deze keer daadwerkelijk volledige nullable en non-null annotaties zijn. Anders hebben we ze deze keer misschien als nieuwe annotaties toegevoegd. We wilden je build niet verstoren. Volledige advertenties, dus we hebben ze onlangs toegevoegd. Bekijk die dus eens. Hopelijk maakt dat het leven voor Kotlin-ontwikkelaars in het algemeen beter. Een ander ding dat we hebben gedaan om het gemakkelijker te maken om te achterhalen wat er daadwerkelijk in het veld gebeurt, is het rapporteren van crashredenen. Het is erg moeilijk om erachter te komen waarom je app is gecrasht op het apparaat van iemand die je nog nooit hebt gezien.

De kans is groot dat de ontwikkel- en testomgeving die u op kantoor of thuis hebt, niet overeenkomt met wat uw gebruikers in de echte wereld gebruiken, toch? Zou het niet fijn zijn als u zou kunnen achterhalen wat er in de echte wereld gebeurt? Dat kan nu. Er is een API waarmee u kunt opvragen waarom uw app is afgesloten, zelfs als deze niet op een apparaat staat dat u ooit eerder hebt gezien. Zo kunt u historische redenen voor het afsluiten van processen opvragen. Dat levert u een verzameling informatie op die u kunt doorlopen om informatie te verkrijgen over bijvoorbeeld: is deze app gecrasht? Was er een ANR? Was er onvoldoende geheugen? Vervolgens kunt u deze gegevens uploaden, loggen en bekijken. U kunt dit rechtstreeks doen als ontwikkelaar of u kunt een crashrapportageservice gebruiken. Deze crashrapportageservices kunnen dit en andere faciliteiten intern gebruiken om dit soort informatie op een zeer gedetailleerd niveau van het platform te verkrijgen. GWP-ASAN bouwt voort op iets dat we eerder in Android 10 hebben ingeschakeld, genaamd HWASAN. HWA-ASAN ging dus over het bieden van een omgeving, een aanpak die je kon gebruiken in je build-, test- en debugomgeving, zodat je in feite een alternatieve geheugentoewijzer installeert. En als je dan als native ontwikkelaar toegang krijgt tot dat geheugen, dit is allemaal voor native ontwikkeling, als je op een manier toegang krijgt tot dat geheugen die niet de bedoeling is, bijvoorbeeld als je iets dereferentieert dat is gewist, dan zal dat een foutmelding veroorzaken, een crash, en een rapport genereren. Dat is geweldig, maar het is zoveel overhead, zowel in termen van geheugen als runtime, om dit extra toewijzingsmechanisme te hebben, dat het te veel was om in de echte wereld te gebruiken. GWP-ASAN doet in feite een klein deel daarvan. Het is een soort steekproefbenadering om datzelfde probleem op te lossen, waarbij niet overal die alternatieve allocator wordt gebruikt. In plaats daarvan is het alleen op bepaalde locaties. En nogmaals, als een van die problemen zich voordoet, zal het een crash veroorzaken, een rapport genereren en dan kun je dat rapport bekijken. Het wordt automatisch geüpload naar je Google Play-dashboard. En aangezien het slechts een steekproef is van de toewijzingen, is de overhead laag genoeg om dit op alles te kunnen gebruiken. Je schakelt het heel eenvoudig in in je manifest. Je zegt gewoon dat de GWP ASAN-modus altijd gelijk is. Je kunt dit ook voor de hele applicatie doen, of je kunt het alleen voor subprocessen of activiteiten doen als je dat wilt. En als een van deze problemen zich voordoet, veroorzaakt dat automatisch een crash en een crashrapport, dat vervolgens automatisch wordt geüpload. ADB Incremental zorgt ervoor dat je echt grote applicaties sneller op je testapparaat kunt installeren. Stel dat je een game hebt met twee gigabyte aan data en je wilt slechts één regel code wijzigen. Elke keer dat je die regel code wijzigt, moet je twee gigabyte aan applicatie naar het apparaat pushen, wat even duurt en waarschijnlijk erg vervelend en vermoeiend is. Maar wat je in plaats daarvan kunt doen, is ADB Incremental gebruiken, waardoor dit tot wel 10 keer sneller gaat.

Zo werkt het. Je gebruikt een alternatief handtekeningmechanisme en vervolgens gebruik je adb install dash dash incremental om hiervan te profiteren. We hebben enkele gedragswijzigingen doorgevoerd, zoals enkele van de privacywijzigingen waar we het eerder over hadden, maar we vereenvoudigen de werking ervan. De meeste van deze wijzigingen zijn alleen van kracht als je je op deze API-versie richt. Dus als je je nog niet op Android 11 richt, hoef je niet veel te doen. Maar als je je wel op deze release wilt richten, kun je deze gedragswijzigingen eenvoudig inschakelen via de opdrachtregel, wat je ook in eerdere releases kon doen, of via een nieuwe gebruikersinterface die we hebben toegevoegd aan de instellingen voor ontwikkelaarsopties. De gebruikersinterface ziet er ongeveer zo uit. U kunt in principe elk van de gedragswijzigingen gaandeweg inschakelen, of u kunt aan de linkerkant de opdrachtregelcode zien. U kunt deze opdracht uitvoeren, waardoor deze wordt ingeschakeld, en u kunt de wijziging zien in de gebruikersinterface aan de rechterkant. Op het gebied van grafische weergave en media zijn er verschillende wijzigingen doorgevoerd. Als je een NDK-ontwikkelaar bent en waarschijnlijk toegang wilde hebben tot onze beelddecoders, omdat we er een heleboel hebben voor alle standaardbestandsindelingen die je zou verwachten, moest je meestal via JNI een up-call uitvoeren om via de Android SDK een down-call uit te voeren naar wat aan onze kant eigenlijk native code was om deze beelden te decoderen. Dat was nogal vervelend om te doen. Veel ontwikkelaars kozen er daarom voor om gewoon een andere native bibliotheek met eigen decoders te bundelen, waardoor je in feite twee bibliotheken hebt. We hebben de platformdecoders en de andere decoders die je bundelt, waardoor je APK-bestanden groter worden. Zou het niet fijn zijn als je dat niet hoefde te doen? Daarom stellen we nu NDK-API's rechtstreeks beschikbaar, zodat je onze decoders direct kunt gebruiken. We hebben ook de mogelijkheid om geanimeerde HEIF-bestanden te decoderen. Dit lijkt veel op de geanimeerde GIF, hoe je het ook wilt uitspreken. En het komt binnen als een geanimeerd afbeeldingsbestand. Het lijkt dus veel op de vorige functionaliteit, behalve dat HEIF-bestanden over het algemeen aanzienlijk kleiner zijn dan GIF-bestanden. Het is dus de moeite waard om eens te bekijken. De code om dat te doen ziet er ongeveer zo uit. U krijgt toegang tot het bestand, u maakt het bronobject voor de beelddecoder en vervolgens, buiten de hoofdthread om, doe dit niet op de hoofdthread, dit is het dure gedeelte, decodeert u de drawable. Als het binnenkwam als een geanimeerde afbeelding drawable, betekent dit dat het meerdere van deze frames heeft en u kunt doorgaan en de animatie starten. Als je een audio-ontwikkelaar bent en een NDK-ontwikkelaar, is de kans groot dat je iets gebruikt dat OpenSL ES heet. Dit is verouderd, dit is niet meer wat we aanbevelen. In plaats daarvan raden we je aan om een open source-bibliotheek te bekijken die Oboe heet. Deze is niet gebundeld. Hij is bedoeld voor C++-ontwikkelaars. Hij is open source. Het is bedoeld voor zowel hoogwaardige audio als audio met lage latentie. Het werkt helemaal terug tot API 16. U kunt het downloaden op GitHub via de URL die daar is gepost. Belangrijk is ook dat we een paar weken geleden hebben gesproken met enkele audio-ingenieurs die aan Oboe werken. Bekijk dus aflevering 135 van Android Developers Backstage voor meer informatie over hoe Oboe werkt en hoe u het kunt gebruiken.

Dus variabele verversingssnelheid. Sinds het begin der tijden draaien apparaten in principe op 60 frames per seconde, althans sinds het begin van mijn tijd in de mobiele wereld. Dit betekent dat je als ontwikkelaar ongeveer 16,67 milliseconden had om alles te doen wat nodig was om een frame te plaatsen. Als je dus een applicatie schrijft die zijn eigen renderingloop heeft, bijvoorbeeld een game, en je merkt dat je op sommige apparaten zoveel werk te doen hebt dat je die 60 frames per seconde niet kunt bijhouden, dat je niet alles kunt doen wat je moet doen in die 16 milliseconden, dan moet je terugvallen op de volgende beschikbare framesnelheid. De manier waarop de verversingssnelheid werkt, betekent dat je nu in feite slechts 30 frames per seconde krijgt. Maar dan komen er nieuwe apparaten op de markt die veel hogere verversingssnelheden mogelijk maken, 90 hertz, zelfs tot 120 frames per seconde. Daardoor kun je niet alleen sneller werken of kan de gebruiker het scherm sneller zien verversen, maar zijn er ook meer variaties in backoff-snelheden mogelijk. Je hebt nu de mogelijkheid om daar toegang toe te krijgen en dat doe je via een van de API's, zoals surface.setFrameRate. Dit is een hint aan het systeem dat je deze backoff-framesnelheid wilt en het systeem verzamelt al deze verzoeken van meerdere vensters die het tegelijkertijd moet weergeven en neemt de juiste beslissing voor de mogelijkheden van het apparaat en voor de verzoeken die het heeft gekregen. Er gebeurt nog meer, maar ik heb geen tijd om daar uitgebreid op in te gaan. Neural Networks API voor machine learning. Het is een API voor machine learning op het apparaat. De 1.3-release komt uit met het Android 11-platform. Sommige van de veranderingen hebben alles te maken met prestaties en functionaliteit. We hebben control flow, dus conditionals en loops en branches op een manier die softwareontwikkelaars verwachten en waarvan ze profiteren. We hebben ook asynchrone command queue API's, die minder overhead produceren voor ketenmodellen. En we hebben ook hard swish up, dat ik al noemde. Niet alleen omdat het snellere training en meer nauwkeurigheid mogelijk maakt, maar ook omdat ik die naam, hard swish up, erg leuk vind. Ik wilde het gewoon nog een keer zeggen.

5G maakt het mogelijk om via een aantal nieuwe apparaten en dankzij de mogelijkheden van providers snellere verbindingen met een lagere latentie, een betere bandbreedte en een lagere latentie te realiseren. En we hebben API's om daarvan te profiteren. Stel dat u een betere ervaring en een hogere resolutie wilt bieden, maar alleen als... Als de gebruiker zich op een onbeperkt netwerk bevindt of over de bandbreedte beschikt om dat te ondersteunen. U kunt dus API's zoals u hier ziet gebruiken om te bepalen of de situatie geschikt is om gebruik te maken van 5G-mogelijkheden. Bij automatisch invullen zijn we gewend aan de UI-ervaring waarbij je op een veld tikt en als automatisch invullen informatie voor je heeft, er een klein dropdownmenu verschijnt. Laten we nu eens zeggen dat we in een typische situatie een toetsenbord hebben. En het toetsenbord heeft een aantal suggesties bovenaan, en dan heeft automatisch invullen hierboven een aantal suggesties. Zou het niet fijn zijn als we dit allemaal in één UI konden combineren? En dat is wat we hebben met de nieuwe functie voor automatisch invullen. Er zijn twee kanten aan deze vergelijking. Je hebt toetsenborden die de informatie op een veilige manier kunnen weergeven. Voor alle duidelijkheid: ze hebben geen toegang tot de inhoud. Ze hebben toegang tot de gebruikersinterface die de informatie intern weergeeft.

En dan heb je nog wachtwoordapplicaties, deze automatische invulservices. Die kunnen die informatie op een veilige manier aan de toetsenborden verstrekken. Dus in plaats van dat dropdownmenu krijgen we de informatie nu in een toetsenbordapp te zien. We kunnen dit zien in een screenshot van het Google-toetsenbord hier, waar de gebruiker op dit veld heeft getikt en het toevallig een e-mailadres is. We zien dat het toetsenbord hieronder wordt ingevuld, of misschien is het een creditcardveld. We zien opnieuw dat het toetsenbord hieronder wordt ingevuld, of het is een echt e-mailadres. De manier waarop dat aan de toetsenbordkant werkt, is dat je inputmethodeservicemethoden moet implementeren. Je hebt dus deze onCreateInlineSuggestionsRequest. Je verwerkt dat verzoek van de IME en krijgt dan een antwoord terug dat je ook verwerkt om deze informatie daadwerkelijk weer te geven. Aan de wachtwoordkant verwerk je onFillRequest om deze informatie te verstrekken en maak je vervolgens een dataset zoals je dat normaal ook doet, maar je vult deze met inline presentatie-informatie. Vervolgens maak je deze invulreactie met die informatie en ben je klaar. We hebben ook een heleboel dingen buiten het platform gedaan, en dat worden er steeds meer. Bijvoorbeeld Jetpack, een suite van bibliotheken, meer dan 70 stuks, die om de paar weken worden uitgebracht, met allerlei dingen, van architectuurcomponenten tot compatibiliteits-API's en kernfunctionaliteit. Een van de nieuwe en spannende ontwikkelingen daar is Hilt, een bibliotheek voor dependency injection die bovenop Dagger is gebouwd.

Dit is de nieuwe aanbevolen aanpak voor DI op Android. Paging is volledig herschreven voor versie drie in Kotlin voor Kotlin, waarbij ontwikkelaars gebruikmaken van taalfuncties zoals coroutines om het schrijven van paging-applicaties veel eenvoudiger te maken. En CameraX heeft onlangs een bètaversie uitgebracht, dus bekijk die zeker eens, want die is bijna stabiel. Er gebeurt steeds meer op dat gebied en daar wordt uitgebreid over gesproken in de presentatie 'What's New in Android Jetpack', dus bekijk die voor alle informatie. Over Jetpack gesproken, Jetpack Compose is nog steeds pre-alpha. Dit is de nieuwe UI-toolkit voor Android. Deze wordt momenteel actief ontwikkeld. Het is reactief. Het is gebaseerd op Kotlin. Zoals ik al zei, het is pre-alpha-ontwikkeling. Het wordt openlijk ontwikkeld. Bekijk de informatie hierover. Voer de tutorial en het voorbeeld uit om er meer over te leren. Speel met de code.

Ga ook naar de Jetpack Compose-lezing voor meer specifieke informatie hierover. Android Studio heeft een aantal interessante dingen in petto in recente releases. De 4.0-release is onlangs stabiel geworden. Motion Editor is een visuele tool voor het maken van motion layout-bestanden. Je kunt al enkele maanden motion layouts maken, omdat deze tool actief werd ontwikkeld, maar je moest veel vervelende code schrijven, vooral voor animaties. Er waren veel dingen die je moest doen, maar het was vanaf het begin bedoeld als een visuele tool. Motion Editor biedt die mogelijkheid voor het maken van rijke animaties in je UI's. Ook heeft Layout Inspector een heleboel echt nieuwe fundamentele mogelijkheden toegevoegd. Zo kun je bijvoorbeeld je containmenthiërarchie in 3D visualiseren om beter te begrijpen wat er waar gebeurt, of kun je doorklikken op eigenschapswaarden om te zien waar die dingen worden ingesteld en waarom. De bètaversie van 4.1 maakt Database Inspector mogelijk, een erg handige tool als je Room of SQLite onder de motorkap gebruikt. Dan kun je zien wat er in je database gebeurt. Je hebt dus een apparaat waarop een applicatie draait die Room gebruikt.

En je hebt inzicht in die database op de tool zelf, en je kunt de gegevens aan beide kanten wijzigen en deze ook live aan beide kanten zien. De Canary-build is om een aantal redenen interessant. Een daarvan is de draadloze debugging-mogelijkheid die ik eerder noemde en die via de tool wordt ingeschakeld, waardoor deze iets gemakkelijker toegankelijk is op de Canary. Als je wilt spelen met Jetpack Compose, dat ik eerder noemde, moet je een Canary-build in Studio gebruiken. Dus hier moet je het halen. Een paar tools om te bekijken wat er nieuw is in Android-ontwikkelingstools en wat er nieuw is in ontwerptools. Wat distributie betreft, is het grote nieuws voor Google Play dat ze de Play-console volledig hebben herschreven. Het gaat vooral om een beter ontwerp en het begrijpelijker en toegankelijker maken van dingen, maar er zijn ook nieuwe mogelijkheden toegevoegd, zoals een sectie over de beleidsstatus, rapporten over gebruikerswerving en het beheer van het team van mensen dat daadwerkelijk toegang heeft tot de dashboardinformatie. Het is momenteel in bèta, dus ga naar die URL, bekijk het, download het, speel ermee, stuur ons feedback en kijk hoe het voor u werkt. Ga ook naar de presentatie 'Wat is er nieuw in Google Play'. Dat was het, maar ik heb nog een paar extra links die ik met jullie wil delen. Allereerst zijn alle presentaties die ik hier heb genoemd, en nog meer, want ik heb niet alles kunnen behandelen, te vinden in de Android 11 beta launch show. Ga dus naar het YouTube-kanaal van Android Developers om alle presentaties te bekijken die daar zijn geplaatst.

de Android 11-previewsite, download de bètaversie, probeer deze uit, kijk hoe deze met uw app werkt en stuur ons feedback als dingen niet werken zoals verwacht. 11 Weeks of Android is een nieuwe campagne die we volgende week lanceren, omdat er niet genoeg tijd was om alles in slechts een tiental video's te behandelen. Dus laten we u meer vertellen. Er komt elke week nieuwe content uit over specifieke onderwerpen, zoals UI en Jetpack. Kom dus elke week terug om te zien wat het onderwerp is en leer gaandeweg alles over dat onderwerp. We werken ook samen met onze online communities over de hele wereld om Android 11-meetups te organiseren. Dit zijn online meetups die tot en met augustus overal ter wereld plaatsvinden. Ga dus naar die site om te kijken of er iets bij jou in de buurt gebeurt. En tot slot is Now in Android een reeks artikelen, video's en een podcast die ik maak om het wat makkelijker te maken om te begrijpen wat er in de Android-wereld gebeurt. We doen veel dingen, zowel op het gebied van het platform als op het gebied van ontwikkelaarsrelaties, artikelen, video's, alles wat er voortdurend gebeurt. Zou het niet fijn zijn als we een makkelijke manier hadden om te begrijpen wat er elke paar weken gebeurt? Dat is waar NOW in Android over gaat. Bekijk ze dus eens. Voor meer informatie over wat er gebeurt in Android, kun je in de tussentijd de video's bekijken. Leer alles over Android 11 en wat er gebeurt in de Android-wereld. Bedankt.