Android 11 AMA: Ingen rullende skærmbilleder, hurtigere applanceringer, mere

I går frigav Google Android 11 Beta 2, der bringer den færdiggjorte SDK, NDK, app-vendende overflader, platformadfærd og begrænsninger på ikke-SDK-grænseflader for udviklere. I dag besvarer Google spørgsmål relateret til Android 11 på Reddits /r/AndroidDev-fællesskab efter at have stillet spørgsmål i sidste uge. Her er en oversigt over alt, hvad vi har lært af Googles AMA (Ask Me Anything).

En af Android 11s mest forventede funktioner vil ikke være tilgængelig, når operativsystemet afslutter betaversionen den 8. september: Rulning af skærmbilleder. I første omgang planlagt til lancering i Android 11, har Google nu bekræftet, at funktionen "ikke klarede snittet for R." Android 11 Developer Preview 1 og alle efterfølgende DP- og Beta-udgivelser har en pladsholderknap til at tage et rullende skærmbillede, der kan være manuelt dukket op med en skjult udviklerkommando

, men ved at trykke på knappen vises blot en toast-meddelelse, der siger, at funktionen "ikke er implementeret."

Vi håbede, at funktionen ville finde vej til en beta eller endda bare den stabile udgivelse, men det ser ud til, at det bare ikke vil ske.

Denne nyhed vil forståeligt nok forstyrre nogle brugere. Mange OEM'er har trods alt haft denne funktion i deres egen software i årevis, så hvad tager Google så lang tid at tilføje den til Pixel-telefoner? Som forklaret af Dan Sandler fra Googles System UI-team, er problemet, at Google vil gøre det rigtigt. Nogle implementeringer af scroll-skærmbilleder derude efterligner blot en rulle og syr derefter flere skærmbilleder sammen, mens skærmen bevæger sig. Hvis du nogensinde har beskæftiget dig med UI-automatisering på Android, vil du vide, at dette ikke altid virker, da, som hr. Sandler nævner, apps kan bruge "en mose-standard RecyclerView eller have implementeret deres egen OpenGL-accelererede rullemotor." Siden Google planlægger at implementere denne funktion til ikke kun Pixel-smartphones, men for hele Android-økosystemet som en del af AOSP, de skal sørge for det vil virke alle apps og ikke kun "en eller to håndplukkede apps på en bestemt enhed."

Fordi holdet var nødt til at "fokusere [deres] begrænsede ressourcer", især på grund af udfordringerne af COVID-19 besluttede holdet at lægge rullende skærmbilleder på backburneren til en fremtidig Android-udgivelse.

Nyt CDD-krav for at informere brugere om baggrundsbegrænsninger

Det er ingen hemmelighed, at mange Android OEM'er, især kinesiske, har aggressive begrænsninger på apps, der kører i baggrunden. Nogle udviklere var så frustrerede over, at deres apps blev dræbt i baggrunden, at de gik sammen om at lave en hjemmeside kaldet "Dræb ikke min app" for at rangere OEM'er baseret på, hvor dårligt de håndterer baggrundsappprocesser. De samme udviklere selv for nylig lavet et benchmark så brugere kan teste, hvor aggressivt deres enhed dræber apps i baggrunden. Grunden til, at mange OEM'er elsker at dræbe baggrundsappprocesser er kompliceret, men jeg tror, ​​det er bedst forklaret i denne kommentar af Redditor /u/muligvis tvivlsom. Kommentaren skitserer den komplicerede status for Android-appudvikling i Kina, hvordan kinesiske teknologivirksomheder er med til at komplicere tingene yderligere, og hvordan mangel på Google-tjenester bidrager til det løbende rod.

Uanset hvad er mange app-udviklere forståeligt nok frustrerede over disse justeringer af Android-platformens adfærd, hvilket har resulteret i, at udviklere har skubbet en kommentar spørger Google, hvad de gør ved det til toppen af ​​Reddit AMA. Her er Googles svar:

Der er et par ting at tage med fra dette svar. For det første ønsker Google, at OEM'er skal være mere gennemsigtige over for brugerne om de begrænsninger for baggrundsapps, de anvender. Jeg tjekkede (ikke-udgivet) Android 11 Compatibility Definition Document (CDD) og fandt følgende foreslåede tilføjelse til Sektion 3.5 - API Behavioural Compatibility:

Hvis enhedsimplementeringer implementerer proprietære mekanismer til at begrænse apps, og denne mekanisme er mere restriktiv end "sjælden" standby-bøtte på AOSP, vil de:

[C-1-5] SKAL informere brugerne, hvis app-begrænsninger anvendes automatisk på en app. (NYT) Sådanne oplysninger MÅ ikke gives tidligere end 24 timer før sådanne begrænsninger anvendes.

(Bemærk) Force Stop anses for at være mere restriktiv end "sjælden" og SKAL overholde alle krav under 3.5.1, inklusive ny 3.5.1/C-1-5

Grundlæggende er Google ikke meget for at forhindre OEM'er i at implementere deres egne restriktive app-dræbende funktioner. De kræver kun, at OEM'er informerer brugerne, hvis deres app-begrænsninger automatisk anvendes. En OEM kunne vise en dialogboks, at de vil stoppe batterisugende baggrundsapps i at køre i baggrund, og brugeren kunne give samtykke uden at være klar over, hvilke apps de virkelig ønsker at køre i baggrunden også er påvirket! Google pålægger udviklere at håndtere sager, hvor deres app bliver dræbt uventet i baggrunden. Faktisk fortsætter Reddit-kommentaren med at fremhæve den nye "årsager til afslutning af appproces" API, der kan fortælle udviklere, om deres app blev dræbt af brugeren, OS, eller om den simpelthen gik ned.

På den anden side tager Google endelig fat på den uretfærdige praksis med OEM'er, der tillader visse privilegerede applikationer at omgå deres baggrundsapprestriktioner. Dette mellemstore indlæg af udvikler Timothy Asiimwe går i detaljer om apps som WhatsApp, Facebook og andre apps er automatisk undtaget fra de skrappe baggrundsbegrænsninger for nogle OEM-software. Google siger, at de "kræver, at enhedsproducenter ikke opretter tilladelseslister for topapps." Vi ved ikke, hvordan dette vil blive håndhævet, men det er godt at vide, at OEM'er endelig vil blive tvunget til at behandle tredjepartsudviklere på lige fod – uanset hvor store eller små deres apps er. er.

Endelig nævner Google også, hvordan Android 11 har "tilføjet ekstra foranstaltninger for at forhindre misbrug ved at opføre sig forkert i apps", hvilket gør det mindre tillokkende for OEM'er at aggressivt dræbe baggrundsprocesser. Virksomheden har dog ikke uddybet, hvad disse "ekstra tiltag" indebærer.

Forbedrede Device-to-Device Backups

I sidste måned opdagede vi en ændring af Android 11s dokumentation antydet understøttelse af bedre lokal sikkerhedskopiering af data. I Android 11 vil systemet se bort fra allowBackup Manifest-attributten for enhver app, der er målrettet mod API-niveau 30, når brugeren starter en "enhed-til-enhed"-migrering af appfiler. Googler Eliot Stock siger, at denne funktion er beregnet til at gøre det "meget nemmere for telefonproducenter at bygge enhed til enhed migreringsværktøjer" såsom "Samsungs fremragende Smart Switch-produkt" til hjælpe med at "sikre apps mere pålidelig overførsel mellem enheder fra et brugerperspektiv." Desværre gælder dette ikke for cloud-baserede sikkerhedskopier, da Google ønsker at "give softwareudviklere kontrol over, hvad sker med deres appdata." Som sådan vil Android 11 stadig respektere allowBackup-attributten for enhver skybaseret sikkerhedskopiering og gendannelse, f.eks. gennem Google Play-tjenestens indbyggede Google Drev backup. Endelig anerkender Google, at 25 MB-per-app backup-loftet muligvis ikke er nok for nogle udviklere, så de undersøger måder at løse det på. Lokale sikkerhedskopier til en pc er dog ikke under overvejelse, og Google gentager deres plan udfase adb backup i en fremtidig Android-udgivelse.

Udviklere opfordres til at implementere friktionsfri datamigreringsmetoder. Det nyt Block Store-bibliotek, som er en del af Google Identity Services Library, er designet til at gøre det nemmere at logge ind på gendannet apps fra skyen på nye enheder, men det er op til udviklerne at vælge, om de vil implementere dette eller ej bibliotek.

Hurtigere appstarthastigheder med I/O Read Ahead Process (IORap)

Google eksperimenterer altid med måder at forbedre ydeevnen i Android på. En af de lidt kendte funktioner, de tilføjede i Android 10, kaldes Unspecialized App Process Pool (USAP). Denne funktion eliminerer forking Zygote under app-opstartsprocessen, hvilket sparer ca. ~5ms i gennemsnitlige app-starthastigheder på en Pixel 2-enhed. Funktionen er pt deaktiveret som standard i AOSP, og Google forklarer, at dens tilføjede hukommelsesbrug stadig skal testes. Hvad der dog er mere interessant, er en ny funktion, der kommer til Android 11 kaldet I/O Read Ahead Process (IORap). Ifølge Google, vil denne funktion føre til "mere end 5 % hurtigere kold opstart med helte-cases, der når 20 % hurtigere." Denne funktion "vil forhåndshente applikationsartefakter (som kode og ressourcer) under opstartsprocessen" for at øge app-lanceringen hastigheder.

Google har også "foretaget forbedringer af de profiler, der bruges til at optimere boot class-stien og systembilledet" hvilket vil forbedre appens ydeevne og reducere hukommelses- og lageromkostningerne forbundet med systemet artefakter. Disse ændringer vil for det meste gavne enheder med større mængder RAM, selvom Google ikke har sagt, hvad grænsen er for, hvor vi vil se de fleste fordele.

Ændringer i Android 11's Scoped Storage - Hvorfor er adgangen til /Downloads begrænset?

Apps, der er målrettet mod Android 11 og bruger ACTION_OPEN_DOCUMENT_TREE hensigten til at anmode om adgang til specifikke mapper på den eksterne storage vil ikke længere være i stand til at bede brugere om adgang til rodmappen på det eksterne lager (/data/media/{user}), download mappe (/data/media{bruger}/Download), eller en af ​​de app-specifikke datamapper på det eksterne lager (/Android/data eller /Android/obb). Hvorfor er adgangen til downloadbiblioteket begrænset? Ifølge Google Roxanna Aliabadi, det er fordi downloadmappen "er den største risiko for at have private oplysninger." For eksempel brugere, der downloader deres skat returneringer eller kontoudtog bør ikke bekymre sig om muligheden for, at apps misbruger deres kontinuerlige læseadgang til vejviser. Google siger, at dokumentvælgeren vil have "opdateret tekst... for at indikere, at Android har begrænset visse mapper skal vælges." Dette vil forhåbentlig reducere forvirringen om, hvorfor de ikke kan give apps adgang til bestemte mapper længere.

For mere information om de kommende ændringer af politikken for scoped Storage and Play, henvise til denne artikel.

Diverse emner

• Googles holdning til rooting/modding
  • Jeff Bailey fra Googles AOSP-team gentager virksomhedens holdning til at støtte valg. Google vil "fortsætte med at sikre, at modding/rooting af Pixel-enheder er mulig", men vil også "støtte OEM'ers valg om ikke at tillade deres enheder at blive rootet." Desuden giver Google softwareudviklere valget "at ikke tillade deres software at køre på rootede enheder," med henvisning til de seneste ændringer i detektering af softwaremanipulation af SafetyNet Attestation API.
• Hvad skete der med "åbn og sæt til standard"?
  • Android 10 lavet det er en smule irriterende at indstille en app som standardhandler for specifikke links, som Google siger blev gjort for at beskytte brugere mod "udnyttende apps." Google bakkede på denne ændring efter at have genovervejet den, foretaget en "antal ændringer bag kulisserne" for at beskytte brugeren.
• Bruger du Vulkan Graphics API til at gengive brugergrænsefladen?
  • Google planlægger i sidste ende at bruge Vulkan Graphics API til at gengive brugergrænsefladen, hvilket vil give nogle præstationsforbedringer. Dette er stadig evalueres, men virksomheden havde ikke nogen detaljer at dele.
• Mangler CallScreeningService på mange enheder
  • Android apps kan implementere CallScreeningService API at opsnappe nye indgående og udgående opkald, så de kan identificere den, der ringer op og enten acceptere eller afvise opkaldet. Selvom dette er en officielt dokumenteret API, er der tilsyneladende mange OEM'er, der ikke implementerer det korrekt, ifølge udvikler /u/_nulmod_. Google bekræfter at denne API er valideret af Compatibility Test Suite (CTS), en automatiseret testsuite, som alle enheder skal bestå for at blive betragtet som Android-kompatible. Uanset årsagen returnerer denne API null, når den kaldes på enheder fra OEM'er som Huawei, Vivo, Xiaomi eller Samsung, så det er sandsynligt, at disse OEM'er har en fejl i deres software.
• Ingen planer om en audio plugin-ramme
  • En udvikler spurgte Google, om de planlægger at implementere en audio plugin-ramme som Apples lydenheder, men svaret er, at det næppe vil ske i den nærmeste fremtid.

Du kan læse alle svarene fra Android-ingeniørteamet her. Holdet taler lidt om Java, Kotlin, Android-byggesystemet, CameraX API og andre emner i et par kommentarer. Der er også flere kommentarer om Wear OS, Android TV og Android Auto, men Google gentager for det meste deres eksisterende arbejde på disse platforme og fortæller udviklere at holde sig opdateret for mere information i løbet af "Android Beyond Phones" uge, der starter den 10. august.