Exkluzivně: 3 nejlepší funkce Androidu 11 nebudou na každém zařízení

Google každoročně vydává novou verzi operačního systému Android. Google vydal první vývojářský náhled pro Android 11 již v únoru, po němž následoval druhý, třetí a čtvrtý vývojářský náhled za posledních několik měsíců. Začátkem tohoto měsíce Google odhalil první Android 11 Beta a podrobně jsme hovořili o nejlepších funkcích, které si uživatelé mohou užít, a které vývojáři implementují. Nyní jsme se však dozvěděli, že tři z nejlepších funkcí v systému Android 11 nebudou dostupné na každém zařízení Android.

Abychom pochopili, jak je to možné, musíme stručně vysvětlit, jak je operační systém Android distribuován od společnosti Google k výrobcům chytrých telefonů. Android je open-source operační systém licencován pod Apache 2.0, což znamená, že kdokoli, od nezávislých vývojářů po velké společnosti, může volně upravovat a distribuovat OS na svých vlastních zařízeních. Většina nových funkcí operačního systému, které Google odhalil pro Android 11, bude součástí projektu Android Open Source Project (AOSP). výrobci zařízení zakládají svůj vlastní software na, ale licence Apache 2.0, jak jsem již zmínil, umožňuje komukoli upravit software, jak vidí vejít se. Aby byla zachována konzistence rozhraní API a chování platformy mezi zařízeními Android, Google sdružuje distribuci mobilních služeb Google (které zahrnují aplikace a rámce, jako je Obchod Google Play a Služby Google Play) s licenčními smlouvami požadujícími, aby zařízení dodržovala pravidla podle "

Program kompatibility Android“ (mimo jiné požadavky). Program Android Compatibility Program se skládá z několika automatických testovacích sad a sady pravidel vyjmenovaných v Androidu Dokument definice kompatibility (CDD).

V CDD Google uvádí softwarové a hardwarové funkce, které výrobci zařízení „MUSÍ“ implementovat, implementovat je pouze „DŮRAZNĚ DOPORUČUJEME“ nebo „NEMĚLI“ implementovat. Pokud je funkce uvedena jako „MUSÍ“ implementovat, musí výrobce zařízení tuto funkci přidat, jinak nebude moci do svých zařízení dodávat aplikace Google. Pokud je funkce uvedena jako „NEMĚLO BY SE“ implementovat, pak výrobce zařízení nemůže tuto funkci přidat nebo nemůže sdružovat aplikace Google. A konečně, pokud je funkce uvedena jako „DŮRAZNĚ DOPORUČENÁ“, pak je na výrobci zařízení, zda tuto funkci chce implementovat či nikoli. CDD je neustále se měnící dokument, a to ještě před jeho každoročním zveřejněním po veřejném vydání nové verze Androidu. Google dokument často aktualizuje, aby odstranil funkce, změnil jazyk, aby byl jasnější, a zmírnil požadavky na základě zpětné vazby od svých partnerů. Jakmile však společnost Google zveřejní CDD pro konkrétní verzi systému Android, budou tyto požadavky pevně stanoveny pro zařízení certifikovaná společností Google s touto verzí operačního systému Android.

Disk CDD pro Android 11 bude zveřejněn až koncem tohoto roku, pravděpodobně začátkem září. Nicméně vývojář @deletescape sdíleli předběžnou kopii dokumentu, která podrobně popisuje změny přicházející do CDD, což nám dává první pohled na to, jak Google utváří Android 11 v celém ekosystému. Naprostá většina z více než 60 změn CDD není pro uživatele příliš zajímavá – popisují jak tvůrci zařízení musí implementovat určitá rozhraní API, deklarovat určité funkce a implementovat určité jádro funkce. Nicméně 3 ze změn CDD nás zaujaly, protože se týkají některých nejzajímavějších funkcí v Androidu 11. Zde je to, co jsme odhalili.

Ovládací prvky zařízení

Device Controls je funkce v systému Android 11, která umožňuje zobrazení ovládacích prvků inteligentní domácí automatizace v nabídce napájení. Můžete zhasnout světla, otevřít garážová vrata, spustit vysavač, změnit teplotu vašeho domova a udělat mnohem víc, aniž byste museli otevírat tucet různých aplikací pro chytrou domácnost. Google přidal rozhraní API, která mohou vývojáři aplikací pro chytrou domácnost použít k zobrazení ovládacích prvků v nabídce napájení. Myslíme si, že je to skvělá funkce konečně přináší váš smartphone do chytré domácnosti. Bohužel neexistuje žádný požadavek, aby jej OEM skutečně implementovali. Pokud si OEM myslí, že funkce je lame, nebo chtějí jít jinou cestou (například povolit pouze smart ovládání domácnosti ze zařízení v jejich vlastním ekosystému), pak mohou jednoduše zakázat podporu pro zařízení Řízení.

Když společnost Google 25. února 2020 poprvé přidala ovládací prvky zařízení do CDD, nařídila jeho zahrnutí přidáním požadavku „MUSÍ“ v části 2.2.3 – Požadavky na software pro kapesní počítače. Dne 20. května 2020 však Google text aktualizoval, aby odstranil navrhované „MUSÍT“. Nová sekce 3.8.16 – Ovládání zařízení popisuje, jak musí být funkce implementována, ale ve skutečnosti nevyžaduje, aby byla implementována na prvním místě! Doufáme, že výrobci OEM tuto šikovnou funkci nezakážou, ale neexistuje způsob, jak zjistit, zda ji deaktivovali, dokud nebudou připraveni odhalit vlastní varianty Androidu postavené na Androidu 11, což se stane až za několik měsíců od Nyní.

Navrhovaná část 3.8.16 (nová) – Ovládací prvky zařízení (aktualizováno 20.5.2020)

3.8.16 Ovládací prvky zařízení

Android obsahuje ControlsProviderService a Control API, která vývojářům umožňují publikovat ovládací prvky zařízení pro rychlý stav a akce pro uživatele.

3.8.16.1 Uživatelská dostupnost ovládacích prvků zařízení

Pokud zařízení implementují ovládací prvky zařízení, pak:

• [C-1-1] MUSÍ nahlásit příznak android.software.controls.feature jako PRAVDIVÝ
• [C-1-2] MUSÍ poskytovat uživatelům prostor s možností přidávat, upravovat, vybírat a ovládat oblíbené položky uživatele z ovládacích prvků registrovaných aplikacemi třetích stran prostřednictvím android.service.controls. ControlsProviderService a android.service.controls. Ovládací rozhraní API.
• [C-1-3] MUSÍ poskytnout přístup k této uživatelské nabídce během tří interakcí ze spouštěče
• [C-1-4] MUSÍ přesně vykreslit v této uživatelské dotaci název a ikonu každé aplikace třetí strany, která poskytuje ovládání prostřednictvím android.service.controls. ControlsProviderService API, stejně jako jakákoli zadaná ikona, stavový text, typ zařízení, název, struktura, zóna, vlastní barva a titulky poskytované android.service.controls. Ovládací rozhraní API

Naopak, pokud implementace zařízení takové ovládací prvky neimplementují, pak je

• [C-2-1] MUSÍ hlásit hodnotu Null pro ControlsProviderService a Control API.

Přečtěte si více

Konverzace v oznámeních

Jednou z největších výhod Androidu ve srovnání s iOS je to, jak první z nich zpracovává upozornění. Tato mezera v použitelnosti se v Androidu 11 ještě prohloubí zavedením konverzací. V systému Android 11 oznámení z aplikací pro zasílání zpráv jsou seskupeny a jsou zobrazeny v samostatné části na panelu oznámení nad většinou ostatních oznámení. To vám umožní rychle zobrazit zprávy a reagovat na ně, aniž byste museli procházet všechna ostatní čekající oznámení. Bohužel tato šikovná změna oznámení nemusí být dostupná na všech zařízeních. Google dává výrobcům OEM možnost vybrat si, zda chtějí „předem seskupovat a zobrazovat upozornění na konverzace oznámení bez konverzace." Výrobci OEM často přizpůsobují panel oznámení, a proto není překvapením, že Google poskytuje OEM výběr zde. Přesto je nešťastné, že se Google nerozhodl prosadit větší konzistenci oznámení v systému Android 11.

Navrhované změny oddílu 3.8.3.1 – Prezentace oznámení (aktualizováno 4. 8. 2020)

Pokud implementace zařízení umožňují aplikacím třetích stran upozorňovat uživatele na významné události:

...

Android R zavádí podporu pro upozornění na konverzaci, což je upozornění, které používá NotificationManager. MessageStyle a poskytuje publikované ID zástupce lidí.

Implementace zařízení jsou:

• [H-SR] DŮRAZNĚ DOPORUČUJEME seskupovat a zobrazovat upozornění na konverzaci před nekonverzací oznámení s výjimkou probíhajících oznámení služby v popředí a důležitost: vysoká oznámení.

Pokud jsou oznámení o konverzaci seskupena do samostatné sekce, implementace zařízení

• [H-1-8] MUSÍ zobrazovat oznámení o konverzaci před oznámeními bez konverzace, s výjimkou probíhajících oznámení služby na popředí a upozornění na důležitost: vysoká.

Implementace zařízení jsou:

• [H-SR] DŮRAZNĚ DOPORUČUJEME poskytnout přístup k následujícím akcím z oznámení konverzací: zobrazit tuto konverzaci jako bublinu, pokud aplikace poskytuje požadovaná data pro bubliny

Implementace AOSP splňuje tyto požadavky s výchozím uživatelským rozhraním systému, nastavením a spouštěčem.

Přečtěte si více

IdentityCredential - Mobilní řidičské průkazy

Konečně jednou z funkcí, ze které jsem nejvíce nadšený, je IdentityCredential API. Jak jsme uvedli v loňském roceIdentityCredential API je navrženo tak, aby umožňovalo aplikacím ukládat do zařízení doklady totožnosti, jako jsou mobilní řidičské průkazy. Několik zemí (a některé státy USA) po celém světě již umožňuje svým občanům ukládat své řidičské průkazy v mobilní aplikaci. Google však pracuje na tom, aby to bylo bezpečnější tím, že má data uložená offline v zabezpečeném prostředí.

Zdrojový kód pro Android 11 obsahuje IdentityCredential API (které vývojáři zavolají, aby ukládali doklady totožnosti do zabezpečené prostředí) a IdentityCredential HAL (která je propojena se zabezpečeným prostředím telefonu), ale výrobci OEM nemusí implementovat je. Když Google 10. ledna 2020 poprvé navrhl zahrnutí IdentityCredential do CDD, uvedl to jako požadavek. Tento požadavek však 18. března 2020 zmírnili a nyní pouze důrazně doporučují, aby výrobci OEM tuto funkci podporovali. Nepřekvapuje nás, že Google tento požadavek zmírnil – přidání změny, která ovlivní prostředí důvěryhodného spouštění, bude vyžadovat úsilí výrobců OEM. Je možné, že výrobci OEM prostě potřebují více času, aby se na tuto změnu připravili. Pro uživatele to však znamená, že neexistuje žádná záruka, že váš konkrétní smartphone se systémem Android 11 bude podporovat bezpečné uložení řidičského průkazu mobilního telefonu v zabezpečeném prostředí telefonu.

Měli bychom poznamenat, že neexistuje žádné technické omezení, které by bránilo širokému přijetí systému IdentityCredential mezi zařízeními Android 11. Jedním z požadavků pro implementaci systému IdentityCredential je, aby zařízení mělo Trusted Execution Prostředí (TEE) nebo vyhrazený zabezpečený procesor, ve kterém „důvěryhodná aplikace“ interaguje s uloženou identitou dokumenty. Od verze Android 7.0 Nougat vyžaduje Google, aby všechna moderní zařízení Android podporovala „izolované prováděcí prostředí“ (za Oddíl 2.2.5 - Bezpečnostní model v CDD). Zařízení s procesory ARM obvykle obsahují ARM TrustZone TEE a Google poskytuje Spolehlivý OS který běží na TrustZone. Přítomnost TEE je dostatečná pro podporu systému IdentityCredential, i když by bylo bezpečnější, kdyby byly přihlašovací údaje uloženy ve vestavěném zabezpečeném CPU (jako např. Secure Processing Unit některých procesorů Qualcomm Snapdragon) nebo diskrétní zabezpečený CPU (jako např Titan M od Googlu nebo Nové bezpečnostní čipy Samsung). Zejména zařízení s diskrétními zabezpečenými CPU mohou být také schopna podporovat funkci „režimu přímého přístupu“ systému IdentityCredential, což uživateli umožní vytáhnout svůj doklad totožnosti, i když v zařízení nezbývá dostatek energie pro spuštění hlavního OS.

Navrhovaný oddíl 9.11.3 (nový) – Identifikační údaje (aktualizováno 18. 3. 2020)

Identity Credential System umožňuje vývojářům aplikací ukládat a získávat dokumenty totožnosti uživatelů.

Implementace zařízení:

• [C-SR] DŮRAZNĚ DOPORUČUJEME implementovat systém identifikačních údajů.

Pokud implementace zařízení implementují Identity Credential System, pak:

• [C-0-1] MUSÍ vrátit hodnotu non-null pro IdentityCredentialStore#getInstance() metoda.
• [C-0-2] MUSÍ implementovat rozhraní API `android.security.identity.*` s kódem komunikujícím s důvěryhodným aplikace běžící buď v Trusted Execution Environment (TEE) nebo ve vyhrazeném zabezpečeném prostředí procesor. Důvěryhodná aplikace musí být implementována tak, aby Trusted Computing Base pro Identity Credential System nezahrnuje operační systém Android.

Přečtěte si více

Google také pracuje na knihovně IdentityCredential Jetpack, která vývojářům usnadní přidávání podpory pro bezpečné ukládání identity. dokumentů na Androidu, ale skutečnou výzvou bude přimět vlády, aby autorizovaly aplikace používající toto rozhraní API k bezpečnému ukládání vládních ID. Podle Engadget, Jižní Korea právě zavedla podporu pro ukládání řidičských průkazů v mobilní aplikaci, takže začínáme pozorovat nárůst přijetí této technologie. Za prvé jsem nadšený, že uvidím, kam to povede, protože to bude znamenat o jednu věc méně, kterou si s sebou vezmu, když půjdu ven.

---

Dokument, který jsme získali, uváděl změny CDD k datu, kdy byly tyto změny provedeny. Poslední změny byly provedeny 10. června 2020, což znamená, že dokument, který máme, je poměrně aktuální. Je možné, že Google by mohl od těchto změn ustoupit a znovu je sjednat se všemi požadavky před veřejným vydáním Androidu 11, ale pochybujeme, že Google najednou udělá CDD více přísné. Tyto změny byly pravděpodobně uvolněny díky zpětné vazbě od výrobců OEM, kteří se budou muset vrátit a implementovat tyto funkce, pokud to již nebylo plánováno. To vyžaduje čas, úsilí a peníze, což by jen ještě více oddálilo vydání Androidu 11 pro zařízení mimo Google. Pokud však Google tyto funkce znovu požaduje, zveřejníme aktualizaci na portálu XDA.