Android 11 AMA: Geen scrollende schermafbeeldingen, snellere app-lanceringen, meer

Gisteren heeft Google dit bekendgemaakt Android 11 Bèta 2, met de definitieve SDK, NDK, app-gerichte oppervlakken, platformgedrag en beperkingen op niet-SDK-interfaces voor ontwikkelaars. Vandaag beantwoordt Google vragen met betrekking tot Android 11 via de /r/AndroidDev-community van Reddit na het beantwoorden van vragen vorige week. Hier is een samenvatting van alles wat we hebben geleerd van Google's AMA (Ask Me Anything).

Een van de meest verwachte functies van Android 11 zal niet beschikbaar zijn wanneer het besturingssysteem wordt geïnstalleerd verlaat de bèta op 8 september: Schermafbeeldingen scrollen. Aanvankelijk gepland voor lancering in Android 11, heeft Google nu bevestigd dat de functie "niet geschikt was voor R." Android 11 Developer Preview 1 en alle volgende DP- en bètaversies hebben een tijdelijke knop waarmee u een scrollende schermafbeelding kunt maken

handmatig opgedoken met een verborgen ontwikkelaarsopdracht, maar als je op de knop tikt, wordt er eenvoudigweg een toastbericht weergegeven waarin staat dat de functie 'niet geïmplementeerd' is.

We hoopten dat de functie zijn weg zou vinden naar een bètaversie of zelfs alleen maar naar de stabiele release, maar het lijkt erop dat dat gewoon niet zal gebeuren.

Dit nieuws zal begrijpelijkerwijs voor sommige gebruikers verontrustend zijn. Veel OEM's hebben deze functie immers al jaren in hun eigen software, dus waarom duurt het zo lang voordat Google deze aan Pixel-telefoons toevoegt? Zoals Dan Sandler van het System UI-team van Google uitlegt, is het probleem dat Google het goed wil doen. Sommige scrollende screenshot-implementaties emuleren eenvoudigweg een scroll en voegen vervolgens meerdere screenshots samen terwijl het scherm beweegt. Als je ooit te maken hebt gehad met UI-automatisering op Android, weet je dat dit niet altijd werkt, omdat, zoals de heer Sandler zegt, apps kunnen "een standaard RecyclerView gebruiken of hun eigen OpenGL-versnelde scroll-engine hebben geïmplementeerd." Omdat Google dat van plan is ze moeten deze functie niet alleen implementeren voor Pixel-smartphones, maar voor het hele Android-ecosysteem als onderdeel van AOSP het zal doorwerken alle apps en niet slechts 'een of twee zorgvuldig uitgekozen apps op een bepaald apparaat'.

Omdat het team "hun beperkte middelen moest inzetten", vooral vanwege de uitdagingen die daarmee gepaard gingen door COVID-19 besloot het team scrollende screenshots op een laag pitje te zetten voor een toekomstige Android-release.

Nieuwe CDD-vereiste om gebruikers te informeren over achtergrondbeperkingen

Het is geen geheim dat veel Android-OEM's, vooral Chinese, agressieve beperkingen hebben voor apps die op de achtergrond draaien. Sommige ontwikkelaars waren zo gefrustreerd omdat hun apps op de achtergrond werden gedood dat ze samen een website maakten met de naam 'Dood mijn app niet" om OEM's te rangschikken op basis van hoe slecht ze omgaan met app-processen op de achtergrond. Diezelfde ontwikkelaars heeft onlangs zelfs een benchmark gemaakt zodat gebruikers kunnen testen hoe agressief hun apparaat apps op de achtergrond doodt. De reden waarom veel OEM's graag app-processen op de achtergrond beëindigen is ingewikkeld, maar ik denk dat dit het beste kan worden uitgelegd in dit commentaar van Redditor /u/mogelijk twijfelachtig. De opmerking schetst de ingewikkelde status van de ontwikkeling van Android-apps in China, en hoe Chinese technologiebedrijven dat doen zijn betrokken bij het verder compliceren van de zaken, en hoe een gebrek aan Google-services bijdraagt ​​aan de voortdurende problemen troep.

Hoe dan ook, veel app-ontwikkelaars zijn begrijpelijkerwijs gefrustreerd door deze aanpassingen aan het gedrag van het Android-platform, wat ertoe heeft geleid dat ontwikkelaars een opmerking hebben gemaakt Google vraagt ​​wat ze eraan doen naar de top van de Reddit AMA. Hier is het antwoord van Google:

Er zijn een paar dingen die we uit deze reactie kunnen afleiden. Ten eerste wil Google dat OEM's transparanter zijn tegenover gebruikers over de beperkingen voor apps op de achtergrond die ze toepassen. Ik heb het (niet-uitgebrachte) Android 11 Compatibility Definition Document (CDD) gecontroleerd en de volgende voorgestelde toevoeging aan Sectie 3.5 - API-gedragscompatibiliteit gevonden:

Als apparaatimplementaties een eigen mechanisme implementeren om apps te beperken en dat mechanisme restrictiever is dan de “Zeldzame” stand-by-bucket op AOSP, dan:

[C-1-5] MOET gebruikers informeren als app-beperkingen automatisch op een app worden toegepast. (NIEUW) Dergelijke informatie MOET niet eerder worden verstrekt dan 24 uur voordat dergelijke beperkingen worden toegepast.

(Opmerking) Force Stop wordt als restrictiever beschouwd dan "Zeldzaam" en MOET voldoen aan alle vereisten onder 3.5.1, inclusief de nieuwe 3.5.1/C-1-5

In principe kan Google OEM's er niet van weerhouden hun eigen beperkende functies voor het doden van apps te implementeren. Ze eisen alleen dat OEM's gebruikers informeren als hun app-beperkingen automatisch worden toegepast. Een OEM zou een dialoogvenster kunnen laten zien dat ze gaan stoppen met het uitvoeren van batterijzuigende achtergrondapps in de achtergrond, en de gebruiker zou kunnen instemmen zonder te beseffen dat de apps die hij echt op de achtergrond wil draaien dat ook zijn aangetast! Google legt de verantwoordelijkheid bij ontwikkelaars om gevallen te behandelen waarin hun app onverwachts op de achtergrond wordt afgesloten. De opmerking van Reddit gaat verder met het benadrukken van het nieuwe "Redenen voor het afsluiten van app-processen"API die ontwikkelaars kan vertellen of hun app is gedood door de gebruiker of het besturingssysteem, of dat deze eenvoudigweg is gecrasht.

Aan de andere kant pakt Google eindelijk de oneerlijke praktijk aan van OEM's die bepaalde bevoorrechte applicaties toestaan ​​de beperkingen van hun achtergrondapps te omzeilen. Dit medium bericht van ontwikkelaar Timothy Asiimwe gaat gedetailleerd in op het feit dat apps als WhatsApp, Facebook en andere apps automatisch zijn vrijgesteld van de strenge achtergrondbeperkingen van sommige OEM-software. Google zegt dat ze "vereisen dat apparaatfabrikanten geen toelatingslijsten maken voor top-apps." We weten niet hoe dit zal worden afgedwongen, maar het is goed om te weten dat OEM's eindelijk gedwongen zullen worden om externe ontwikkelaars op gelijke voet te behandelen, hoe groot of klein hun apps ook zijn Zijn.

Ten slotte vermeldt Google ook hoe Android 11 "extra maatregelen heeft toegevoegd om misbruik door apps die zich misdragen te voorkomen", waardoor het voor OEM's minder aantrekkelijk wordt om op agressieve wijze achtergrondprocessen te beëindigen. Wat deze ‘extra maatregelen’ inhouden, wil het bedrijf echter niet uiteenzetten.

Verbeterde back-ups van apparaat naar apparaat

Vorige maand hebben we een wijziging in de documentatie van Android 11 opgemerkt hintte op ondersteuning voor betere lokale gegevensback-ups. In Android 11 negeert het systeem het kenmerk allowBackup Manifest voor elke app die zich richt op API-niveau 30 wanneer de gebruiker een 'apparaat-naar-apparaat'-migratie van app-bestanden initieert. Googler Eliot Stock zegt dat deze functie bedoeld is om het "voor telefoonfabrikanten veel gemakkelijker te maken om migratietools van apparaat naar apparaat te bouwen", zoals "Samsungs uitstekende Smart Switch-product" om helpen "ervoor te zorgen dat apps betrouwbaarder kunnen worden overgedragen tussen apparaten vanuit gebruikersperspectief." Helaas is dit niet van toepassing op cloudgebaseerde back-ups, omdat Google “softwareontwikkelaars controle wil geven over wat gebeurt met hun app-gegevens." Als zodanig respecteert Android 11 nog steeds het allowBackup-kenmerk voor elke cloudgebaseerde back-up en herstel, zoals via de ingebouwde Google Drive van Google Play Service back-up. Ten slotte erkent Google dat het back-upplafond van 25 MB per app voor sommige ontwikkelaars misschien niet genoeg is, dus onderzoeken ze manieren om dit op te lossen. Lokale back-ups op een pc worden echter niet overwogen en Google herhaalt hun plan geleidelijk uitfaseren van adb-back-up in een toekomstige Android-release.

Ontwikkelaars worden aangemoedigd om wrijvingsloze datamigratiemethoden te implementeren. De nieuwe Block Store-bibliotheek, dat deel uitmaakt van de Google Identity Services Library, is ontworpen om het gemakkelijker te maken om in te loggen bij herstelde apps vanuit de cloud op nieuwe apparaten, maar het is aan ontwikkelaars om te kiezen of ze dit wel of niet willen implementeren bibliotheek.

Hogere opstartsnelheden van apps met I/O Read Ahead Process (IORap)

Google experimenteert voortdurend met manieren om de prestaties in Android te verbeteren. Een van de weinig bekende functies die ze in Android 10 hebben toegevoegd, is de Unspecialized App Process Pool (USAP). Deze functie elimineert het forken van Zygote tijdens het opstartproces van de app, waardoor ongeveer ~5 ms wordt bespaard op de gemiddelde opstartsnelheid van de app op een Pixel 2-apparaat. De functie is momenteel standaard uitgeschakeld in AOSP, en Google legt uit dat het toegevoegde geheugengebruik nog moet worden getest. Wat echter interessanter is, is een nieuwe functie die naar Android 11 komt, genaamd I/O Read Ahead Process (IORap). Volgens Google, zal deze functie leiden tot "meer dan 5% snellere koude startups, waarbij hero-cases 20% sneller bereiken." Deze functie "zal applicatie-artefacten (zoals code en bronnen) vooraf ophalen tijdens het opstartproces" om het starten van de app te stimuleren snelheden.

Google heeft ook "verbeteringen aangebracht in de profielen die worden gebruikt om het opstartklassepad en de systeemimage te optimaliseren" wat de app-prestaties zal verbeteren en de geheugen- en opslagkosten die aan het systeem zijn gekoppeld, zal verlagen artefacten. Deze veranderingen zullen vooral ten goede komen aan apparaten met grotere hoeveelheden RAM, hoewel Google niet heeft gezegd wat de grens is waar we de meeste voordelen zullen zien.

Wijzigingen in de scoped-opslag van Android 11 - Waarom is de toegang tot /Downloads beperkt?

Apps die Android 11 targeten en de ACTION_OPEN_DOCUMENT_TREE-intentie gebruiken om toegang te vragen tot specifieke mappen op de externe opslag kan gebruikers niet langer om toegang vragen tot de hoofdmap van de externe opslag (/data/media/{user}), de download map (/data/media{user}/Download), of een van de app-specifieke gegevensmappen op de externe opslag (/Android/data of /Android/obb). Waarom is de toegang tot de downloadmap beperkt? Volgens Google Roxanna Aliabadi, komt dit omdat de downloadmap "het grootste risico loopt privé-informatie te bevatten." Als voorbeeld: gebruikers die hun belasting downloaden aangiften of bankafschriften hoeven zich geen zorgen te maken over de mogelijkheid dat apps misbruik maken van hun continue leestoegang tot de map. Google zegt dat de documentkiezer "bijgewerkte tekst zal hebben... om aan te geven dat Android bepaalde mappen heeft beperkt geselecteerd worden.” Dit zal hopelijk de verwarring verminderen over waarom ze apps geen toegang kunnen verlenen tot bepaalde mappen meer.

Voor meer informatie over de aanstaande wijzigingen in het Scoped Storage- en Play-beleid, raadpleeg dit artikel.

Diverse onderwerpen

• Het standpunt van Google over rooten/modding
  • Jeff Bailey van het AOSP-team van Google herhaalt het standpunt van het bedrijf over het ondersteunen van keuzemogelijkheden. Google zal “ervoor blijven zorgen dat het modden/rooten van de Pixel-lijn van apparaten mogelijk is”, maar zal ook “de keuze van OEM’s ondersteunen om hun apparaten niet toe te staan geroot moeten worden." Bovendien geeft Google softwareontwikkelaars de keuze "om niet toe te staan ​​dat hun software op geroote apparaten draait", verwijzend naar recente veranderingen in detectie van softwaremanipulatie van de SafetyNet Attestation API.
• Wat is er gebeurd met "openen en instellen op standaard"?
  • Android 10 gemaakt het is een beetje vervelend om een ​​app als standaardhandler in te stellen voor specifieke links, wat volgens Google is gedaan om gebruikers te beschermen tegen 'uitbuitende apps'. Google trok zich terug over deze wijziging na er opnieuw over nagedacht te hebben, en een "aantal wijzigingen achter de schermen" door te voeren om de gebruiker te beschermen.
• Gebruikt u de Vulkan Graphics API om de gebruikersinterface weer te geven?
  • Google is uiteindelijk van plan dit te gebruiken de Vulkan Graphics API om de gebruikersinterface weer te geven, wat enkele prestatieverbeteringen zal opleveren. Dit is wordt nog geëvalueerd, maar het bedrijf had geen bijzonderheden te delen.
• Ontbrekende CallScreeningService op veel apparaten
  • Android-apps kunnen de CallScreeningService-API om nieuwe inkomende en uitgaande oproepen te onderscheppen, zodat ze de beller kunnen identificeren en de oproep kunnen accepteren of weigeren. Hoewel dit een officieel gedocumenteerde API is, zijn er blijkbaar veel OEM's die deze niet goed implementeren, aldus ontwikkelaar /u/_zeromod_. Googlen bevestigt dat deze API wordt gevalideerd door de Compatibility Test Suite (CTS), een geautomatiseerde testsuite waaraan alle apparaten moeten slagen om als Android-compatibel te worden beschouwd. Om welke reden dan ook retourneert deze API null wanneer deze wordt aangeroepen op apparaten van OEM's zoals Huawei, Vivo, Xiaomi of Samsung, dus het is waarschijnlijk dat deze OEM's een bug in hun software hebben.
• Geen plannen voor een raamwerk voor audio-plug-ins
  • Een ontwikkelaar vroeg Google of ze van plan zijn een raamwerk voor audio-plug-ins te implementeren, zoals Apple's Audio Units, maar... het antwoord is dat het onwaarschijnlijk is dat dit in de nabije toekomst zal gebeuren.

U kunt alle antwoorden van het Android-engineeringteam lezen hier. Het team vertelt in een paar opmerkingen iets over Java, Kotlin, het Android-bouwsysteem, de CameraX API en andere onderwerpen. Er zijn ook verschillende opmerkingen over Wear OS, Android TV en Android Auto, maar Google herhaalt vooral hun bestaande werk op deze platforms en vertelt ontwikkelaars dat ze op de hoogte moeten blijven voor meer informatie tijdens de "Android Beyond-telefoons"week vanaf 10 augustus.