Wyłącznie: 3 z najlepszych funkcji Androida 11 nie będą dostępne na każdym urządzeniu

Co roku Google wypuszcza nową wersję systemu operacyjnego Android. Google udostępniło pierwszą wersję deweloperską Androida 11 w lutym, a następnie drugą, trzecią i czwartą wersję deweloperską w ciągu ostatnich kilku miesięcy. Na początku tego miesiąca Google zaprezentowało pierwsza wersja beta Androida 11 i szczegółowo omówiliśmy najlepsze funkcje, z których mogą korzystać użytkownicy i które programiści mogą wdrożyć. Jednak teraz dowiedzieliśmy się, że trzy z najważniejszych funkcji Androida 11 nie będą dostępne na każdym urządzeniu z Androidem.

Aby zrozumieć, jak to możliwe, musimy pokrótce wyjaśnić, w jaki sposób system operacyjny Android jest dystrybuowany przez Google wśród producentów smartfonów. Android jest system operacyjny typu open source licencjonowany w ramach Apache 2.0, co oznacza, że ​​każdy, od niezależnych programistów po duże firmy, może swobodnie modyfikować i rozpowszechniać system operacyjny na swoich własnych urządzeniach. Większość nowych funkcji systemu operacyjnego, które Google zaprezentował dla Androida 11, będzie częścią projektu Android Open Source Project (AOSP), którego dotyczy smartfon twórcy urządzeń opierają się na własnym oprogramowaniu, jednak licencja Apache 2.0, jak wspomniałem wcześniej, pozwala każdemu modyfikować oprogramowanie według własnego uznania pasować. Aby zachować spójność interfejsów API i zachowania platform na urządzeniach z Androidem, Google łączy w sobie dystrybucję usług mobilnych Google (w tym aplikacje i platformy, takie jak Sklep Google Play i Usługi Google Play) z umowami licencyjnymi nakładającymi na urządzenia obowiązek przestrzegania zasad określonych w Google Play "

Program zgodności z Androidem” (wśród innych wymagań). Program zgodności systemu Android składa się z wielu automatycznych zestawów testów i zestawu reguł wymienionych w systemie Android Dokument definicji kompatybilności (CDD).

W CDD Google wymienia funkcje oprogramowania i sprzętu, które producenci urządzeń „MUSZĄ” wdrożyć, których wdrożenie jest jedynie „Zdecydowanie ZALECANE” lub których „NIE POWINNO się” wdrażać. Jeśli funkcja jest wymieniona jako „MUSISZ” zostać wdrożona, producent urządzenia musi ją dodać, w przeciwnym razie nie będzie mógł dostarczać aplikacji Google na swoje urządzenia. Jeśli dana funkcja jest wymieniona jako „NIE NALEŻY” wdrażać, producent urządzenia nie może dodać tej funkcji lub nie może łączyć aplikacji Google. Wreszcie, jeśli dana funkcja jest wymieniona jako „Zdecydowanie ZALECANY”, to od producenta urządzenia zależy, czy chce ją wdrożyć. CDD jest dokumentem stale zmieniającym się, nawet przed publikacją co roku po publicznym wydaniu nowej wersji Androida. Google często aktualizuje dokument, aby usunąć funkcje, zmienić język na bardziej przejrzysty i złagodzić wymagania w oparciu o opinie swoich partnerów. Jednak gdy Google opublikuje CDD dla konkretnej wersji Androida, wymagania te zostaną niezmiennie ustalone dla urządzeń z certyfikatem Google, na których działa ta wersja systemu operacyjnego Android.

CDD Androida 11 zostanie upublicznione dopiero pod koniec tego roku, prawdopodobnie na początku września. Jednak programista @usuń krajobraz udostępnił przedpremierową kopię dokumentu zawierającego szczegółowe informacje na temat zmian wprowadzanych do CDD, co dało nam wgląd w to, jak Google kształtuje Androida 11 w całym ekosystemie. Zdecydowana większość z ponad 60 zmian w CDD nie jest zbyt interesująca dla użytkowników — opisują, jak to zrobić twórcy urządzeń muszą wdrożyć określone interfejsy API, zadeklarować pewne funkcje i wdrożyć określone jądro cechy. Naszą uwagę przykuły jednak 3 zmiany w CDD, ponieważ dotyczą one niektórych z najciekawszych funkcji Androida 11. Oto, co odkryliśmy.

Sterowanie urządzeniami

Sterowanie urządzeniami to funkcja w systemie Android 11, która umożliwia wyświetlanie elementów sterujących inteligentną automatyką domową w menu zasilania. Możesz wyłączyć światła, otworzyć bramę garażową, uruchomić odkurzacz, zmienić temperaturę w domu i zrobić wiele więcej bez otwierania kilkunastu różnych aplikacji inteligentnego domu. Google dodało interfejsy API, z których mogą korzystać twórcy inteligentnych aplikacji domowych, aby wyświetlić elementy sterujące w menu zasilania. Uważamy, że jest to fajna funkcja wreszcie wprowadza Twój smartfon do inteligentnego domu. Niestety, nie ma wymogu, aby producenci OEM faktycznie go wdrażali. Jeśli producent OEM uważa, że ​​ta funkcja jest kiepska lub chce pójść inną drogą (na przykład pozwolić tylko na smart sterowanie domem z urządzeń we własnym ekosystemie), wówczas mogą po prostu wyłączyć obsługę urządzenia Sterownica.

Kiedy 25 lutego 2020 r. firma Google po raz pierwszy dodała kontrolę urządzeń do CDD, nakazała jej włączenie, dodając wymaganie „MUSI” w sekcji 2.2.3 – Wymagania dotyczące oprogramowania przenośnego. Jednak 20 maja 2020 r. Google zaktualizowało tekst, usuwając proponowane „MUSI”. Nowa sekcja 3.8.16 – Kontrola urządzeń opisuje, w jaki sposób należy zaimplementować tę funkcję, ale w rzeczywistości nie wymaga jej wdrożenia! Mamy nadzieję, że producenci OEM nie wyłączą tej fajnej funkcji, ale nie możemy się dowiedzieć, czy ją wyłączyli, dopóki tego nie zrobią gotowi zaprezentować własne wersje Androida zbudowanego na systemie Android 11, co nastąpi dopiero za kilka miesięcy Teraz.

Proponowana sekcja 3.8.16 (Nowa) – Sterowanie urządzeniami (aktualizacja 20.05.2020 r.)

3.8.16 Sterowanie urządzeniem

Android zawiera interfejsy API ControlsProviderService i Control, które umożliwiają programistom publikowanie elementów sterujących urządzeniami w celu uzyskania szybkiego statusu i działania dla użytkowników.

3.8.16.1 Urządzenie kontroluje dostępność użytkownika

Jeśli urządzenia wdrażają Kontrolę urządzeń, to:

• [C-1-1] MUSI zgłosić, że flaga android.software.controls.feature ma wartość PRAWDA
• [C-1-2] MUSI zapewniać użytkownikowi możliwość dodawania, edytowania, wybierania i obsługi ulubionych użytkownika za pomocą elementów sterujących zarejestrowanych przez aplikacje innych firm za pośrednictwem android.service.controls. ControlsProviderService i android.service.controls. Kontroluj interfejsy API.
• [C-1-3] MUSI zapewnić dostęp do tego użytkownika w ciągu trzech interakcji z Launcherem
• [C-1-4] MUSI dokładnie renderować w tej afordancji użytkownika nazwę i ikonę każdej aplikacji innej firmy, która zapewnia kontrolę za pośrednictwem android.service.controls. ControlsProviderService API, a także dowolną określoną ikonę, tekst stanu, typ urządzenia, nazwę, strukturę, strefę, niestandardowy kolor i podtytuł dostarczone przez android.service.controls. Kontroluj API

I odwrotnie, jeśli implementacje urządzeń nie implementują takich kontroli, to one

• [C-2-1] MUSI zgłosić wartość Null dla usługi ControlsProviderService i interfejsów API kontroli.

Czytaj więcej

Rozmowy w powiadomieniach

Jedną z największych zalet Androida w porównaniu z iOS jest sposób, w jaki ten pierwszy obsługuje powiadomienia. Ta luka w użyteczności stanie się jeszcze większa w Androidzie 11 wraz z wprowadzeniem „Rozmów”. W Androidzie 11 powiadomienia z aplikacji do przesyłania wiadomości są pogrupowane i wyświetlane w osobnej sekcji w panelu powiadomień nad większością pozostałych powiadomienia. Dzięki temu możesz szybko przeglądać wiadomości i odpowiadać na nie bez konieczności przewijania wszystkich innych oczekujących powiadomień. Niestety, ta sprytna zmiana w powiadomieniach może nie być dostępna na wszystkich urządzeniach. Google daje producentom OEM możliwość wyboru, czy chcą „grupować i wyświetlać powiadomienia o rozmowach z wyprzedzeniem”. powiadomienia niezwiązane z rozmowami.” Producenci OEM często dostosowują panel powiadomień, nic więc dziwnego, że Google udostępnia producentom OEM tutaj wybór. Mimo wszystko szkoda, że ​​Google nie zdecydowało się na wymuszenie większej spójności powiadomień w Androidzie 11.

Proponowane zmiany w punkcie 3.8.3.1 – Prezentacja powiadomień (aktualizacja 4.08.2020)

Jeśli implementacje urządzeń umożliwiają aplikacjom innych firm powiadamianie użytkowników o ważnych wydarzeniach, to:

...

Android R wprowadza obsługę powiadamiania o konwersacjach, czyli powiadomieniu wykorzystującym NotificationManager. MessageStyle i udostępnia opublikowany identyfikator skrótu osób.

Implementacje urządzeń to:

• [H-SR] ZDECYDOWANIE ZALECA SIĘ grupowanie i wyświetlanie powiadomień o rozmowach przed konwersacjami powiadomienia z wyjątkiem bieżących powiadomień o usługach na pierwszym planie i ich znaczenie: wysokie powiadomienia.

Jeśli powiadomienia o konwersacjach są zgrupowane w osobnej sekcji, implementacje urządzeń

• [H-1-8] MUSI wyświetlać powiadomienia o konwersacjach przed powiadomieniami niezwiązanymi z konwersacją, z wyjątkiem bieżących powiadomień o usługach na pierwszym planie i ważności: powiadomienia o wysokim poziomie.

Implementacje urządzeń to:

• [H-SR] ZDECYDOWANIE ZALECA SIĘ zapewnienie dostępu do następujących akcji z powiadomień o konwersacjach: wyświetl tę rozmowę jako dymek, jeśli aplikacja dostarcza wymagane dane dla dymków

Implementacja AOSP spełnia te wymagania z domyślnym interfejsem użytkownika systemu, ustawieniami i programem uruchamiającym.

Czytaj więcej

IdentityCredential — mobilne prawa jazdy

Na koniec, jedną z funkcji, która mnie najbardziej ekscytuje, jest interfejs API IdentityCredential. Jak pisaliśmy w zeszłym roku, interfejs API IdentityCredential umożliwia aplikacjom przechowywanie na urządzeniu dokumentów tożsamości, takich jak mobilne prawa jazdy. Kilka krajów (i niektóre stany USA) na całym świecie umożliwia już swoim obywatelom przechowywanie praw jazdy w aplikacji mobilnej. Google pracuje jednak nad zwiększeniem bezpieczeństwa, przechowując dane w trybie offline w bezpiecznym środowisku.

Kod źródłowy Androida 11 zawiera interfejs API IdentityCredential (który programiści będą wywoływać w celu przechowywania dokumentów tożsamości w pamięci telefonu bezpieczne środowisko) i IdentityCredential HAL (który łączy się z bezpiecznym środowiskiem telefonu), ale producenci OEM nie są zobowiązani do je wdrożyć. Kiedy 10 stycznia 2020 r. Google po raz pierwszy zaproponował włączenie IdentityCredential do CDD, wymienił to jako wymaganie. Jednak 18 marca 2020 r. złagodzili ten wymóg i obecnie jedynie zdecydowanie zalecają producentom OEM obsługę tej funkcji. Nie jesteśmy zaskoczeni, że Google złagodził ten wymóg – wdrożenie zmiany wpływającej na zaufane środowisko wykonawcze będzie wymagało wysiłku ze strony producentów OEM. Możliwe, że producenci OEM po prostu potrzebują więcej czasu, aby przygotować się na tę zmianę. Jednak dla użytkowników oznacza to, że nie ma gwarancji, że Twój konkretny smartfon z Androidem 11 będzie obsługiwał bezpieczne przechowywanie mobilnego prawa jazdy w bezpiecznym środowisku telefonu.

Należy zauważyć, że nie ma ograniczeń technicznych uniemożliwiających powszechne przyjęcie systemu IdentityCredential na urządzeniach z Androidem 11. Jednym z wymagań wdrożenia systemu IdentityCredential jest to, że urządzenie posiada Trusted Execution Środowisko (TEE) lub dedykowany bezpieczny procesor, w którym „zaufana aplikacja” wchodzi w interakcję z przechowywaną tożsamością dokumenty. Od wersji Androida 7.0 Nougat firma Google wymaga, aby wszystkie nowoczesne urządzenia z Androidem obsługiwały „izolowane środowisko wykonawcze” (według Sekcja 2.2.5 – Model zabezpieczeń w CDD). Urządzenia z procesorami ARM zazwyczaj są wyposażone w procesory ARM Strefa zaufania TEE, a Google udostępnia Zaufany system operacyjny który działa na TrustZone. Obecność TEE wystarczy do obsługi systemu IdentityCredential, chociaż byłoby bezpieczniejsze, gdyby poświadczenia były przechowywane we wbudowanym bezpiecznym procesorze (np. Bezpieczna jednostka przetwarzająca niektórych procesorów Qualcomm Snapdragon) lub dyskretny bezpieczny procesor (taki jak in Google Titan M Lub Nowe chipy zabezpieczające Samsunga). Warto zauważyć, że urządzenia z oddzielnymi bezpiecznymi procesorami mogą również obsługiwać funkcję „trybu bezpośredniego dostępu” systemu IdentityCredential, co pozwoli użytkownikowi wyciągnąć dokument tożsamości nawet wtedy, gdy w urządzeniu nie ma wystarczającej ilości energii, aby uruchomić główny system operacyjny.

Proponowana sekcja 9.11.3 (Nowa) – Poświadczenie tożsamości (aktualizacja 18.03.2020 r.)

System poświadczeń tożsamości umożliwia twórcom aplikacji przechowywanie i pobieranie dokumentów tożsamości użytkownika.

Implementacje urządzeń:

• ZDECYDOWANIE ZALECA SIĘ [C-SR] wdrożenie Systemu Poświadczeń Tożsamości.

Jeśli implementacje urządzeń wdrażają system poświadczeń tożsamości, to:

• [C-0-1] MUSI zwrócić wartość różną od null dla IdentityCredentialStore#getInstance() metoda.
• [C-0-2] MUSI implementować interfejsy API `android.security.identity.*` z kodem komunikującym się z zaufanym aplikacja działająca w zaufanym środowisku wykonawczym (TEE) lub na dedykowanym bezpiecznym serwerze edytor. Zaufana aplikacja musi zostać zaimplementowana w taki sposób, aby Zaufana baza obliczeniowa dla Systemu Poświadczeń Tożsamości nie obejmuje systemu operacyjnego Android.

Czytaj więcej

Google pracuje także nad biblioteką IdentityCredential Jetpack, aby ułatwić programistom dodawanie obsługi bezpiecznego przechowywania tożsamości dokumentów na Androidzie, ale prawdziwym wyzwaniem będzie nakłonienie rządów do autoryzacji aplikacji korzystających z tego interfejsu API do bezpiecznego przechowywania identyfikatorów rządowych. Według Engadgetw Korei Południowej właśnie wdrożono obsługę przechowywania praw jazdy w aplikacji mobilnej, więc zaczynamy zauważać wzrost akceptacji tej technologii. Ja na przykład nie mogę się doczekać, dokąd to wszystko zmierza, bo dzięki temu będę mieć o jedną rzecz mniej do noszenia, gdy wyjdę na zewnątrz.

---

Dokument, który uzyskaliśmy, zawierał listę zmian w CDD według daty ich wprowadzenia. Ostatnie zmiany zostały wprowadzone 10 czerwca 2020 roku, co oznacza, że ​​dokument, którym dysponujemy, jest w miarę aktualny. Możliwe, że Google odstąpi od tych zmian i ponownie postawi wszystkie wymagania przed publiczną premierą Androida 11, ale wątpimy, czy Google nagle wprowadzi CDD więcej przekonywający. Zmiany te prawdopodobnie zostały złagodzone ze względu na opinie producentów OEM, którzy będą musieli wrócić i wdrożyć te funkcje, jeśli nie było to jeszcze zaplanowane. Wymaga to czasu, wysiłku i pieniędzy, co jeszcze bardziej opóźniłoby wydanie Androida 11 na urządzenia inne niż Google. Jeśli jednak Google ponownie sprawi, że te funkcje będą wymagane, opublikujemy aktualizację w portalu XDA.