Zespół inżynierów Google zajmujący się Androidem zorganizował AMA na Reddicie, aby odpowiedzieć na pytania dotyczące Androida 11. Oto, czego dowiedzieliśmy się o kolejnej wersji systemu operacyjnego Android.
Wczoraj Google udostępniło Androida 11 Beta 2, udostępniając sfinalizowane zestawy SDK, NDK, powierzchnie dostępne dla aplikacji, zachowania platform i ograniczenia dotyczące interfejsów innych niż SDK dla programistów. Dzisiaj Google odpowiada na pytania związane z Androidem 11 w społeczności Reddit /r/AndroidDev po zadaniu pytań w zeszłym tygodniu. Oto podsumowanie wszystkiego, czego dowiedzieliśmy się z Google AMA (Zapytaj mnie o wszystko).
Jedna z najbardziej oczekiwanych funkcji Androida 11 nie będzie dostępna, gdy system operacyjny wychodzi z wersji beta 8 września: Przewijanie zrzutów ekranu. Początkowo planowane do uruchomienia w systemie Android 11, firma Google potwierdziła teraz, że ta funkcja „nie została zastosowana w wersji R”. Android 11 Developer Preview 1 i wszystkie kolejne wydania DP i Beta mają przycisk zastępczy umożliwiający wykonanie przewijanego zrzutu ekranu
ręcznie wykryte za pomocą ukrytego polecenia programisty, ale naciśnięcie przycisku powoduje po prostu wyświetlenie komunikatu tostowego z informacją, że funkcja „nie została zaimplementowana”.Mieliśmy nadzieję, że funkcja trafi do wersji beta lub nawet do wersji stabilnej, ale wygląda na to, że tak się nie stanie.
Ta wiadomość będzie, co zrozumiałe, zdenerwowana dla niektórych użytkowników. Przecież wielu producentów OEM od lat ma tę funkcję w swoim oprogramowaniu, więc czemu Google tak długo zajmuje dodanie jej do telefonów Pixel? Jak wyjaśnił Dan Sandler z zespołu Google ds. interfejsu systemowego, problem polega na tym, że Google chce to zrobić dobrze. Niektóre dostępne implementacje zrzutów ekranu po prostu emulują przewijanie, a następnie łączą wiele zrzutów ekranu w miarę przesuwania się ekranu. Jeśli kiedykolwiek miałeś do czynienia z automatyzacją interfejsu użytkownika na Androidzie, wiesz, że nie zawsze to działa, ponieważ, jak wspomina pan Sandler, aplikacje może używać „standardowego widoku RecyclerView lub zaimplementować własny silnik przewijania przyspieszany przez OpenGL”. Ponieważ Google planuje wdrożyć tę funkcję nie tylko dla smartfonów Pixel, ale dla całego ekosystemu Androida w ramach AOSP, muszą się upewnić to będzie działać Wszystko aplikacje, a nie tylko „jedna lub dwie ręcznie wybrane aplikacje na konkretnym urządzeniu”.
Ponieważ zespół musiał „skupić [swoje] ograniczone zasoby”, zwłaszcza ze względu na związane z tym wyzwania przez Covid-19 zespół zdecydował się umieścić przewijane zrzuty ekranu w tle dla przyszłej wersji Androida.
Nowy wymóg CDD dotyczący informowania użytkowników o ograniczeniach w tle
Nie jest tajemnicą, że wielu producentów OEM Androida, zwłaszcza chińskich, stosuje agresywne ograniczenia dotyczące aplikacji działających w tle. Niektórzy programiści byli tak sfrustrowani wyłączaniem się ich aplikacji w tle, że połączyli siły, aby stworzyć witrynę internetową o nazwie „Nie zabijaj mojej aplikacji", aby uszeregować producentów OEM na podstawie tego, jak słabo radzą sobie z procesami aplikacji w tle. Ci sami programiści nawet niedawno stworzył punkt odniesienia dzięki czemu użytkownicy mogą sprawdzić, jak agresywnie ich urządzenie zabija aplikacje w tle. Powód, dla którego wielu producentów OEM uwielbia zabijać procesy aplikacji w tle, jest skomplikowany, ale myślę, że najlepiej wyjaśniony jest w tym komentarzu Redditora /u/prawdopodobnie wątpliwe. W komentarzu zarysowano skomplikowany status rozwoju aplikacji na Androida w Chinach oraz sytuację chińskich firm technologicznych są zaangażowane w dalsze komplikowanie spraw i jak brak usług Google wpływa na to, co się dzieje bałagan.
Niezależnie od tego wielu twórców aplikacji jest, co zrozumiałe, sfrustrowanych tymi zmianami w zachowaniu platformy Android, co spowodowało, że programiści przesunęli komentarz pytając Google, co z tym robią na szczyt Reddit AMA. Oto odpowiedź Google:
Z tej odpowiedzi można wyciągnąć kilka rzeczy. Po pierwsze, Google chce, aby producenci OEM zapewniali użytkownikom większą przejrzystość w zakresie stosowanych przez nich ograniczeń aplikacji działających w tle. Sprawdziłem (nieopublikowany) dokument definicji zgodności Androida 11 (CDD) i znalazłem następujący proponowany dodatek do sekcji 3.5 – Zgodność behawioralna API:
Jeśli implementacje urządzeń wdrażają zastrzeżony mechanizm ograniczania aplikacji, a mechanizm ten jest bardziej restrykcyjny niż „Rzadki” segment gotowości w AOSP, to:
[C-1-5] MUSI informować użytkowników, jeśli ograniczenia aplikacji są stosowane automatycznie. (NOWOŚĆ) Taka informacja MUSI zostać przekazana wcześniej niż 24 godziny przed zastosowaniem takich ograniczeń.
(Uwaga) Wymuszone zatrzymanie jest uważane za bardziej restrykcyjne niż „Rzadkie” i MUSI spełniać wszystkie wymagania określone w 3.5.1, w tym nowe 3.5.1/C-1-5
Zasadniczo Google nie jest w stanie powstrzymać producentów OEM od wdrażania własnych, restrykcyjnych funkcji zabijania aplikacji. Wymagają jedynie, aby producenci OEM informowali użytkowników, czy ograniczenia ich aplikacji są stosowane automatycznie. Producent OEM może wyświetlić okno dialogowe informujące, że zamierza zatrzymać działanie aplikacji działających w tle zużywających baterię tle, a użytkownik może wyrazić zgodę, nie zdając sobie sprawy, że aplikacje, które naprawdę chce uruchamiać w tle, również tam są dotknięty! Google nakłada na programistów obowiązek radzenia sobie z przypadkami, gdy ich aplikacja nieoczekiwanie przestaje działać w tle. Rzeczywiście, komentarz na Reddicie dalej podkreśla nowe „powody zakończenia procesu aplikacji" API, które może poinformować programistów, czy ich aplikacja została zabita przez użytkownika, system operacyjny, czy też po prostu uległa awarii.
Z drugiej strony Google w końcu rozprawia się z nieuczciwymi praktykami producentów OEM, pozwalającymi niektórym uprzywilejowanym aplikacjom na ominięcie ograniczeń aplikacji działających w tle. Ten średni post autorstwa programisty Tymoteusz Asiimwe szczegółowo omawia aplikacje takie jak WhatsApp, Facebook i inne aplikacje, które są automatycznie zwolnione z surowych ograniczeń w tle niektórych programów OEM. Google twierdzi, że „wymaga, aby producenci urządzeń nie tworzyli list dozwolonych dla najpopularniejszych aplikacji”. Nie wiemy, jak to będzie egzekwowane, ale dobrze wiedzieć, że producenci OEM będą w końcu zmuszeni traktować zewnętrznych programistów na równych zasadach – niezależnie od tego, jak duże czy małe są ich aplikacje Czy.
Na koniec Google wspomina również, że w systemie Android 11 „dodano dodatkowe środki zapobiegające nadużyciom wynikającym z nieprawidłowego działania aplikacji”, dzięki czemu producenci OEM nie są tak zachęcani do agresywnego zabijania procesów w tle. Firma nie wyjaśniła jednak, na czym polegają te „dodatkowe środki”.
Ulepszone kopie zapasowe z urządzenia na urządzenie
W zeszłym miesiącu zauważyliśmy zmianę w dokumentacji Androida 11, która polegała na tym, że zasugerowano obsługę lepszych lokalnych kopii zapasowych danych. W systemie Android 11 system zignoruje atrybutallowBackup Manifest w przypadku każdej aplikacji przeznaczonej dla poziomu interfejsu API 30, gdy użytkownik zainicjuje migrację plików aplikacji „z urządzenia na urządzenie”. Googler Eliot Stock twierdzi, że ta funkcja ma „znacznie ułatwić producentom telefonów tworzenie narzędzi do migracji z urządzenia na urządzenie”, takich jak „doskonały produkt Samsung Smart Switch” pomóc „zapewnić bardziej niezawodne przesyłanie aplikacji między urządzeniami z perspektywy użytkownika”. Niestety nie dotyczy to kopii zapasowych w chmurze, ponieważ Google chce „dawać twórcom oprogramowania kontrolę nad tym, co dzieje się z danymi ich aplikacji.” W związku z tym system Android 11 będzie nadal szanował atrybut zezwolenie na kopię zapasową w przypadku wszelkich kopii zapasowych i przywracania w chmurze, na przykład za pośrednictwem wbudowanego Dysku Google usługi Google Play kopia zapasowa. Na koniec Google przyznaje, że górny limit wielkości kopii zapasowych wynoszący 25 MB na aplikację może być niewystarczający dla niektórych programistów, dlatego szukają sposobów rozwiązania tego problemu. Lokalne kopie zapasowe na komputerze nie są jednak brane pod uwagę i Google podtrzymuje swój plan wycofaj kopię zapasową adb w przyszłej wersji Androida.
Zachęcamy programistów do wdrażania bezproblemowych metod migracji danych. The nowa biblioteka Block Store, która jest częścią Biblioteki usług tożsamości Google, ma za zadanie ułatwić logowanie się do przywróconych aplikacji z chmury na nowych urządzeniach, ale to programiści decydują, czy chcą to wdrożyć biblioteka.
Większe prędkości uruchamiania aplikacji dzięki procesowi odczytu z wyprzedzeniem we/wy (IORap)
Google zawsze eksperymentuje ze sposobami poprawy wydajności w systemie Android. Jedna z mało znanych funkcji, które dodali w Androidzie 10, nosi nazwę Unspecialized App Process Pool (USAP). Ta funkcja eliminuje rozwidlanie Zygote podczas procesu uruchamiania aplikacji, oszczędzając około 5 ms średniej szybkości uruchamiania aplikacji na urządzeniu Pixel 2. Funkcja jest obecnie domyślnie wyłączone w AOSP, a Google wyjaśnia, że wykorzystanie dodatkowej pamięci nadal wymaga przetestowania. Co jednak bardziej interesujące, w systemie Android 11 pojawi się nowa funkcja o nazwie I/O Read Ahead Process (IORap). Według Google’a, ta funkcja zapewni „ponad 5% szybsze zimne uruchamianie, a przypadki bohaterów będą szybsze o 20%”. Ta cecha „pobierze wstępnie artefakty aplikacji (takie jak kod i zasoby) podczas procesu uruchamiania”, aby przyspieszyć uruchamianie aplikacji prędkości.
Google „wprowadził także ulepszenia w profilach używanych do optymalizacji ścieżki klasy rozruchowej i obrazu systemu” co poprawi wydajność aplikacji i zmniejszy koszty pamięci i przechowywania związane z systemem artefakty. Zmiany te przyniosą korzyści głównie urządzeniom z większą ilością pamięci RAM, chociaż Google nie podał, jaka jest granica, w przypadku której zobaczymy najwięcej korzyści.
Zmiany w ograniczonej pamięci masowej w systemie Android 11 — dlaczego dostęp do /Pobieranie jest ograniczony?
Aplikacje przeznaczone dla Androida 11 i korzystające z intencji ACTION_OPEN_DOCUMENT_TREE do żądania dostępu do określonych katalogów na urządzeniu zewnętrznym Storage nie będzie już mógł prosić użytkowników o dostęp do katalogu głównego pamięci zewnętrznej (/data/media/{user}), plik Download katalog (/data/media{user}/Download) lub dowolny z katalogów danych specyficznych dla aplikacji w pamięci zewnętrznej (/Android/data lub /Android/obb). Dlaczego dostęp do katalogu pobierania jest ograniczony? Według Google Roxanny Aliabadi, dzieje się tak dlatego, że folder pobierania „jest najbardziej narażony na ryzyko przechowywania prywatnych informacji”. Na przykład użytkownicy, którzy pobierają swój podatek zwroty lub wyciągi bankowe nie powinny martwić się możliwością nadużywania przez aplikacje ciągłego dostępu do odczytu informator. Google twierdzi, że selektor dokumentów będzie miał „zaktualizowany tekst… wskazujący, że Android ograniczył niektóre foldery do wybrania.” Miejmy nadzieję, że zmniejszy to zamieszanie związane z tym, dlaczego nie mogą przyznawać aplikacjom dostępu do niektórych katalogów nie więcej.
Aby uzyskać więcej informacji na temat nadchodzących zmian w zasadach dotyczących ograniczonego przechowywania i odtwarzania, zapoznaj się z tym artykułem.
Różne tematy
-
Stanowisko Google w sprawie rootowania/modowania
- Jeff Bailey z zespołu AOSP firmy Google podtrzymuje stanowisko firmy dotyczące wspierania wyboru. Google „będzie w dalszym ciągu zapewniać możliwość modyfikowania/rootowania urządzeń z linii Pixel”, ale będzie także „wspierać decyzje producentów OEM, aby nie pozwalali swoim urządzeniom zostać zrootowany.” Co więcej, Google daje twórcom oprogramowania możliwość „niepozwolenia na uruchamianie ich oprogramowania na urządzeniach zrootowanych” w nawiązaniu do niedawnych zmian w wykrywanie manipulacji oprogramowaniem API SafetyNet Attestation.
-
Co się stało z opcją „otwórz i ustaw na domyślne”?
- Zrobiono Androida 10 ustawienie aplikacji jako domyślnej procedury obsługi jest odrobinę denerwujące dla konkretnych linków, co według Google miało na celu ochronę użytkowników przed „aplikacjami wykorzystującymi exploity”. Google wycofał się na temat tej zmiany po ponownym przemyśleniu jej, wprowadzając „szereg zmian za kulisami”, aby chronić użytkownika.
-
Używasz interfejsu API grafiki Vulkan do renderowania interfejsu użytkownika?
- Google ostatecznie planuje użyć Vulkan Graphics API do renderowania interfejsu użytkownika, co przyniesie pewną poprawę wydajności. To jest nadal podlega ocenie, ale firma nie podzieliła się żadnymi szczegółami.
-
Brak usługi CallScreeningService na wielu urządzeniach
- Aplikacje na Androida mogą implementować Interfejs API usługi CallScreeningService przechwytywać nowe połączenia przychodzące i wychodzące, umożliwiając identyfikację osoby dzwoniącej i przyjęcie lub odrzucenie połączenia. Chociaż jest to oficjalnie udokumentowany interfejs API, według programisty /u/ najwyraźniej wielu producentów OEM nie wdraża go prawidłowo_zeromod_. Google potwierdza że ten interfejs API jest zatwierdzony przez pakiet testów zgodności (CTS), zautomatyzowany zestaw testów, który muszą przejść wszystkie urządzenia, aby można je było uznać za zgodne z systemem Android. Z jakiegoś powodu ten interfejs API zwraca wartość null, gdy jest wywoływany na urządzeniach producentów OEM, takich jak Huawei, Vivo, Xiaomi lub Samsung, więc prawdopodobnie ci producenci OEM mają błąd w swoim oprogramowaniu.
-
Brak planów dotyczących struktury wtyczek audio
- Programista zapytał Google, czy planuje wdrożyć platformę wtyczek audio, taką jak Apple Audio Units, ale odpowiedź jest to, że jest mało prawdopodobne, że stanie się to w najbliższej przyszłości.
Wszystkie odpowiedzi możesz przeczytać od zespołu inżynierów Androida Tutaj. W kilku komentarzach zespół omawia trochę Javę, Kotlin, system kompilacji Androida, API CameraX i inne tematy. Istnieje również kilka komentarzy na temat Wear OS, Android TV i Android Auto, ale Google w większości je powtarza ich dotychczasowe prace na tych platformach i zaleca programistom śledzenie dalszych informacji w trakcie aktualizacji "Android poza telefonami„Tydzień rozpoczynający się 10 sierpnia.