Exkluzív: Az Android 11 legjobb funkciói közül 3 nem lesz elérhető minden eszközön

A Google minden évben kiadja az Android operációs rendszer új verzióját. A Google februárban kiadta az első Android 11 Developer Preview-t, majd az elmúlt néhány hónapban a második, a harmadik és a negyedik fejlesztői előnézetet. A hónap elején a Google bemutatta a az első Android 11 Béta és részletesen beszélt a legjobb szolgáltatásokról, amelyeket a felhasználók élvezhetnek és a fejlesztők megvalósíthatnak. Mostanra azonban megtudtuk, hogy az Android 11 legfontosabb funkciói közül három nem lesz elérhető minden Android-eszközön.

Ahhoz, hogy megértsük, hogyan lehetséges ez, röviden el kell magyaráznunk, hogyan terjeszti az Android operációs rendszert a Google az okostelefonok gyártóihoz. Az Android egy nyílt forráskódú operációs rendszer Az Apache 2.0 alatt licencelt, ami azt jelenti, hogy az indie fejlesztőktől a nagyvállalatokig bárki szabadon módosíthatja és terjesztheti az operációs rendszert a saját eszközén. A legtöbb új operációs rendszer funkció, amelyet a Google bemutatott az Android 11 számára, az Android Open Source Project (AOSP) része lesz az okostelefonon. az eszközgyártók saját szoftvereiket alapozzák meg, de az Apache 2.0 licenc, ahogy korábban említettem, bárki módosíthatja a szoftvert, ahogy látja. elfér. Az API-k és az Android-eszközök közötti platform viselkedésének konzisztenciájának megőrzése érdekében a Google egy csomagba kapcsolja a Google mobilszolgáltatások terjesztését (amely magában foglalja alkalmazások és keretrendszerek, például a Google Play Áruház és a Google Play Szolgáltatások) licencszerződésekkel, amelyek kötelezik az eszközöket a Google szabályainak betartására. "

Android kompatibilitási program" (egyéb követelmények mellett). Az Android kompatibilitási program több automatizált tesztcsomagból és az Androidban felsorolt ​​szabályokból áll. Kompatibilitási definíciós dokumentum (CDD).

A CDD-ben a Google felsorolja azokat a szoftver- és hardverfunkciókat, amelyeket az eszközgyártóknak "KÖTELEZŐEN" megvalósítani, csak "ERŐSEN AJÁNLOTT" megvalósítani, vagy amelyeket "NEM KELL" megvalósítani. Ha egy funkció „KÖTELEZŐ” megvalósításként szerepel, akkor az eszköz gyártójának hozzá kell adnia ezt a funkciót, különben nem szállíthat Google-alkalmazásokat eszközére. Ha egy funkció „NEM KELL” megvalósításként szerepel, akkor az eszköz gyártója nem tudja hozzáadni a funkciót, vagy nem tudja csomagolni a Google-alkalmazásokat. Végül, ha egy funkció „ERŐSEN AJÁNLOTT” jelöléssel szerepel, akkor az eszköz gyártóján múlik, hogy kívánja-e megvalósítani a funkciót. A CDD egy folyamatosan változó dokumentum, még az új Android-verzió nyilvános megjelenését követően minden évben a megjelenése előtt. A Google gyakran frissíti a dokumentumot, hogy eltávolítsa a funkciókat, módosítsa a nyelvet, hogy világosabb legyen, és enyhítse a követelményeket a partnerei visszajelzései alapján. Ha azonban a Google nyilvánosságra hozza a CDD-t egy adott Android-verzióhoz, ezek a követelmények kőbe vésve lesznek az adott Android operációs rendszert futtató, Google által tanúsított eszközökre vonatkozóan.

Az Android 11 CDD csak idén, valószínűleg szeptember elején válik nyilvánossá. Azonban a fejlesztő @deletescape megosztott egy kiadás előtti példányt egy olyan dokumentumról, amely részletezi a CDD-n érkező változásokat, így hamar áttekinthetjük, hogyan alakítja a Google az Android 11-et az ökoszisztémában. A CDD több mint 60 módosításának túlnyomó többsége nem túl érdekes a felhasználók számára – leírják, hogyan az eszközgyártóknak implementálniuk kell bizonyos API-kat, deklarálniuk kell bizonyos funkciókat és implementálniuk kell bizonyos kernelt jellemzők. A CDD módosításai közül 3 azonban felkeltette a figyelmünket, mert az Android 11 legérdekesebb funkcióihoz kapcsolódnak. Íme, amit feltártunk.

Eszközvezérlők

Az eszközvezérlők az Android 11 olyan funkciója, amely lehetővé teszi az intelligens otthon automatizálási vezérlőinek megjelenítését a tápellátás menüben. Lekapcsolhatja a világítást, kinyithatja a garázsajtót, elindíthatja a porszívót, megváltoztathatja otthona hőmérsékletét, és még sok mást tehet anélkül, hogy több tucat különböző intelligens otthoni alkalmazást nyitna meg. A Google olyan API-kat adott hozzá, amelyeket az intelligens otthoni alkalmazások fejlesztői használhatnak a vezérlőelemek megjelenítésére a tápellátás menüben. Szerintünk ez egy ügyes funkció végre behozza okostelefonját az okosotthonba. Sajnos az OEM-ek nem kötelesek ténylegesen megvalósítani. Ha egy OEM úgy véli, hogy a funkció sántít, vagy más utat szeretne választani (például csak a smart otthoni vezérlőket a saját ökoszisztémájukban lévő eszközökről), akkor egyszerűen letilthatják az Eszköz támogatását Vezérlők.

Amikor 2020. február 25-én a Google először hozzáadta az Eszközvezérlőket a CDD-hez, kötelezővé tette annak felvételét a „KÖTELEZŐ” követelmény hozzáadásával a 2.2.3 – Kézi számítógépekre vonatkozó szoftverkövetelmények szakaszban. 2020. május 20-án azonban a Google frissítette a szöveget, hogy eltávolítsa a javasolt „KÖTELEZETT” szót. Az új, 3.8.16. szakasz – Eszközvezérlők felvázolja, hogyan kell a funkciót megvalósítani, de valójában nem követeli meg az első helyen való megvalósítást! Reméljük, hogy az OEM-ek nem fogják letiltani ezt a remek funkciót, de nem tudjuk megtudni, hogy letiltották-e, amíg nem készen állnak arra, hogy bemutassák saját Android 11-re épülő Android-ízeiket, amelyekre csak néhány hónap múlva kerül sor Most.

Javasolt 3.8.16. szakasz (Új) – Eszközvezérlők (Frissítve: 2020.05.20.)

3.8.16 Eszközvezérlők

Az Android tartalmaz ControlsProviderService és Control API-kat, amelyek lehetővé teszik a fejlesztők számára, hogy eszközvezérlőket tegyenek közzé a felhasználók gyors állapota és műveletei érdekében.

3.8.16.1 Az eszköz vezérli a felhasználói igényeket

Ha az eszközök eszközvezérlőket valósítanak meg, akkor:

• [C-1-1] Az android.software.controls.feature jelző IGAZ értékét KELL jelenteni
• [C-1-2] KELL biztosítani a felhasználónak a lehetőséget, hogy hozzáadhassa, szerkeszthesse, kiválaszthassa és kezelhesse a felhasználó kedvenceit a harmadik féltől származó alkalmazások által az android.service.controls oldalon keresztül regisztrált vezérlőkből. ControlsProviderService és az android.service.controls. Control API-k.
• [C-1-3] hozzáférést KELL biztosítani ehhez a felhasználói engedményhez az Indító három interakcióján belül
• [C-1-4] Ebben a felhasználóban pontosan kell megjeleníteni minden olyan harmadik féltől származó alkalmazás nevét és ikonját, amely az android.service.controls-on keresztül vezérlőket biztosít. ControlsProviderService API, valamint az android.service.controls által biztosított bármely megadott ikon, állapotszöveg, eszköztípus, név, szerkezet, zóna, egyéni szín és felirat. Control API

Ezzel szemben, ha az eszközmegvalósítások nem valósítanak meg ilyen vezérlőket, akkor azok

• [C-2-1] A ControlsProviderService és a Control API-k esetében nullát KELL jelenteni.

Olvass tovább

Beszélgetések az Értesítésekben

Az Android egyik legnagyobb előnye az iOS-hez képest, hogy az előbbi hogyan kezeli az értesítéseket. Ez a használhatósági rés még nagyobb lesz az Android 11-ben a „Conversations” bevezetésével. Android 11-ben értesítések üzenetküldő alkalmazásokból vannak csoportosítva, és külön részben jelennek meg az értesítési panelen a többi felett értesítéseket. Ezzel gyorsan megtekintheti és válaszolhat az üzenetekre anélkül, hogy végig kellene görgetnie az összes többi függőben lévő értesítést. Sajnos előfordulhat, hogy az értesítések ezen remek módosítása nem érhető el minden eszközön. A Google lehetőséget ad az OEM-eknek, hogy eldöntsék, szeretnének-e csoportosítani és megjeleníteni a beszélgetési értesítéseket nem beszélgetési értesítések." Az OEM-ek gyakran személyre szabják az értesítési panelt, így nem meglepő, hogy a Google az OEM-eket itt egy választás. Ennek ellenére sajnálatos, hogy a Google nem úgy dönt, hogy nagyobb következetességet kényszerít ki az értesítésekben az Android 11 rendszerben.

Javasolt módosítások a 3.8.3.1. szakaszban – Értesítések bemutatása (Frissítve: 2020.08.04.)

Ha az eszközmegvalósítások lehetővé teszik a harmadik féltől származó alkalmazások számára, hogy értesítsék a felhasználókat a figyelemre méltó eseményekről, akkor:

...

Az Android R támogatja a beszélgetésértesítést, amely a NotificationManager alkalmazást használó értesítés. MessageStyle, és közzétett People Shortcut ID-t biztosít.

Az eszköz megvalósításai a következők:

• [H-SR] ERŐSEN AJÁNLOTT a beszélgetési értesítések csoportosításához és megjelenítéséhez a nem beszélgetés előtt értesítések, kivéve a folyamatban lévő előtér szolgáltatási értesítéseket és fontossága: magas értesítéseket.

Ha a beszélgetési értesítések külön szakaszba vannak csoportosítva, az eszközmegvalósítások

• [H-1-8] KÖTELEZŐ megjeleníteni a beszélgetési értesítéseket a nem beszélgetéssel kapcsolatos értesítések előtt, kivéve a folyamatban lévő előtérben lévő szolgáltatási értesítéseket és a fontosságot: magas szintű értesítéseket.

Az eszköz megvalósításai a következők:

• [H-SR] ERŐSEN AJÁNLOTT, hogy hozzáférést biztosítson a következő műveletekhez a beszélgetési értesítésekből: jelenítse meg ezt a beszélgetést buborékként, ha az alkalmazás biztosítja a buborékokhoz szükséges adatokat

Az AOSP megvalósítás megfelel ezeknek a követelményeknek az alapértelmezett rendszer felhasználói felülettel, beállításokkal és indítóval.

Olvass tovább

IdentityCredential – Mobil vezetői engedélyek

Végezetül, az egyik olyan szolgáltatás, amely miatt a legjobban örülök, az IdentityCredential API. Ahogy tavaly részleteztük, az IdentityCredential API-t úgy tervezték, hogy lehetővé tegye az alkalmazások számára, hogy személyazonosító dokumentumokat, például mobil vezetői engedélyeket tároljanak az eszközön. A világ számos országa (és néhány amerikai állam) már lehetővé teszi állampolgárai számára, hogy vezetői engedélyeiket mobilalkalmazásban tárolják. A Google azonban azon dolgozik, hogy ezt még biztonságosabbá tegye azáltal, hogy az adatokat offline, biztonságos környezetben tárolja.

Az Android 11 forráskódja tartalmazza az IdentityCredential API-t (amelyet a fejlesztők hívnak meg, hogy a személyazonosító dokumentumokat a telefonban tárolják biztonságos környezet) és az IdentityCredential HAL (amely a telefon biztonságos környezetéhez kapcsolódik), de az OEM-eknek nem kell végrehajtani azokat. Amikor 2020. január 10-én a Google először javasolta az IdentityCredential felvételét a CDD-be, azt követelményként sorolta fel. 2020. március 18-án azonban enyhítették ezt a követelményt, és most csak azt javasolják, hogy az OEM-ek támogassák ezt a funkciót. Nem csodálkozunk azon, hogy a Google enyhített ezen a követelményen – a megbízható végrehajtási környezetet érintő változtatások bevezetése az OEM-ek erőfeszítéseit követeli meg. Lehetséges, hogy az OEM-eknek egyszerűen több időre van szükségük, hogy felkészüljenek erre a változásra. A felhasználók számára ez azonban azt jelenti, hogy nincs garancia arra, hogy az adott Android 11 okostelefon támogatja a mobil jogosítványok biztonságos tárolását a telefon biztonságos környezetében.

Meg kell jegyeznünk, hogy semmilyen technikai korlát nem akadályozza meg az IdentityCredential rendszer széles körű elterjedését az Android 11-es eszközök között. Az IdentityCredential rendszer megvalósításának egyik feltétele, hogy az eszköz megbízható végrehajtással rendelkezzen Környezet (TEE) vagy dedikált biztonságos processzor, amelyben egy "megbízható alkalmazás" kölcsönhatásba lép a tárolt identitás dokumentumokat. Az Android 7.0 Nougat óta a Google megköveteli, hogy minden modern Android-eszköz támogassa az „elszigetelt végrehajtási környezetet” (per 2.2.5. szakasz – Biztonsági modell a CDD-n). Az ARM processzorral rendelkező eszközök általában ARM-eket tartalmaznak TrustZone TEE, és a Google biztosítja a Megbízható operációs rendszer amely a TrustZone-on fut. A TEE jelenléte elegendő az IdentityCredential rendszer támogatásához, bár biztonságosabb lenne, ha a hitelesítő adatokat egy beágyazott biztonságos CPU-ban tárolnák (például Egyes Qualcomm Snapdragon processzorok biztonságos feldolgozó egysége) vagy egy különálló biztonságos CPU (például A Google Titan M vagy A Samsung új biztonsági chipjei). Nevezetesen, a különálló, biztonságos CPU-kkal rendelkező eszközök támogathatják az IdentityCredential rendszer „Közvetlen hozzáférési mód” funkcióját is, Ez lehetővé teszi a felhasználó számára, hogy elővegye személyazonosító okmányát még akkor is, ha nincs elég áram az eszközben a fő operációs rendszer indításához.

Javasolt 9.11.3. szakasz (Új) – Személyazonossági hitelesítés (Frissítve: 2020.03.18.)

Az Identity Credential System lehetővé teszi az alkalmazásfejlesztők számára a felhasználói személyazonosító dokumentumok tárolását és lekérését.

Eszköz implementációk:

• A [C-SR] ERŐSEN AJÁNLOTT az Identity Credential System megvalósításához.

Ha az eszközmegvalósítások megvalósítják az Identity Credential System-et, akkor:

• [C-0-1] Nem nullát KELL visszaadnia a IdentityCredentialStore#getInstance() módszer.
• [C-0-2] KÖTELEZŐ megvalósítani az `android.security.identity.*` API-kat megbízható egységgel kommunikáló kóddal. Az alkalmazás megbízható végrehajtási környezetben (TEE) vagy dedikált biztonságosan fut processzor. A megbízható alkalmazást úgy kell megvalósítani, hogy a Megbízható számítástechnikai bázis mert az Identity Credential System nem tartalmazza az Android operációs rendszert.

Olvass tovább

A Google egy IdentityCredential Jetpack könyvtáron is dolgozik, hogy megkönnyítse a fejlesztők számára az identitás biztonságos tárolásának támogatását. dokumentumokat az Androidon, de az igazi kihívás az lesz, hogy a kormányok engedélyezzék az ezt az API-t használó alkalmazásokat a kormányzati azonosítók biztonságos tárolására. Alapján Engadget, Dél-Korea nemrégiben vezette be a jogosítványok mobilalkalmazásban való tárolásának támogatását, így kezdünk emelkedést tapasztalni a technológia elfogadottságában. Én például izgatott vagyok, hogy lássam, hová megy ez, mert eggyel kevesebb dolgot fogok magammal vinni, amikor kimegyek a szabadba.

---

Az általunk megszerzett dokumentum felsorolta a CDD módosításait a módosítások dátumára. A legutóbbi módosítások 2020. június 10-én történtek, ami azt jelenti, hogy a rendelkezésünkre álló dokumentum meglehetősen naprakész. Lehetséges, hogy a Google lemond ezekről a változtatásokról, és újra előírja az összes követelményt az Android 11 nyilvános kiadása előtt, de kételkedünk abban, hogy a Google hirtelen elkészíti a CDD-t. több szigorú. Ezeket a változtatásokat valószínűleg enyhítették az OEM-ek visszajelzései miatt, akiknek vissza kell térniük és be kell vezetniük ezeket a funkciókat, ha még nem tervezték. Ez időt, erőfeszítést és pénzt igényel, ami csak tovább késlelteti az Android 11 megjelenését a nem Google-eszközökön. Ennek ellenére, ha a Google még egyszer megköveteli ezeket a funkciókat, frissítést teszünk közzé az XDA portálon.