Druga wersja beta Androida 17

Dziś udostępniamy drugą wersję beta Androida 17, kontynuując prace nad platformą, która stawia na pierwszym miejscu prywatność, bezpieczeństwo i lepszą wydajność. Ta aktualizacja wprowadza szereg nowych funkcji, w tym interfejs EyeDropper API i narzędzie do wyboru kontaktów, które chroni prywatność użytkowników. 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 tej 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, pływający interfejs użytkownika niezależny od interfejsu API dymków wiadomości. Użytkownicy mogą utworzyć dymek aplikacji na telefonie, urządzeniu składanym lub tablecie, naciskając i 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.

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

EyeDropper API

Nowy interfejs API zakraplacza 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. Dzięki temu zmniejsza się potrzeba 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 raportowały zdarzenia w sposób bardzo różny od myszy. Zamiast względnych ruchów, które byłyby raportowane przez mysz, podawały lokalizacje 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 prosząc o ich rejestrowanie 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 interaktywnego selektora

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

Połączenia i korzystanie z wielu 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 pobliskich urządzeń użytkownika. 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 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 wysyłając prośbę o nie, 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 do potajemnego śledzenia użytkowników i zbierania ich 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 mogą wyraźnie prosić o to nowe uprawnienie w czasie działania, aby utrzymać komunikację w sieci lokalnej.

Transmisja 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 czasowa w formacie Unix, oraz wtedy, gdy zmienia się identyfikator strefy czasowej.

Zarządzanie NPU i określanie 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 konkretnych dostawców, 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ę SMS-ów z hasłami jednorazowymi, automatycznie opóźniając dostęp do takich wiadomości. 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 skrótowi, to opóźnienie nie obowiązuje. Ta aktualizacja rozszerza ochronę na wszystkie SMS-y z kodem OTP. W przypadku większości aplikacji wiadomości SMS zawierające hasło jednorazowe będą dostępne dopiero po 3 godzinach, aby zapobiec przejęciu hasła jednorazowego. Transmisja SMS_RECEIVED_ACTION zostanie wstrzymana, a zapytania do bazy danych dostawcy SMS-ów będą filtrowane. Wiadomość SMS będzie dostępna dla tych aplikacji po upływie tego czasu. 

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ą kodu OTP (co zostało ustalone na podstawie weryfikacji domeny), SMS w formacie WebOTP będzie dostępny 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 docelowego poziomu interfejsu API.

Opóźniony dostęp do standardowych SMS-ów z kodem OTP

W przypadku SMS-ów zawierających kod OTP, które nie korzystają z formatów WebOTP ani SMS Retriever, SMS z kodem OTP będzie dostępny dopiero po 3 godzinach w przypadku 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 czy aplikacje towarzyszące połączonym urządzeniom, będą zwolnione z tego opóźnienia.

Wszystkie aplikacje, które polegają na odczytywaniu SMS-ów w celu wyodrębniania jednorazowych kodów dostępu, 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 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 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, które mogą powodować problemy. W IV kwartale planujemy wydać mniejszą wersję 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 opuścić program 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 naszych pracach nad ostateczną wersją.

Aby zapewnić sobie najlepsze wrażenia podczas tworzenia aplikacji na Androida 17, zalecamy korzystanie z najnowszej wersji podglądowej 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 kompatybilna, dowiedz się, czy zmiany w Androidzie 17 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 będziesz automatycznie otrzymywać przyszłe aktualizacje.

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 wersji Canary, czy deweloperem aplikacji testującym wersję Beta 2, rozważ dołączenie do naszych społeczności i przesyłanie opinii. Słuchamy.