Druga wersja beta Androida 17

Dziś udostępniamy drugą wersję beta Androida 17. Kontynuujemy prace nad platformą, która stawia na pierwszym miejscu prywatność, bezpieczeństwo i wydajność. Ta aktualizacja wprowadza szereg nowych funkcji, w tym interfejs EyeDropper API i narzędzie do wyboru kontaktów z zachowaniem prywatności. Dodajemy też zaawansowane określanie odległości, interfejsy API do przekazywania między urządzeniami i inne funkcje.

Ta wersja kontynuuje zmianę w częstotliwości publikowania. Po corocznej wersji głównej pakietu SDK w II kwartale opublikujemy mniejszą aktualizację pakietu SDK.

Wygoda użytkowników i interfejs systemu

Dymki

Dymki to funkcja trybu okienkowego, która oferuje nowy interfejs użytkownika w postaci pływających okienek, niezależny od interfejsu API dymków wiadomości. Użytkownicy mogą utworzyć dymek aplikacji na telefonie, urządzeniu składanym lub tablecie, przytrzymując ikonę aplikacji w menu z aplikacjami. Na dużych ekranach na pasku aplikacji znajduje się pasek dymków, na którym użytkownicy mogą organizować dymki, przełączać się między nimi oraz przenosić je do i z punktów zakotwiczenia na ekranie.

Aby mieć pewność, że aplikacje działają prawidłowo jako dymki, postępuj zgodnie z wytycznymi dotyczącymi obsługi trybu wielu okien.

Dymki nie są jeszcze w pełni włączone w wersji beta 2. Szukaj ich w przyszłej wersji Androida 17.

EyeDropper API

Nowy interfejs EyeDropper API na poziomie systemu umożliwia aplikacji pobieranie koloru z dowolnego piksela na wyświetlaczu bez konieczności uzyskiwania uprawnień do przechwytywania ekranu.

val eyeDropperLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) {
  result -> if (result.resultCode == Activity.RESULT_OK) {
    val color = result.data?.getIntExtra(Intent.EXTRA_COLOR, Color.BLACK)
    // Use the picked color in your app
  }
}

fun launchColorPicker() {
  val intent = Intent(Intent.ACTION_OPEN_EYE_DROPPER)
  eyeDropperLauncher.launch(intent)
}

Selektor kontaktów

Nowy selektor kontaktów na poziomie systemu, uruchamiany za pomocą intencji ACTION_PICK_CONTACTS, przyznaje tymczasowy dostęp do odczytu tylko tych pól danych, o które prosi użytkownik. Zmniejsza to potrzebę przyznawania szerokich uprawnień READ_CONTACTS. Umożliwia też wybieranie treści z profilu osobistego lub służbowego na urządzeniu.

val contactPicker = rememberLauncherForActivityResult(StartActivityForResult()) {
    if (it.resultCode == RESULT_OK) {
        val uri = it.data?.data ?: return@rememberLauncherForActivityResult
        // Handle result logic
        processContactPickerResults(uri)
    }
}

val dataFields = arrayListOf(Email.CONTENT_ITEM_TYPE, Phone.CONTENT_ITEM_TYPE)
val intent = Intent(ACTION_PICK_CONTACTS).apply {
    putStringArrayListExtra(EXTRA_PICK_CONTACTS_REQUESTED_DATA_FIELDS, dataFields)
    putExtra(EXTRA_ALLOW_MULTIPLE, true)
    putExtra(EXTRA_PICK_CONTACTS_SELECTION_LIMIT, 5)
}

contactPicker.launch(intent)

Łatwiejsze przechwytywanie wskaźnika dzięki zgodności z touchpadami

Wcześniej, gdy aplikacja przechwytywała wskaźnik, touchpady zgłaszały zdarzenia w sposób bardzo różny od myszy. Zamiast względnych ruchów, które byłyby zgłaszane przez mysz, raportowały położenie palców na padzie. Utrudniało to prawidłową obsługę gier z widokiem z perspektywy pierwszej osoby. Teraz system domyślnie rozpoznaje ruch wskaźnika i gesty przewijania, gdy touchpad jest przechwytywany, i zgłasza je tak samo jak zdarzenia myszy. Nadal możesz prosić o stare, szczegółowe dane o położeniu palca, wyraźnie żądając rejestrowania w nowym trybie „bezwzględnym”.

// To request the new default relative mode (mouse-like events)
// This is the same as requesting with View.POINTER_CAPTURE_MODE_RELATIVE
view.requestPointerCapture()

// To request the legacy absolute mode (raw touch coordinates)
view.requestPointerCapture(View.POINTER_CAPTURE_MODE_ABSOLUTE)

Granice spoczynkowe selektora interaktywnego

Wywołując funkcję getInitialRestingBounds w ChooserSession na Androidzie, aplikacja może określić pozycję docelową, którą zajmuje selektor po zakończeniu animacji i wczytaniu danych, co umożliwia lepsze dostosowanie interfejsu.

Połączenia i wiele urządzeń

Przekazywanie aplikacji na inne urządzenie

Nowy interfejs Handoff API umożliwia określenie stanu aplikacji, który ma zostać wznowiony na innym urządzeniu, np. tablecie z Androidem. Gdy użytkownik wyrazi zgodę, system synchronizuje stan za pomocą interfejsu CompanionDeviceManager i wyświetla sugestię przekazania w launcherze urządzeń znajdujących się w pobliżu. Ta funkcja została zaprojektowana z myślą o zapewnieniu płynności pracy, dzięki czemu użytkownicy mogą kontynuować zadania dokładnie w miejscu, w którym je przerwali, w całym ekosystemie Androida. Co ważne, funkcja przekazywania obsługuje zarówno przejścia między aplikacjami natywnymi, jak i przejścia z aplikacji do witryny, co zapewnia maksymalną elastyczność i pełne wrażenia, nawet jeśli aplikacja natywna nie jest zainstalowana na urządzeniu odbierającym.

Zaawansowane interfejsy API pomiaru odległości

Dodajemy obsługę 2 nowych technologii pomiaru odległości:

1. UWB DL-TDOA, która umożliwia aplikacjom korzystanie z technologii UWB do nawigacji w pomieszczeniach. Ten interfejs API jest zgodny ze specyfikacją FIRA (Fine Ranging Consortium) 4.0 DL-TDOA i umożliwia nawigację w pomieszczeniach z zachowaniem prywatności  (zapobiega śledzeniu urządzenia przez punkt dostępu).
2. Wykrywanie bliskości, które umożliwia aplikacjom korzystanie z nowej specyfikacji pomiaru odległości przyjętej przez WFA (WiFi Alliance). W porównaniu z obecną specyfikacją pomiaru odległości opartego na technologii Wi-Fi Aware ta technologia zapewnia większą niezawodność i dokładność.

Ulepszenia pakietów danych

Aby zoptymalizować jakość multimediów, aplikacja może teraz pobierać maksymalne szybkości transmisji danych przydzielone przez operatora dla aplikacji do strumieniowania za pomocą funkcji getStreamingAppMaxDownlinkKbps i getStreamingAppMaxUplinkKbps.

Główne funkcje, prywatność i wydajność

Dostęp przez sieć lokalną

Android 17 wprowadza uprawnienie w czasie działania (aplikacji) ACCESS_LOCAL_NETWORK, aby chronić użytkowników przed nieautoryzowanym dostępem do sieci lokalnej. Ponieważ ta funkcja należy do istniejącej grupy uprawnień NEARBY_DEVICES, użytkownicy, którzy przyznali już inne uprawnienia NEARBY_DEVICES, nie będą ponownie proszeni o ich przyznanie. Deklarując to uprawnienie i o nie prosząc, aplikacja może wykrywać urządzenia w lokalnej sieci komputerowej (LAN), takie jak inteligentne urządzenia domowe czy odbiorniki do przesyłania, i się z nimi łączyć. Zapobiega to wykorzystywaniu przez złośliwe aplikacje nieograniczonego dostępu do sieci lokalnej w celu potajemnego śledzenia użytkowników i zbierania odcisków cyfrowych. Aplikacje kierowane na Androida 17 lub nowszego będą miały 2 sposoby na utrzymanie komunikacji z urządzeniami w sieci LAN: mogą korzystać z wybierania urządzeń za pomocą systemu, które chroni prywatność i pomija prośbę o uprawnienia, lub wyraźnie prosić o to nowe uprawnienie w czasie działania, aby utrzymać komunikację w sieci lokalnej.

Rozgłaszanie zmiany przesunięcia strefy czasowej

Android udostępnia teraz niezawodny zamiar transmisji ACTION_TIMEZONE_OFFSET_CHANGED, który jest wywoływany, gdy zmienia się przesunięcie strefy czasowej systemu, np. podczas przejścia na czas letni. Uzupełnia to istniejące intencje transmisji ACTION_TIME_CHANGED i ACTION_TIMEZONE_CHANGED, które są wywoływane odpowiednio wtedy, gdy zmienia się sygnatura czasu uniksowego i gdy zmienia się identyfikator strefy czasowej.

Zarządzanie NPU i ustalanie priorytetów

Aplikacje na Androida 17, które potrzebują bezpośredniego dostępu do NPU, muszą zadeklarować w pliku manifestu FEATURE_NEURAL_PROCESSING_UNIT, aby uniknąć zablokowania dostępu do NPU. Dotyczy to aplikacji, które używają delegata LiteRT NPU, pakietów SDK specyficznych dla dostawcy, a także wycofanego NNAPI.

Obsługa ICU 78 i Unicode 17

Główne biblioteki internacjonalizacji zostały zaktualizowane do wersji ICU 78, co rozszerza obsługę nowych skryptów, znaków i bloków emoji oraz umożliwia bezpośrednie formatowanie obiektów czasu.

Zabezpieczenie hasłem jednorazowym SMS

Android rozszerza ochronę haseł jednorazowych SMS-em, automatycznie opóźniając dostęp do wiadomości SMS z hasłem jednorazowym. Wcześniej ochrona była skoncentrowana głównie na formacie SMS Retriever, w którym dostarczanie wiadomości zawierających skrót SMS Retriever jest opóźniane w przypadku większości aplikacji o 3 godziny. Jednak w przypadku niektórych aplikacji, takich jak domyślna aplikacja do SMS-ów itp., oraz aplikacji odpowiadającej identyfikatorowi, to opóźnienie nie obowiązuje. Ta aktualizacja rozszerza ochronę na wszystkie SMS-y z kodem OTP. W przypadku większości aplikacji SMS-y zawierające jednorazowy kod dostępu będą dostępne dopiero po 3 godzinach, aby zapobiec przejęciu kodu. Transmisja SMS_RECEIVED_ACTION zostanie wstrzymana, a zapytania do bazy danych dostawcy SMS-ów będą filtrowane. Po upływie tego czasu SMS będzie dostępny w tych aplikacjach. 

Opóźniony dostęp do wiadomości SMS w formacie WebOTP

Jeśli aplikacja ma uprawnienia do odczytywania SMS-ów, ale nie jest zamierzonym odbiorcą hasła jednorazowego (co zostało ustalone na podstawie weryfikacji domeny), wiadomość SMS w formacie WebOTP będzie dostępna dopiero po upływie 3 godzin. Ta zmiana ma na celu zwiększenie bezpieczeństwa użytkowników, ponieważ zapewnia, że kod weryfikacyjny może być odczytywany programowo tylko przez aplikacje powiązane z domeną wymienioną w wiadomości. Ta zmiana dotyczy wszystkich aplikacji niezależnie od poziomu interfejsu API, na który są kierowane.

Opóźniony dostęp do standardowych wiadomości SMS z hasłem jednorazowym

W przypadku SMS-ów zawierających kod OTP, które nie korzystają z formatów WebOTP ani SMS Retriever, kod OTP będzie dostępny dopiero po 3 godzinach w większości aplikacji. Ta zmiana dotyczy tylko aplikacji kierowanych na Androida 17 (interfejs API na poziomie 37) lub nowszego.

Niektóre aplikacje, takie jak domyślna aplikacja do SMS-ów, aplikacja asystenta, aplikacje towarzyszące połączonym urządzeniom itp., będą zwolnione z tego opóźnienia.

Wszystkie aplikacje, które polegają na odczytywaniu wiadomości SMS w celu wyodrębniania kodów OTP, powinny przejść na korzystanie z interfejsów API SMS Retriever lub SMS User Consent, aby zapewnić ciągłość działania.

Harmonogram Androida 17

Szybko przejdziemy z tej wersji beta do etapu stabilności platformy, który planujemy na marzec. Na tym etapie udostępnimy ostateczne interfejsy API pakietu SDK/NDK. Od tego momentu możesz kierować aplikację na pakiet SDK 37 i publikować ją w Google Play, aby przeprowadzić testy i zebrać opinie użytkowników w ciągu kilku miesięcy przed ogólną dostępnością Androida 17.

Rok premier

Planujemy, że Android 17 będzie nadal otrzymywać aktualizacje w ramach serii kwartalnych wersji. Nadchodząca wersja w II kwartale to jedyna, w której wprowadzimy planowane zmiany w działaniu aplikacji. W IV kwartale planujemy wydać mniejszą aktualizację pakietu SDK z dodatkowymi interfejsami API i funkcjami.

Pierwsze kroki z Androidem 17

Możesz zarejestrować dowolne obsługiwane urządzenie Pixel, aby otrzymywać tę i przyszłe aktualizacje wersji beta Androida bezprzewodowo. Jeśli nie masz urządzenia Pixel, możesz używać 64-bitowych obrazów systemu z emulatorem Androida w Android Studio.

Jeśli uczestniczysz w programie Android Beta, otrzymasz aktualizację OTA do wersji beta 2.

Jeśli masz wersję beta Androida 26Q1 i chcesz zainstalować ostateczną stabilną wersję 26Q1 i zakończyć testy beta, zignoruj aktualizację OTA do wersji beta 26Q2 i poczekaj na wydanie wersji 26Q1.

Chętnie poznamy Twoją opinię, dlatego zgłaszaj problemy i przesyłaj prośby o dodanie funkcji na stronie z opiniami. Im wcześniej otrzymamy Twoją opinię, tym więcej będziemy mogli uwzględnić w naszej pracy nad wersją ostateczną.

Aby zapewnić sobie najlepsze środowisko programistyczne w Androidzie 17, zalecamy korzystanie z najnowszej wersji testowej Androida Studio (Panda). Gdy wszystko skonfigurujesz, wykonaj te czynności:

• Skompiluj kod z użyciem nowego pakietu SDK, przetestuj go w środowiskach CI i zgłoś wszelkie problemy w naszym narzędziu do śledzenia na stronie z opiniami.
• Sprawdź, czy Twoja obecna aplikacja jest zgodna z Androidem 17, dowiedz się, czy zmiany w tym systemie mają na nią wpływ, zainstaluj ją na urządzeniu lub emulatorze z Androidem 17 i dokładnie ją przetestuj.

W trakcie cyklu wydawniczego Androida 17 będziemy regularnie aktualizować wersje systemu w wersji zapoznawczej lub beta oraz pakiet SDK. Po zainstalowaniu wersji beta przyszłe aktualizacje będą pobierane automatycznie.

OTA w przypadku wszystkich kolejnych wersji przedpremierowych i beta.

Pełne informacje znajdziesz na stronie dla deweloperów Androida 17.

Dołącz do rozmowy

W miarę zbliżania się do stabilności platformy i ogólnej dostępności Androida 17 jeszcze w tym roku Twoje opinie pozostają dla nas najcenniejszym źródłem informacji. Niezależnie od tego, czy jesteś osobą, która jako jedna z pierwszych korzysta z kanału Canary, czy deweloperem aplikacji testującym wersję beta 2, możesz dołączyć do naszych społeczności i przesłać opinię. Słuchamy.