Android 11 AMA: Žádné posouvání snímků obrazovky, rychlejší spouštění aplikací, více

Včera to Google zveřejnil Android 11 Beta 2, která přináší finalizovanou sadu SDK, NDK, povrchy orientované na aplikace, chování platformy a omezení pro rozhraní bez sady SDK pro vývojáře. Dnes Google odpovídá na otázky týkající se Androidu 11 v komunitě /r/AndroidDev Reddit po dotazech z minulého týdne. Zde je souhrn všeho, co jsme se naučili od Google AMA (Ask Me Anything).

Jedna z nejočekávanějších funkcí Androidu 11 nebude k dispozici, až bude OS končí beta 8. září: Posouvání snímků obrazovky. Zpočátku plánované spuštění na Android 11, Google nyní potvrdil, že tato funkce „neprosadila R“. Android 11 Developer Preview 1 a všechny následující verze DP a Beta mají zástupné tlačítko pro pořízení snímku obrazovky, který může být ručně vynořený pomocí skrytého příkazu vývojáře, ale klepnutím na tlačítko jednoduše zobrazíte zprávu o přípitku, která uvádí, že funkce „není implementována“.

Doufali jsme, že se tato funkce dostane do beta verze nebo dokonce jen do stabilní verze, ale vypadá to, že se to prostě nestane.

Tato zpráva bude pochopitelně některé uživatele rozrušovat. Koneckonců, mnoho výrobců OEM má tuto funkci ve svém vlastním softwaru již léta, tak proč Googlu trvá tak dlouho, než ji přidá do telefonů Pixel? Jak vysvětlil Dan Sandler z týmu Google System UI, problém je v tom, že Google to chce udělat správně. Některé implementace posouvajících se screenshotů jednoduše emulují posouvání a poté spojují dohromady více screenshotů, jak se obrazovka pohybuje. Pokud jste se někdy zabývali automatizací uživatelského rozhraní na Androidu, budete vědět, že to ne vždy funguje, protože, jak zmiňuje pan Sandler, aplikace může používat "standardní RecyclerView pro bažiny nebo implementovat vlastní rolovací engine s akcelerací OpenGL." Protože to Google plánuje implementovat tuto funkci nejen pro smartphony Pixel, ale pro celý ekosystém Android jako součást AOSP, musí se ujistit bude to fungovat Všechno aplikace a ne pouze „jednu nebo dvě ručně vybrané aplikace na konkrétním zařízení“.

Protože tým musel „zaměřit [jejich] omezené zdroje“, zejména kvůli výzvám, které to přineslo do COVID-19 se tým rozhodl umístit snímky obrazovky na backburner pro budoucí vydání Androidu.

Nový požadavek CDD informovat uživatele o omezeních na pozadí

Není žádným tajemstvím, že mnoho výrobců Android OEM, zejména těch čínských, má agresivní omezení aplikací běžících na pozadí. Někteří vývojáři byli tak frustrovaní ze zabíjení jejich aplikací na pozadí, že se spojili a vytvořili web s názvem „Don't Kill My App" k seřazení výrobců OEM podle toho, jak špatně zvládají procesy aplikací na pozadí. Ti samí vývojáři dokonce nedávno udělal benchmark takže uživatelé mohou otestovat, jak agresivně jejich zařízení zabíjí aplikace na pozadí. Důvod, proč mnoho výrobců OEM tak rád zabíjí procesy aplikací na pozadí, je komplikovaný, ale myslím, že to nejlépe vysvětlí tento komentář od Redditor /u/možná sporné. Komentář nastiňuje komplikovaný stav vývoje aplikací pro Android v Číně, jak čínské technologické společnosti se podílejí na dalším zkomplikování věcí a jak k tomu přispívá nedostatek služeb Google nepořádek.

Bez ohledu na to je mnoho vývojářů aplikací pochopitelně frustrováno těmito vylepšeními chování platformy Android, což vedlo k tomu, že vývojáři vložili komentář ptát se Google, co s tím dělají na vrchol Reddit AMA. Zde je odpověď Google:

Z této odpovědi je třeba si odnést několik věcí. Za prvé, Google chce, aby výrobci OEM byli vůči uživatelům transparentnější ohledně omezení aplikací na pozadí, která uplatňují. Zkontroloval jsem (nevydaný) dokument s definicí kompatibility Android 11 (CDD) a našel jsem následující navrhovaný doplněk k části 3.5 – Kompatibilita chování API:

Pokud implementace zařízení implementují proprietární mechanismus pro omezení aplikací a tento mechanismus je restriktivnější než „vzácný“ pohotovostní segment na AOSP, pak:

[C-1-5] MUSÍ informovat uživatele, pokud jsou na aplikaci automaticky aplikována omezení aplikace. (NOVINKA) Tyto informace NESMÍ být poskytnuty dříve než 24 hodin před uplatněním těchto omezení.

(Poznámka) Force Stop je považován za přísnější než „Vzácný“ a MUSÍ splňovat všechny požadavky podle 3.5.1, včetně nového 3.5.1/C-1-5

Google v zásadě moc nebrání výrobcům OEM v implementaci jejich vlastních restriktivních funkcí zabíjení aplikací. Požadují pouze, aby výrobci OEM informovali uživatele, pokud se automaticky uplatňují omezení jejich aplikací. OEM by mohl zobrazit dialog, že zastaví běh aplikací na pozadí, které vysávají baterii na pozadí a uživatel mohl souhlasit, aniž by si uvědomil, jaké aplikace skutečně chtějí na pozadí spouštět postižený! Google klade břemeno na vývojáře, aby se vypořádali s případy, kdy je jejich aplikace nečekaně zabita na pozadí. Opravdu, komentář na Redditu dále zdůrazňuje nové „důvody ukončení procesu aplikace" API, které může vývojářům sdělit, zda byla jejich aplikace zabita uživatelem, operačním systémem, nebo zda prostě spadla.

Na druhou stranu Google konečně řeší nekalé praktiky OEM, které umožňují určitým privilegovaným aplikacím obejít jejich omezení aplikací na pozadí. Tento příspěvek od vývojáře Timothy Asiimwe podrobně popisuje aplikace jako WhatsApp, Facebook a další aplikace, které jsou automaticky vyňaty z přísných omezení na pozadí některých OEM softwaru. Google říká, že „vyžadují, aby výrobci zařízení nevytvářeli seznamy povolených pro nejlepší aplikace“. Nevíme, jak to bude vynucováno, ale je dobré vědět, že výrobci OEM budou konečně nuceni zacházet s vývojáři třetích stran stejně – bez ohledu na to, jak velké nebo malé jsou jejich aplikace jsou.

Nakonec Google také zmiňuje, jak Android 11 „přidal další opatření, aby zabránil zneužívajícímu chování nesprávně se chovajícími aplikacemi“, takže je pro výrobce OEM méně lákavé agresivně zabíjet procesy na pozadí. Co tato „zvláštní opatření“ obnáší, však společnost neupřesnila.

Vylepšené zálohování mezi zařízeními

Minulý měsíc jsme zaznamenali změnu v dokumentaci k Androidu 11 naznačil podporu lepších lokálních záloh dat. V systému Android 11 bude systém ignorovat atribut allowBackup Manifest pro jakoukoli aplikaci, která cílí na úroveň API 30, když uživatel zahájí migraci souborů aplikace „ze zařízení na zařízení“. Googler Eliot Stock říká, že tato funkce má výrobcům telefonů „mnohem usnadnit vytváření nástrojů pro migraci ze zařízení na zařízení“, jako je například „vynikající produkt Samsung Smart Switch“. pomáhají „zajistit spolehlivější přenos aplikací mezi zařízeními z pohledu uživatele“. Bohužel to neplatí pro zálohování v cloudu, protože Google chce „poskytnout vývojářům softwaru kontrolu nad tím, co se stane s daty jejich aplikací." Android 11 jako takový bude stále respektovat atribut allowBackup pro jakékoli zálohování a obnovení v cloudu, například prostřednictvím integrovaného Disku Google služby Google Play. záloha. A konečně, Google uznává, že 25 MB zálohování na aplikaci nemusí některým vývojářům stačit, takže hledají způsoby, jak to vyřešit. Místní zálohy do počítače však nepřicházejí v úvahu a Google svůj plán opakuje vyřaďte zálohu adb v budoucí verzi systému Android.

Vývojářům se doporučuje implementovat metody migrace dat bez tření. The nová knihovna Block Store, který je součástí knihovny Google Identity Services Library, je navržen tak, aby usnadnil přihlašování do obnovených aplikací z cloudu na nových zařízeních, ale je na vývojářích, zda se rozhodnou, zda to chtějí implementovat knihovna.

Rychlejší spouštění aplikací díky procesu I/O Read Ahead (IORap)

Google neustále experimentuje se způsoby, jak zlepšit výkon v systému Android. Jedna z málo známých funkcí, kterou přidali do Androidu 10, se nazývá Unspecialized App Process Pool (USAP). Tato funkce eliminuje rozvětvení Zygote během procesu spouštění aplikace a ušetří přibližně ~5 ms průměrné rychlosti spouštění aplikace na zařízení Pixel 2. Funkce je v současné době ve výchozím nastavení v AOSP zakázánoa Google vysvětluje, že využití přidané paměti stále vyžaduje testování. Co je však zajímavější, je nová funkce přicházející pro Android 11 nazvaná I/O Read Ahead Process (IORap). Podle Google, tato funkce povede k „o více než 5 % rychlejším studeným startům, přičemž případy hrdinů dosahují o 20 % rychleji“. Tato funkce „předběžně načte artefakty aplikací (jako kód a zdroje) během procesu spouštění“, aby se urychlilo spouštění aplikace rychlosti.

Google také „vylepšil profily používané k optimalizaci cesty spouštěcí třídy a obrazu systému“ což zlepší výkon aplikace a sníží náklady na paměť a úložiště spojené se systémem artefakty. Tyto změny budou většinou přínosem pro zařízení s vyšším množstvím paměti RAM, i když Google neuvedl, jaká je hranice, kde uvidíme největší výhody.

Změny Scoped Storage systému Android 11 – Proč je přístup k /Stahování omezen?

Aplikace, které cílí na Android 11 a používají záměr ACTION_OPEN_DOCUMENT_TREE k vyžádání přístupu ke konkrétním adresářům na externím úložiště již nebude moci žádat uživatele o přístup do kořenového adresáře externího úložiště (/data/media/{user}), stahování adresář (/data/media{user}/Download) nebo libovolný datový adresář specifický pro aplikaci na externím úložišti (/Android/data nebo /Android/obb). Proč je přístup do adresáře Download omezen? Podle Google Roxanna Aliabadi, je to proto, že složka pro stahování „je nejvíce ohrožena soukromými informacemi“. Například uživatelé, kteří si stahují svou daň vratky nebo bankovní výpisy by se neměly obávat možnosti aplikací zneužít jejich nepřetržitý přístup ke čtení adresář. Google říká, že nástroj pro výběr dokumentů bude mít „aktualizovaný text..., který označuje, že Android omezil určité složky aby byly vybrány." To doufejme sníží zmatek ohledně toho, proč nemohou aplikacím udělit přístup k určitým adresářům už

Další informace o nadcházejících změnách zásad Scoped Storage a Play viz tento článek.

Různá témata

• Postoj Google k rootování/moddingu
  • Jeff Bailey z týmu AOSP společnosti Google opakuje postoj společnosti k podpoře výběru. Google bude „nadále zajišťovat, aby bylo možné modifikovat/rootovat řadu zařízení Pixel“, ale bude také „podporovat volbu výrobců OEM nepovolit jejich zařízení Google dále dává vývojářům softwaru možnost „nepovolit spuštění jejich softwaru na zakořeněných zařízeních“ s odkazem na nedávné změny v detekce softwarové manipulace s SafetyNet Attestation API.
• Co se stalo s „otevřít a nastavit jako výchozí“?
  • Vytvořen Android 10 je trochu otravné nastavit aplikaci jako výchozí ovladač pro konkrétní odkazy, což podle Googlu bylo provedeno za účelem ochrany uživatelů před „vykořisťovatelskými aplikacemi“. Google ustoupil na této změně poté, co ji přehodnotil a provedl „řadu změn v zákulisí“, aby ochránil uživatele.
• Používáte rozhraní Vulkan Graphics API k vykreslení uživatelského rozhraní?
  • Google nakonec plánuje použít Vulkan Graphics API pro vykreslení uživatelského rozhraní, což přinese určitá vylepšení výkonu. Tohle je stále se hodnotí, ale společnost neměla žádné podrobnosti, o které by se mohla podělit.
• Na mnoha zařízeních chybí služba CallScreeningService
  • Aplikace pro Android mohou implementovat CallScreeningService API zachytit nové příchozí a odchozí hovory, což jim umožní identifikovat volajícího a buď přijmout nebo odmítnout hovor. Ačkoli se jedná o oficiálně zdokumentované API, podle vývojáře /u/ je zjevně mnoho výrobců OEM, kteří jej řádně neimplementují_zeromod_. Google potvrzuje že toto API je ověřeno sadou Compatibility Test Suite (CTS), automatizovanou testovací sadou, kterou musí projít všechna zařízení, aby byla považována za kompatibilní se systémem Android. Z jakéhokoli důvodu se toto rozhraní API při volání na zařízení od výrobců OEM, jako je Huawei, Vivo, Xiaomi nebo Samsung, vrátí na hodnotu null, takže je pravděpodobné, že tito výrobci OEM mají ve svém softwaru chybu.
• Žádné plány na rámec audio pluginů
  • Vývojář se zeptal Google, zda plánují implementovat rámec audio pluginů, jako je Apple Audio Units, ale odpověď je, že je nepravděpodobné, že se to stane v blízké budoucnosti.

Můžete si přečíst všechny odpovědi od týmu inženýrů Androidu tady. Tým v několika komentářích mluví trochu o Javě, Kotlinu, systému sestavení Androidu, CameraX API a dalších tématech. Existuje také několik komentářů k Wear OS, Android TV a Android Auto, ale Google většinou opakuje jejich stávající práci na těchto platformách a sděluje vývojářům, aby během této doby sledovali další informace "Android mimo telefony“ týden od 10. srpna.