Czwarta wersja beta Androida 17

Android 17 osiągnął wersję beta 4, czyli ostatnią zaplanowaną wersję beta w tym cyklu wydania. Jest to ważny etap w zakresie zgodności aplikacji i stabilności platformy. Niezależnie od tego, czy dopracowujesz wygodę użytkowników, zapewniasz płynne renderowanie od krawędzi do krawędzi, czy korzystasz z najnowszych interfejsów API, wersja beta 4 zapewnia niemal ostateczne środowisko do testowania. 

Przygotuj swoje aplikacje, biblioteki, narzędzia i silniki gier

Jeśli tworzysz Android SDK, bibliotekę, narzędzie lub silnik gry, musisz teraz przygotować niezbędne aktualizacje, aby deweloperzy aplikacji i gier nie mieli problemów ze zgodnością i mogli korzystać z najnowszych funkcji Android SDK. Poinformuj deweloperów, że do pełnej obsługi Androida 17 wymagane są aktualizacje.

Testowanie polega na zainstalowaniu aplikacji produkcyjnej lub testowej korzystającej z biblioteki lub silnika w Google Play lub w inny sposób na urządzeniu lub emulatorze z Androidem 17 w wersji beta 4. Sprawdź wszystkie ścieżki w aplikacji i poszukaj problemów z funkcjonalnością lub interfejsem. Każda wersja Androida zawiera zmiany na platformie, które zwiększają prywatność, bezpieczeństwo i ogólną wygodę użytkowników. Aby skupić się na testowaniu, zapoznaj się ze zmianami w działaniu aplikacji działających i kierowanych na Androida 17, w tym:

• Możliwość zmiany rozmiaru na dużych ekranach: gdy zaczniesz kierować aplikację na Androida 17, nie będziesz już mieć możliwości rezygnacji z zachowania orientacji, możliwości zmiany rozmiaru i ograniczeń formatu obrazu na dużych ekranach.
• Dynamiczne wczytywanie kodu: jeśli Twoja aplikacja jest kierowana na Androida 17 lub nowszego, ochrona Safer Dynamic Code Loading (DCL) wprowadzona w Androidzie 14 w przypadku plików DEX i JAR obejmuje teraz biblioteki natywne. Wszystkie pliki natywne wczytywane za pomocą System.load() muszą być oznaczone jako tylko do odczytu. W przeciwnym razie system zgłosi błąd UnsatisfiedLinkError.
• Domyślne włączanie CT: Przejrzystość certyfikatów (CT) jest domyślnie włączona. (W Androidzie 16 CT jest dostępna, ale aplikacje musiały wyrazić zgodę.)
• Ochrona sieci lokalnej: aplikacje kierowane na Androida 17 lub nowszego mają domyślnie zablokowany dostęp do sieci lokalnej. Jeśli to możliwe, przejdź na selektory chroniące prywatność i użyj nowego ACCESS_LOCAL_NETWORK uprawnienia do szerokiego, trwałego dostępu.
• Wzmacnianie zabezpieczeń dźwięku w tle: od Androida 17 platforma audio wymusza ograniczenia dotyczące interakcji z dźwiękiem w tle, w tym odtwarzania dźwięku, żądań aktywności audio i interfejsów API zmiany głośności. Na podstawie Twoich opinii wprowadziliśmy kilka zmian od wersji beta 2, w tym ograniczenie targetSDK podczas egzekwowania działania usługi działającej na pierwszym planie i wyłączenie dźwięku alarmu. Szczegółowe informacje znajdziesz w zaktualizowanych wskazówkach.

Limity pamięci aplikacji

Android wprowadza limity pamięci aplikacji oparte na łącznej ilości pamięci RAM urządzenia, aby stworzyć bardziej stabilne i deterministyczne środowisko dla Twoich aplikacji i użytkowników Androida. W Androidzie 17 limity są ustawione konserwatywnie, aby ustalić podstawowe wartości systemu i wykrywać ekstremalne wycieki pamięci oraz inne wartości odstające, zanim spowodują one niestabilność całego systemu, co może prowadzić do zacinania się interfejsu, szybszego rozładowywania się baterii i zamykania aplikacji. Chociaż przewidujemy minimalny wpływ na zdecydowaną większość sesji aplikacji, zalecamy stosowanie tych sprawdzonych metod dotyczących pamięci, w tym ustalenie podstawowej wartości pamięci.

W obecnej implementacji, jeśli Twoja aplikacja została dotknięta problemem, getDescription w ApplicationExitInfo będzie zawierać ciąg znaków "MemoryLimiter". Możesz też użyć profilowania opartego na wyzwalaczach z TRIGGER_TYPE_ANOMALY, aby uzyskać zrzuty sterty, które są zbierane po osiągnięciu limitu pamięci.

Aby ułatwić Ci znajdowanie wycieków pamięci, Android Studio Panda dodaje integrację LeakCanary bezpośrednio w profilerze Android Studio jako osobne zadanie, które jest kontekstowo powiązane z IDE i w pełni zintegrowane z kodem źródłowym.

Mniejsze zużycie pamięci przekłada się bezpośrednio na płynniejsze działanie, dłuższy czas pracy na baterii i lepsze wrażenia na wszystkich urządzeniach. Stwórzmy razem szybszą i bardziej niezawodną przyszłość ekosystemu Androida.

Wywoływanie profilowania w przypadku anomalii w aplikacji

Android wprowadza usługę wykrywania anomalii na urządzeniu, która monitoruje zachowania wymagające dużej ilości zasobów i potencjalne regresje zgodności. Ta usługa, zintegrowana z ProfilingManager, umożliwia aplikacji otrzymywanie artefaktów profilowania wywoływanych przez określone zdarzenia wykryte przez system.

Użyj wyzwalacza TRIGGER_TYPE_ANOMALY, aby wykrywać problemy z wydajnością systemu, takie jak nadmierna liczba wywołań bindera i nadmierne wykorzystanie pamięci. Gdy aplikacja przekroczy limity pamięci określone przez system operacyjny, wyzwalacz anomalii umożliwia deweloperom otrzymywanie zrzutów sterty specyficznych dla aplikacji, co pomaga w identyfikowaniu i rozwiązywaniu problemów z pamięcią. Dodatkowo w przypadku nadmiernego spamu bindera wyzwalacz anomalii udostępnia profil próbkowania stosu w transakcjach bindera.

To wywołanie zwrotne interfejsu API następuje przed wprowadzeniem jakichkolwiek ograniczeń przez system. Może na przykład pomóc deweloperom w zbieraniu danych debugowania, zanim aplikacja zostanie zamknięta przez system z powodu przekroczenia limitów pamięci. Aby dowiedzieć się, jak używać wyzwalacza, zapoznaj się z dokumentacją dotyczącą profilowania opartego na wyzwalaczach.

    val profilingManager = applicationContext.getSystemService(ProfilingManager::class.java)
    val triggers = ArrayList<ProfilingTrigger>()  
    triggers.add(ProfilingTrigger.Builder(
                 ProfilingTrigger.TRIGGER_TYPE_ANOMALY))
    val mainExecutor: Executor = Executors.newSingleThreadExecutor()
    val resultCallback = Consumer<ProfilingResult> { profilingResult ->
        if (profilingResult.errorCode != ProfilingResult.ERROR_NONE) {
            // upload profile result to server for further analysis          
            setupProfileUploadWorker(profilingResult.resultFilePath)
        } 
    profilingManager.registerForAllProfilingResults(mainExecutor, resultCallback)
    profilingManager.addProfilingTriggers(triggers)
}

Kryptografia postkwantowa (PQC) w magazynie kluczy Androida

Magazyn kluczy Androida dodał obsługę znormalizowanego przez NIST algorytmu ML-DSA (Module-Lattice-Based Digital Signature Algorithm). Na obsługiwanych urządzeniach możesz generować klucze ML-DSA i używać ich do tworzenia podpisów odpornych na złamanie za pomocą komputera kwantowego, w całości w bezpiecznym sprzęcie urządzenia. Magazyn kluczy Androida udostępnia warianty algorytmów ML-DSA-65 i ML-DSA-87 za pomocą standardowych interfejsów API architektury kryptograficznej Java: KeyPairGenerator, KeyFactory i Signature. Więcej informacji znajdziesz w dokumentacji dla deweloperów.

KeyPairGenerator generator = KeyPairGenerator.getInstance(
        “ML-DSA-65”, "AndroidKeyStore");
generator.initialize(
        new KeyGenParameterSpec.Builder(
                “my-key-alias”,
                KeyProperties.PURPOSE_SIGN | KeyProperties.PURPOSE_VERIFY)
        .build());
KeyPair keyPair = generator.generateKeyPair();

Rozpoczęcie korzystania z Androida 17

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

Jeśli obecnie uczestniczysz w programie testów beta Androida, otrzymasz aktualizację OTA do wersji beta 4.

Nadal zgłaszaj problemy i przesyłaj prośby o dodanie funkcji na stronie opinii. Im szybciej otrzymamy Twoją opinię, tym więcej będziemy mogli uwzględnić w pracach nad wersją finalną.

Aby zapewnić sobie najlepsze wrażenia podczas tworzenia aplikacji na Androida 17, zalecamy korzystanie z najnowszej wersji testowej Android Studio (Panda). Gdy wszystko skonfigurujesz, wykonaj te czynności:

• Skompiluj aplikację za pomocą nowego pakietu SDK, przetestuj ją w środowiskach CI i zgłoś wszelkie problemy w naszym narzędziu do śledzenia na stronie opinii.
• Przetestuj bieżącą aplikację pod kątem zgodności, sprawdź, czy zmiany w Androidzie 17 mają na nią wpływ, zainstaluj aplikację na urządzeniu lub emulatorze z Androidem 17 i dokładnie ją przetestuj.

W trakcie cyklu wydania Androida 17 będziemy regularnie aktualizować obrazy systemu w wersji testowej lub beta oraz pakiet SDK. Po zainstalowaniu wersji beta będziesz automatycznie otrzymywać przyszłe aktualizacje OTA wszystkich kolejnych wersji testowych i beta.

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

Dołącz do rozmowy

Twoja opinia jest dla nas najważniejsza. Niezależnie od tego, czy jesteś użytkownikiem wczesnej wersji w kanale Canary, czy deweloperem aplikacji testującym wersję beta 4, dołącz do naszych społeczności i prześlij opinię. Słuchamy.