Android 17 osiągnął etap wersji beta 4, czyli ostatniej zaplanowanej wersji beta w tym cyklu wydawniczym. Jest to ważny etap pod względem 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, w którym możesz przeprowadzać testy. 

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

Jeśli tworzysz Android SDK, bibliotekę, narzędzie lub silnik gry, musisz teraz przygotować wszelkie 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 za pomocą Google Play lub innych środków 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, które mają wpływ na aplikacje działające i kierowane na Androida 17. Obejmują one:

• Zmiana rozmiaru na dużych ekranach: gdy zaczniesz kierować aplikację na Androida 17, nie będziesz już mieć możliwości rezygnacji z zachowania orientacji, zmiany rozmiaru i ograniczeń proporcji na dużych ekranach.
• Dynamiczne ładowanie 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 się na nią zdecydować.)
• 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 framework 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 wymuszania 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 pamięci RAM urządzenia, aby stworzyć bardziej stabilne i deterministyczne środowisko dla 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, szybkiego zużycia 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 "MemoryLimiter". Możesz też użyć profilowania opartego na aktywatorach z TRIGGER_TYPE_ANOMALY, aby uzyskać zrzuty stosu, 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 kontekstowe w IDE i w pełni zintegrowane z kodem źródłowym.

Mniejsze wykorzystanie 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 formatach urządzeń. Stwórzmy razem szybszą i bardziej niezawodną przyszłość ekosystemu Androida.

Reguły profilowania 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 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, reguła 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 reguła 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 korzystać z reguły, zapoznaj się z dokumentacją dotyczącą profilowania opartego na regułach.

    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();

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ć obrazów systemu 64-bitowego z emulatorem Androida w Android Studio.

Jeśli obecnie uczestniczysz w programie testów beta Androida, otrzymasz aktualizację bezprzewodową 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 przedpremierowej Android Studio (Panda). Gdy wszystko skonfigurujesz, wykonaj te czynności:

• Skompiluj aplikację z nowym pakietem 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 wydawniczego Androida 17 będziemy regularnie aktualizować obrazy systemu w wersji przedpremierowej lub beta oraz pakiet SDK. Po zainstalowaniu wersji beta będziesz automatycznie otrzymywać przyszłe aktualizacje bezprzewodowo dla wszystkich kolejnych wersji przedpremierowych 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 na kanale Canary, czy deweloperem aplikacji testującym wersję beta 4, dołącz do naszych społeczności i przesyłaj opinie. Słuchamy.