Android 17 wprowadza nowe funkcje i interfejsy API dla deweloperów. W kolejnych sekcjach znajdziesz podsumowanie tych funkcji, które pomoże Ci rozpocząć korzystanie z powiązanych interfejsów API.
Szczegółową listę nowych, zmodyfikowanych i usuniętych interfejsów API znajdziesz w raporcie o różnicach w interfejsach API. Szczegółowe informacje o nowych interfejsach API znajdziesz w dokumentacji interfejsów API Androida. Nowe interfejsy API są wyróżnione.
Sprawdź też obszary, na które zmiany na platformie mogą mieć wpływ. Więcej informacji znajdziesz na tych stronach:
- Zmiany w działaniu, które wpływają na aplikacje kierowane na Androida 17
- Zmiany w działaniu, które wpływają na wszystkie aplikacje niezależnie od
targetSdkVersion.
Główna funkcja
Android 17 wprowadza te nowe funkcje związane z podstawową funkcjonalnością Androida:
Nowe aktywatory ProfilingManager
Android 17 dodaje kilka nowych wyzwalaczy systemowych do ProfilingManager, aby pomóc Ci zbierać szczegółowe dane do debugowania problemów z wydajnością.
Nowe aktywatory to:
TRIGGER_TYPE_COLD_START: wyzwalacz występuje podczas zimnego startu aplikacji. W odpowiedzi podaje próbkę stosu wywołań i ślad systemowy.TRIGGER_TYPE_OOM: reguła jest uruchamiana, gdy aplikacja zgłaszaOutOfMemoryErrori w odpowiedzi udostępnia zrzut sterty Javy.TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE: wyzwalacz uruchamia się, gdy aplikacja zostanie zamknięta z powodu nieprawidłowego i nadmiernego wykorzystania procesora. W odpowiedzi podaje próbkę stosu wywołań.
Aby dowiedzieć się, jak skonfigurować wyzwalacz systemowy, zapoznaj się z dokumentacją dotyczącą profilowania opartego na wyzwalaczach oraz pobierania i analizowania danych profilowania.
Interfejsy JobDebugInfo API
Android 17 wprowadza nowe interfejsy API JobDebugInfo, które pomagają deweloperom debugować zadania JobScheduler – dlaczego nie działają, jak długo działały i inne zagregowane informacje.
Pierwsza metoda rozszerzonych interfejsów JobDebugInfo API to getPendingJobReasonStats(), która zwraca mapę przyczyn, dla których zadanie było w stanie oczekiwania na wykonanie, oraz odpowiadające im łączne czasy oczekiwania. Ta metoda dołącza do metod getPendingJobReasonsHistory() i getPendingJobReasons(), aby dostarczać informacji o tym, dlaczego zaplanowane zadanie nie działa zgodnie z oczekiwaniami. Upraszcza jednak pobieranie informacji, ponieważ zarówno czas trwania, jak i przyczyna zadania są dostępne w ramach jednej metody.
Na przykład dla określonego jobId metoda może zwrócić PENDING_JOB_REASON_CONSTRAINT_CHARGING i czas trwania 60000 ms, co oznacza, że zadanie oczekiwało przez 60000 ms, ponieważ nie spełniało ograniczenia dotyczącego ładowania.
Prywatność
Android 17 zawiera te nowe funkcje, które zwiększają prywatność użytkowników.
Selektor kontaktów na Androidzie
Selektor kontaktów na Androidzie to standardowy interfejs przeglądania, który umożliwia użytkownikom udostępnianie kontaktów w Twojej aplikacji. Jest on dostępny na urządzeniach z Androidem 17 lub nowszym i stanowi alternatywę dla szerokiego uprawnienia READ_CONTACTS, która zapewnia ochronę prywatności. Zamiast prosić o dostęp do całej książki adresowej użytkownika, aplikacja określa potrzebne jej pola danych, takie jak numery telefonów lub adresy e-mail, a użytkownik wybiera konkretne kontakty do udostępnienia. Dzięki temu aplikacja uzyskuje dostęp do odczytu tylko wybranych danych, co zapewnia szczegółową kontrolę i spójne wrażenia użytkowników dzięki wbudowanym funkcjom wyszukiwania, przełączania profili i wielokrotnego wyboru bez konieczności tworzenia interfejsu użytkownika ani zarządzania nim.
Więcej informacji znajdziesz w dokumentacji selektora kontaktów.
Bezpieczeństwo
Android 17 zawiera te nowe funkcje, które zwiększają bezpieczeństwo urządzenia i aplikacji:
Tryb ochrony zaawansowanej na Androidzie (AAPM)
Tryb ochrony zaawansowanej na Androidzie oferuje użytkownikom tego systemu nowy, zaawansowany zestaw funkcji zabezpieczeń, co stanowi ważny krok w ochronie użytkowników – zwłaszcza tych bardziej narażonych – przed zaawansowanymi atakami. AAPM to funkcja, którą można włączyć. Aktywuje się ją za pomocą jednego ustawienia konfiguracyjnego, które użytkownicy mogą włączyć w dowolnym momencie, aby zastosować zestaw zabezpieczeń.
Te podstawowe konfiguracje obejmują blokowanie instalacji aplikacji z nieznanych źródeł (instalowanie z zewnątrz), ograniczanie sygnalizacji danych przez USB i wymaganie skanowania przez Google Play Protect, co znacznie zmniejsza obszar podatny na ataki.
Deweloperzy mogą zintegrować tę funkcję za pomocą interfejsu AdvancedProtectionManager API, aby wykrywać stan trybu, co umożliwia aplikacjom automatyczne przyjmowanie wzmocnionych zabezpieczeń lub ograniczanie funkcji wysokiego ryzyka, gdy użytkownik wyrazi na to zgodę.
Łączność
Android 17 wprowadza te funkcje, aby poprawić łączność urządzeń i aplikacji.
Sieci satelitarne o ograniczonej przepustowości
Wprowadza optymalizacje, które umożliwiają skuteczne działanie aplikacji w sieciach satelitarnych o niskiej przepustowości.
Wrażenia użytkowników i interfejs systemu
Android 17 zawiera te zmiany, które zwiększają wygodę użytkowników.
Handoff
Przekazywanie to nowa funkcja i interfejs API, które pojawią się w Androidzie 17. Deweloperzy aplikacji mogą je zintegrować, aby zapewnić użytkownikom ciągłość działania na różnych urządzeniach. Umożliwia użytkownikowi rozpoczęcie działania w aplikacji na jednym urządzeniu z Androidem i przeniesienie go na inne urządzenie z Androidem. Przekazywanie działa w tle na urządzeniu użytkownika i wyświetla dostępne działania z innych pobliskich urządzeń użytkownika w różnych punktach wejścia, takich jak program uruchamiający i pasek zadań na urządzeniu odbierającym.
Aplikacje mogą wyznaczyć przekazywanie, aby uruchamiać tę samą natywną aplikację na Androida, jeśli jest ona zainstalowana i dostępna na urządzeniu odbierającym. W tym przepływie między aplikacjami użytkownik jest przekierowywany za pomocą precyzyjnego linku do wyznaczonej aktywności. Przekazywanie z aplikacji do przeglądarki może być też oferowane jako opcja rezerwowa lub bezpośrednio wdrażane za pomocą przekazywania z użyciem adresu URL.
Obsługa funkcji Handoff jest wdrażana w przypadku poszczególnych aktywności. Aby włączyć przekazywanie, wywołaj metodę setHandoffEnabled() dla aktywności. Wraz z przekazaniem może być konieczne przesłanie dodatkowych danych, aby odtworzona aktywność na urządzeniu odbierającym mogła przywrócić odpowiedni stan. Zaimplementuj wywołanie zwrotne onHandoffActivityRequested(), aby zwrócić obiekt HandoffActivityData, który zawiera szczegółowe informacje określające, jak funkcja przekazywania ma obsługiwać i odtwarzać aktywność na urządzeniu odbierającym.
Live Update - Semantic color API
W Androidzie 17 Live Update wprowadza interfejsy API kolorowania semantycznego, aby obsługiwać kolory o uniwersalnym znaczeniu.
Kolorowanie semantyczne jest obsługiwane w przypadku tych klas:
NotificationNotification.MetricNotification.ProgressStyle.PointNotification.ProgressStyle.Segment
Kolorowanki
- Zielony: związany z bezpieczeństwem. Ten kolor powinien być używany w sytuacji, gdy chcesz poinformować innych, że jesteś bezpieczny.
- Pomarańczowy: do oznaczania ostrzeżeń i zagrożeń fizycznych. Ten kolor powinien być używany w sytuacjach, w których użytkownicy muszą zwrócić uwagę na ustawienia, aby lepiej chronić swoje dane.
- Czerwony: zwykle oznacza niebezpieczeństwo, zatrzymanie. Powinien być wyświetlany w przypadku, gdy pilnie potrzebujesz uwagi użytkowników.
- Niebieski: neutralny kolor treści informacyjnych, które powinny wyróżniać się na tle innych treści.
Przykład poniżej pokazuje, jak zastosować style semantyczne do tekstu w powiadomieniu:
val ssb = SpannableStringBuilder()
.append("Colors: ")
.append("NONE", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_UNSPECIFIED), 0)
.append(", ")
.append("INFO", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_INFO), 0)
.append(", ")
.append("SAFE", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_SAFE), 0)
.append(", ")
.append("CAUTION", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_CAUTION), 0)
.append(", ")
.append("DANGER", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_DANGER), 0)
Notification.Builder(context, channelId)
.setSmallIcon(R.drawable.ic_icon)
.setContentTitle("Hello World!")
.setContentText(ssb)
.setOngoing(true)
.setRequestPromotedOngoing(true)
UWB Downlink-TDoA API na Androida 17
Określanie odległości za pomocą różnicy czasu dotarcia sygnału w kierunku do urządzenia (DL-TDoA) pozwala urządzeniu określić swoje położenie względem wielu punktów dostępu przez pomiar względnych czasów dotarcia sygnałów.
Poniższy fragment kodu pokazuje, jak zainicjować Menedżera pomiarów odległości, sprawdzić możliwości urządzenia i rozpocząć sesję DL-TDoA:
Kotlin
class RangingApp {
fun initDlTdoa(context: Context) {
// Initialize the Ranging Manager
val rangingManager = context.getSystemService(RangingManager::class.java)
// Register for device capabilities
val capabilitiesCallback = object : RangingManager.CapabilitiesCallback {
override fun onRangingCapabilities(capabilities: RangingCapabilities) {
// Make sure Dl-TDoA is supported before starting the session
if (capabilities.uwbCapabilities != null && capabilities.uwbCapabilities!!.isDlTdoaSupported) {
startDlTDoASession(context)
}
}
}
rangingManager.registerCapabilitiesCallback(Executors.newSingleThreadExecutor(), capabilitiesCallback)
}
fun startDlTDoASession(context: Context) {
// Initialize the Ranging Manager
val rangingManager = context.getSystemService(RangingManager::class.java)
// Create session and configure parameters
val executor = Executors.newSingleThreadExecutor()
val rangingSession = rangingManager.createRangingSession(executor, RangingSessionCallback())
val rangingRoundIndexes = intArrayOf(0)
val config: ByteArray = byteArrayOf() // OOB config data
val params = DlTdoaRangingParams.createFromFiraConfigPacket(config, rangingRoundIndexes)
val rangingDevice = RangingDevice.Builder().build()
val rawTagDevice = RawRangingDevice.Builder()
.setRangingDevice(rangingDevice)
.setDlTdoaRangingParams(params)
.build()
val dtTagConfig = RawDtTagRangingConfig.Builder(rawTagDevice).build()
val preference = RangingPreference.Builder(DEVICE_ROLE_DT_TAG, dtTagConfig)
.setSessionConfig(SessionConfig.Builder().build())
.build()
// Start the ranging session
rangingSession.start(preference)
}
}
private class RangingSessionCallback : RangingSession.Callback {
override fun onDlTdoaResults(peer: RangingDevice, measurement: DlTdoaMeasurement) {
// Process measurement results here
}
}
Java
public class RangingApp {
public void initDlTdoa(Context context) {
// Initialize the Ranging Manager
RangingManager rangingManager = context.getSystemService(RangingManager.class);
// Register for device capabilities
RangingManager.CapabilitiesCallback capabilitiesCallback = new RangingManager.CapabilitiesCallback() {
@Override
public void onRangingCapabilities(RangingCapabilities capabilities) {
// Make sure Dl-TDoA is supported before starting the session
if (capabilities.getUwbCapabilities() != null && capabilities.getUwbCapabilities().isDlTdoaSupported) {
startDlTDoASession(context);
}
}
};
rangingManager.registerCapabilitiesCallback(Executors.newSingleThreadExecutor(), capabilitiesCallback);
}
public void startDlTDoASession(Context context) {
RangingManager rangingManager = context.getSystemService(RangingManager.class);
// Create session and configure parameters
Executor executor = Executors.newSingleThreadExecutor();
RangingSession rangingSession = rangingManager.createRangingSession(executor, new RangingSessionCallback());
int[] rangingRoundIndexes = new int[] {0};
byte[] config = new byte[0]; // OOB config data
DlTdoaRangingParams params = DlTdoaRangingParams.createFromFiraConfigPacket(config, rangingRoundIndexes);
RangingDevice rangingDevice = new RangingDevice.Builder().build();
RawRangingDevice rawTagDevice = new RawRangingDevice.Builder()
.setRangingDevice(rangingDevice)
.setDlTdoaRangingParams(params)
.build();
RawDtTagRangingConfig dtTagConfig = new RawDtTagRangingConfig.Builder(rawTagDevice).build();
RangingPreference preference = new RangingPreference.Builder(DEVICE_ROLE_DT_TAG, dtTagConfig)
.setSessionConfig(new SessionConfig.Builder().build())
.build();
// Start the ranging session
rangingSession.start(preference);
}
private static class RangingSessionCallback implements RangingSession.Callback {
@Override
public void onDlTdoaResults(RangingDevice peer, DlTdoaMeasurement measurement) {
// Process measurement results here
}
}
}
Konfiguracje poza pasmem (OOB)
Poniższy fragment zawiera przykład danych konfiguracyjnych DL-TDoA OOB dla Wi-Fi i BLE:
Java
// Wifi Configuration
byte[] wifiConfig = {
(byte) 0xDD, (byte) 0x2D, (byte) 0x5A, (byte) 0x18, (byte) 0xFF, // Header
(byte) 0x5F, (byte) 0x19, // FiRa Sub-Element
(byte) 0x02, (byte) 0x00, // Profile ID
(byte) 0x06, (byte) 0x02, (byte) 0x20, (byte) 0x08, // MAC Address
(byte) 0x14, (byte) 0x01, (byte) 0x0C, // Preamble Index
(byte) 0x27, (byte) 0x02, (byte) 0x08, (byte) 0x07, // Vendor ID
(byte) 0x28, (byte) 0x06, (byte) 0xCA, (byte) 0xC8, (byte) 0xA6, (byte) 0xF7, (byte) 0x6F, (byte) 0x08, // Static STS IV
(byte) 0x08, (byte) 0x02, (byte) 0x60, (byte) 0x09, // Slot Duration
(byte) 0x1B, (byte) 0x01, (byte) 0x0A, // Slots per RR
(byte) 0x09, (byte) 0x04, (byte) 0xE8, (byte) 0x03, (byte) 0x00, (byte) 0x00, // Duration
(byte) 0x9F, (byte) 0x04, (byte) 0x67, (byte) 0x45, (byte) 0x23, (byte) 0x01 // Session ID
};
// BLE Configuration
byte[] bleConfig = {
(byte) 0x2D, (byte) 0x16, (byte) 0xF4, (byte) 0xFF, // Header
(byte) 0x5F, (byte) 0x19, // FiRa Sub-Element
(byte) 0x02, (byte) 0x00, // Profile ID
(byte) 0x06, (byte) 0x02, (byte) 0x20, (byte) 0x08, // MAC Address
(byte) 0x14, (byte) 0x01, (byte) 0x0C, // Preamble Index
(byte) 0x27, (byte) 0x02, (byte) 0x08, (byte) 0x07, // Vendor ID
(byte) 0x28, (byte) 0x06, (byte) 0xCA, (byte) 0xC8, (byte) 0xA6, (byte) 0xF7, (byte) 0x6F, (byte) 0x08, // Static STS IV
(byte) 0x08, (byte) 0x02, (byte) 0x60, (byte) 0x09, // Slot Duration
(byte) 0x1B, (byte) 0x01, (byte) 0x0A, // Slots per RR
(byte) 0x09, (byte) 0x04, (byte) 0xE8, (byte) 0x03, (byte) 0x00, (byte) 0x00, // Duration
(byte) 0x9F, (byte) 0x04, (byte) 0x67, (byte) 0x45, (byte) 0x23, (byte) 0x01 // Session ID
};
Jeśli nie możesz użyć konfiguracji OOB, ponieważ jej brakuje, lub jeśli musisz zmienić wartości domyślne, których nie ma w konfiguracji OOB, możesz utworzyć parametry za pomocą znaku DlTdoaRangingParams.Builder, jak pokazano w tym fragmencie kodu. Zamiast parametru DlTdoaRangingParams.createFromFiraConfigPacket() możesz użyć tych parametrów:
Kotlin
val dlTdoaParams = DlTdoaRangingParams.Builder(1)
.setComplexChannel(UwbComplexChannel.Builder()
.setChannel(9).setPreambleIndex(10).build())
.setDeviceAddress(deviceAddress)
.setSessionKeyInfo(byteArrayOf(0x01, 0x02, 0x03, 0x04))
.setRangingIntervalMillis(240)
.setSlotDuration(UwbRangingParams.DURATION_2_MS)
.setSlotsPerRangingRound(20)
.setRangingRoundIndexes(byteArrayOf(0x01, 0x05))
.build()
Java
DlTdoaRangingParams dlTdoaParams = new DlTdoaRangingParams.Builder(1)
.setComplexChannel(new UwbComplexChannel.Builder()
.setChannel(9).setPreambleIndex(10).build())
.setDeviceAddress(deviceAddress)
.setSessionKeyInfo(new byte[]{0x01, 0x02, 0x03, 0x04})
.setRangingIntervalMillis(240)
.setSlotDuration(UwbRangingParams.DURATION_2_MS)
.setSlotsPerRangingRound(20)
.setRangingRoundIndexes(new byte[]{0x01, 0x05})
.build();