Zmiany w działaniu Androida 7.0

Oprócz nowych funkcji i możliwości Androida 7.0 obejmuje różne zmiany w działaniu systemu i interfejsu API. Ten dokument Wyróżniamy najważniejsze zmiany, o których należy pamiętać i które warto wziąć pod uwagę. w Twoich aplikacjach.

Jeśli masz już opublikowaną aplikację na Androida, pamiętaj, że Twoja aplikacja te zmiany na platformie.

Bateria i pamięć

Android 7.0 obejmuje zmiany w działaniu systemu mające na celu wydłużenie czasu pracy na baterii urządzeń i zmniejszyć wykorzystanie pamięci RAM. Te zmiany mogą wpłynąć na dostęp Twojej aplikacji do tych funkcji: zasobów systemowych, oraz sposobu, w jaki aplikacja współdziała z innymi aplikacjami, niejawne intencje.

Uśpienie

W Androidzie 6.0 (poziom interfejsu API 23) Uśpienie wydłuża czas pracy na baterii o odroczenie aktywności procesora i sieci, gdy użytkownik pozostawi urządzenie odłączone, nie ruszać się i mieć wyłączony ekran. Android 7.0 to jeszcze więcej – ulepszenie funkcji Uśpienie przez zastosowanie podzbioru ograniczeń dotyczących procesora i sieci gdy urządzenie jest odłączone i wyłączony ekran, ale nie zawsze nieruchome, np. gdy telefon znajduje się w kieszeni użytkownika.

Ilustracja pokazująca, jak Uśpienie stosuje pierwszy poziom ograniczenia aktywności systemu w celu wydłużenia czasu pracy na baterii

Rysunek 1. Ilustracja pokazująca, jak Uśpienie stosuje pierwszy poziom ograniczenia aktywności systemu w celu wydłużenia czasu pracy na baterii.

Gdy urządzenie jest zasilane z baterii, a ekran był przez określony czas wyłączony urządzenie przejdzie w tryb uśpienia i zastosuje pierwszy podzbiór ograniczeń. wyłącza dostęp aplikacji do sieci oraz opóźnia zadania i synchronizacje. Jeśli urządzenie jest nie rusza się przez określony czas po włączeniu trybu uśpienia, system stosuje pozostałe ograniczenia Uśpienia dla PowerManager.WakeLock, Alarmy AlarmManager, GPS i skanowania Wi-Fi. Niezależnie od czy stosowane są niektóre czy wszystkie ograniczenia uśpienia, system włączy przez krótkie okresy konserwacji, podczas których można używać aplikacji dostępu do sieci i może wykonywać wszelkie odroczone zadania/synchronizacje.

Ilustracja przedstawiająca, jak Uśpienie stosuje drugi poziom ograniczenia aktywności systemu po określonym czasie nieaktywności urządzenia

Rysunek 2. Ilustracja przedstawiająca, jak Uśpienie stosuje drugi poziom ograniczenia aktywności systemu po określonym czasie nieaktywności urządzenia.

Pamiętaj, że włączenie ekranu lub podłączenie urządzenia wyłączy tryb uśpienia i usuwa ograniczenia przetwarzania. To dodatkowe działanie nie powoduje wpłynąć na rekomendacje i sprawdzone metody dostosowywania aplikacji do poprzednich wersji Uśpienia wprowadzonej w Androidzie 6.0 (poziom interfejsu API 23), jak omówiliśmy w Optymalizacja pod kątem funkcji Uśpienie i Czuwanie aplikacji Nadal jednak postępuj zgodnie z tymi zaleceniami, np. korzystaj z Komunikacji w chmurze Firebase (FCM), wysyłać i odbierać wiadomości oraz planować aktualizacje, dodatkowe działanie funkcji Uśpienie.

Projekt Svelte: optymalizacje w tle

W Androidzie 7.0 wykasowano 3 niejawne komunikaty, aby zoptymalizować obie wykorzystanie pamięci i zużycia energii. Ta zmiana jest niezbędna, ponieważ często uruchamiają aplikacje, które zarejestrowały się, aby ich nasłuchiwać w tle. Usunięcie tych transmisji może znacząco przynieść korzyści urządzeniu wydajności i wrażeń użytkownika.

Na urządzeniach mobilnych często zmienia się łączność, np. podczas przenoszenia między Wi-Fi a mobilną transmisją danych. Obecnie aplikacje mogą monitorować zmiany w z łącznością, rejestrując odbiornik na potrzeby domniemanego przesyłania CONNECTIVITY_ACTION pliku manifestu. Wiele aplikacji rejestruje się, by odbierać ten komunikat, dlatego przełącznik sieci może sprawić, że wszystkie te urządzenia wybudzą się i przetworzą transmisję raz.

Podobnie w poprzednich wersjach Androida aplikacje mogły się rejestrować, aby odbierać pośrednie komunikaty ACTION_NEW_PICTURE i ACTION_NEW_VIDEO z innych aplikacji, na przykład Kamera. Gdy użytkownik zrobi zdjęcie za pomocą aplikacji Aparat, te aplikacje zostaną wybudzone do przetworzenia transmisji.

Aby eliminować te problemy, Android 7.0 stosuje te zasady optymalizacje:

Jeśli aplikacja używa którejkolwiek z tych intencji, usuń zależności jak najszybciej, aby można było prawidłowo kierować reklamy na urządzenia z Androidem 7.0. Platforma Androida udostępnia kilka rozwiązań, które pozwalają ograniczyć potrzebę tych niejawnych przekazów. Na przykład interfejs API JobScheduler zapewnia solidny mechanizm planowania operacji sieciowych w określonych warunkach, takich jak połączenie z bez pomiaru, są spełnione. Możesz nawet używać JobScheduler, aby reagować na zmiany w dostawcach treści.

Więcej informacji o optymalizacji w tle w Androidzie 7.0 (poziom interfejsu API 24) i dostosowania aplikacji znajdziesz w sekcji Informacje ogólne Optymalizacje.

Zmiany uprawnień

Android 7.0 zawiera zmiany uprawnień, które mogą mieć wpływ na Twoją aplikację.

Zmiany uprawnień systemu plików

Aby zwiększyć bezpieczeństwo plików prywatnych, katalog prywatny aplikacje kierowane na Androida 7.0 lub nowszego mają ograniczony dostęp (0700). To ustawienie zapobiega wyciekowi metadanych prywatnych plików, np. ich rozmiaru lub istnienia. Ta zmiana uprawnień ma wiele skutków ubocznych:

Udostępnianie plików między aplikacjami

W przypadku aplikacji kierowanych na Androida 7.0 platforma Androida wymusza zasady interfejsu API StrictMode zabraniające ujawniania identyfikatorów URI file:// poza aplikacją. Jeśli intencja zawierająca identyfikator URI pliku opuści aplikację, przestanie ona działać. z wyjątkiem FileUriExposedException.

Aby udostępniać pliki między aplikacjami, wysyłaj identyfikator URI content:// i przyznaj tymczasowe uprawnienia dostępu do identyfikatora URI. Najłatwiejszym sposobem przyznania tego uprawnienia jest za pomocą klasy FileProvider. Więcej informacji na temat konfiguracji uprawnień i udostępniania plików, Więcej informacji: Udostępnianie plików.

Udoskonalone ułatwienia dostępu

Android 7.0 zawiera zmiany, które mają na celu dla użytkowników niedowidzących i niedowidzących. Te zmiany powinny zwykle nie wymagają wprowadzania zmian w kodzie aplikacji, jednak warto sprawdzić, tych funkcji i przetestować je w aplikacji, aby ocenić potencjalny wpływ na użytkowników i uzyskiwanie dodatkowych informacji.

Powiększenie ekranu

Android 7.0 umożliwia użytkownikom ustawianie rozmiaru wyświetlacza, który umożliwia powiększenie lub zwinie wszystkie elementy na ekranie, aby poprawić dostępność na urządzeniu dla użytkowników niedowidzących. Użytkownicy nie mogą powiększać ekranu poza minimalnym ekranem szerokość sw320dp – szerokość typowej średniej wielkości telefonu Nexus 4.

Ekran pokazujący niepowiększony wyświetlacz urządzenia z obrazem systemu Android 7.0
Ekran pokazujący efekt zwiększenia rozmiaru wyświetlacza urządzenia z obrazem systemu Android 7.0

Rysunek 3. Na ekranie po prawej stronie widać efekt działania zwiększenie rozmiaru wyświetlacza na urządzeniu z Androidem 7.0.

Gdy układ urządzenia się zmieni, system powiadomi o tym uruchomione aplikacje w następujący sposób:

  • Jeśli aplikacja jest kierowana na interfejs API na poziomie 23 lub niższym, system automatycznie wszystkich procesów w tle. Oznacza to, że jeśli użytkownik przejdzie otworzyć ekran Ustawienia i zmienić Rozmiar interfejsu, system zamyka aplikację jak w sytuacji braku pamięci. Jeśli aplikacja ma jakiś pierwszy plan system powiadamia te procesy o zmianie konfiguracji, opisane w sekcji Obsługa zmiany czasu działania, tak jak w przypadku zmiany orientacji urządzenia.
  • Jeśli aplikacja jest kierowana na Androida 7.0, wszystkie jej procesy (na pierwszym planie i w tle) są powiadamiane o zmianie konfiguracji jako opisane w sekcji Obsługa Zmiany w środowisku wykonawczym.

W większości aplikacji nie trzeba wprowadzać żadnych zmian, aby obsługiwać tę funkcję, są zgodne ze sprawdzonymi metodami dotyczącymi Androida. Konkretne rzeczy, które należy sprawdzić:

  • Przetestuj aplikację na urządzeniu o szerokości ekranu sw320dp aby dbać o jego skuteczność.
  • Gdy zmieni się konfiguracja urządzenia, zaktualizuj ustawienia interfejsu zależne od gęstości informacji zapisanych w pamięci podręcznej, takich jak mapy bitowe zapisane w pamięci podręcznej lub zasoby wczytane z Sprawdź, czy konfiguracja się zmieniła po wznowieniu aplikacji ze wstrzymanego stanu.

    Uwaga: jeśli przechowujesz w pamięci podręcznej dane zależne od konfiguracji, Dobrym pomysłem jest dodanie odpowiednich metadanych, np. odpowiedniego ekranu rozmiaru lub gęstości pikseli. Zapisanie tych metadanych umożliwi: Zdecyduj, czy po konfiguracji trzeba odświeżyć dane w pamięci podręcznej .

  • Unikaj określania wymiarów za pomocą jednostek pikseli, ponieważ nie są one skalowane gęstości ekranu. Zamiast tego określ wymiary niezależne od gęstości pikseli (dp).

Ustawienia widoczności w kreatorze konfiguracji

Android 7.0 zawiera ustawienia widoczności na ekranie powitalnym, skonfiguruj na nowym urządzeniu te ustawienia ułatwień dostępu: Gest powiększenia, Rozmiar czcionki, Rozmiar wyświetlacza i TalkBack Ta zmiana zwiększa widoczność błędów związanych z różnymi ustawieniami ekranu. Do ocenić wpływ tej funkcji, przetestuj aplikacje za pomocą tych włączono ustawienia. Odpowiednie ustawienia znajdziesz w sekcji Ustawienia > Ułatwienia dostępu.

Łączenie aplikacji NDK z bibliotekami platformy

Począwszy od Androida w wersji 7.0 system blokuje dynamiczne łączenie aplikacji. z bibliotekami innymi niż NK, które mogą spowodować awarię aplikacji. Ta zmiana w ma na celu zapewnienie spójności działania aplikacji na różnych platformach i na różnych urządzeniach. Nawet jeśli Twój kod nie łączy się z prywatnych, może się zdarzyć, że biblioteka statyczna innej firmy co może robić aplikacja. Dlatego wszyscy deweloperzy powinni się upewnić, ich aplikacje nie ulegają awarii na urządzeniach z Androidem 7.0. Jeśli aplikacja używa kodu natywnego, należy używać tylko publicznych interfejsów API NDK.

Aplikacja może próbować uzyskać dostęp do platformy prywatnej na 3 sposoby Interfejsy API:

  • Aplikacja ma bezpośredni dostęp do prywatnych bibliotek platformy. Należy zaktualizować dodaj do aplikacji własną kopię tych bibliotek lub użyj publicznych interfejsów API NDK.
  • Twoja aplikacja używa biblioteki zewnętrznej, która ma dostęp do platformy prywatnej biblioteki. Nawet jeśli masz pewność, że aplikacja nie ma dostępu do bibliotek prywatnych bezpośrednio, warto mimo to przetestować aplikację w takim scenariuszu.
  • Aplikacja odwołuje się do biblioteki, która nie jest uwzględniona w pliku APK. Dla: Może się tak zdarzyć, gdy próbujesz użyć własnej kopii OpenSSL, ale zapomniałeś dodać go do pliku APK aplikacji. Aplikacja może działać normalnie w różnych wersjach platformy Android, która zawiera libcrypto.so. Aplikacja może ulegać awarii w późniejszych wersjach Androida, które nie zawierają tej biblioteki (na przykład z Androidem 6.0 i nowszym). Aby rozwiązać ten problem, połącz w pakiet biblioteki inne niż NDK z pakietem APK.

Aplikacje nie powinny używać bibliotek natywnych, które nie zostały uwzględnione w NDK, ponieważ mogą się zmienić lub zostać usunięte w różnych wersjach Androida. przejście z OpenSSL na BoringSSL jest przykładem takiej zmiany. Oprócz tego: ponieważ nie ma wymagań dotyczących zgodności bibliotek platformy, które nie które wchodzi w skład NDK, różne urządzenia mogą oferować różne poziomy zgodność.

Aby zmniejszyć wpływ, jaki to ograniczenie może obecnie mieć opublikowane aplikacje, czyli zbiór bibliotek, które są używane w znacznym stopniu – taki jak libandroid_runtime.so, libcutils.so, libcrypto.so i libssl.so – są tymczasowo dostępne w Androidzie 7.0 (poziom API 24) w przypadku aplikacji kierowanych na interfejs API na poziomie 23 lub obniżysz się. Jeśli aplikacja wczyta jedną z tych bibliotek, logcat wygeneruje ostrzeżenie. a na urządzeniu docelowym pojawi się powiadomienie. Jeśli widzisz te należy zaktualizować aplikację, tak aby zawierała lub tylko publicznych interfejsów API NDK. Kolejne wersje Androida może całkowicie ograniczyć korzystanie z bibliotek prywatnych i spowodować do awarii.

Wszystkie aplikacje generują błąd środowiska wykonawczego, gdy wywołują interfejs API, który nie jest żadnym z nich publiczne ani tymczasowo dostępne. Wynika to z tego, System.loadLibrary i dlopen(3) wracają NULL i może spowodować awarię aplikacji. Przejrzyj kod aplikacji umożliwiający usunięcie wykorzystania interfejsów API platformy prywatnej i dokładne testowanie aplikacji na urządzeniu lub emulatorze z Androidem 7.0 (poziom interfejsu API 24). Jeśli jesteś Jeśli nie masz pewności, czy Twoja aplikacja używa bibliotek prywatnych, możesz sprawdzić tag logcat, aby zidentyfikować błąd środowiska wykonawczego.

W tabeli poniżej opisano zachowanie, którego możesz się spodziewać po w zależności od wykorzystania prywatnych bibliotek natywnych i docelowego interfejsu API aplikacji poziom (android:targetSdkVersion).

Biblioteki Docelowy poziom interfejsu API Dostęp w czasie działania za pomocą dynamicznego kreatora linków Działanie Androida 7.0 (poziom interfejsu API 24) Przyszłe zachowanie platformy Androida
NDK publiczny Dowolny Ułatwienia dostępu Działa zgodnie z oczekiwaniami Działa zgodnie z oczekiwaniami
Prywatne (tymczasowo dostępne biblioteki prywatne) 23 lub mniej Tymczasowo dostępny Działa zgodnie z oczekiwaniami, ale jest wyświetlane ostrzeżenie logcat. Błąd środowiska wykonawczego
Prywatne (tymczasowo dostępne biblioteki prywatne) 24 lub więcej Z ograniczonym dostępem Błąd środowiska wykonawczego Błąd środowiska wykonawczego
Prywatne (inne) Dowolny Z ograniczonym dostępem Błąd środowiska wykonawczego Błąd środowiska wykonawczego

Sprawdzanie, czy aplikacja używa bibliotek prywatnych

Aby ułatwić wykrywanie problemów z wczytywaniem bibliotek prywatnych, narzędzie logcat może wygenerować lub błędu podczas działania. Na przykład: jeśli aplikacja jest kierowana na interfejs API na poziomie 23 lub niższą wersję i próbuje uzyskać dostęp do prywatnej biblioteki na urządzeniu z Androidem 7.0, może wyświetlić się ostrzeżenie podobne do tego: 

03-21 17:07:51.502 31234 31234 W linker  : library "libandroid_runtime.so"
("/system/lib/libandroid_runtime.so") needed or dlopened by
"/data/app/com.popular-app.android-2/lib/arm/libapplib.so" is not accessible
for the namespace "classloader-namespace" - the access is temporarily granted
as a workaround for http://b/26394120

Te ostrzeżenia logcat informują, która biblioteka próbuje uzyskać dostęp do API platformy prywatnej, ale nie spowoduje awarii aplikacji. Jeśli aplikacja są kierowane na interfejs API na poziomie 24 lub wyższym, jednak logcat generuje a aplikacja może ulec awarii: 

java.lang.UnsatisfiedLinkError: dlopen failed: library "libcutils.so"
("/system/lib/libcutils.so") needed or dlopened by
"/system/lib/libnativeloader.so" is not accessible for the namespace
"classloader-namespace"
  at java.lang.Runtime.loadLibrary0(Runtime.java:977)
  at java.lang.System.loadLibrary(System.java:1602)

Te dane wyjściowe logcat mogą być też widoczne, jeśli aplikacja korzysta z bibliotek innych firm które dynamicznie łączą się z interfejsami API platformy prywatnej. Narzędzie Readelf w interfejsie Android 7.0DK umożliwia generowanie listy wszystkich dynamicznie połączonych elementów udostępnianych i bibliotece danego pliku .so, uruchamiając to polecenie: 

aarch64-linux-android-readelf -dW libMyLibrary.so

Zaktualizuj aplikację

Oto kilka czynności, które możesz wykonać, aby naprawić tego typu błędy i zadbaj o to, żeby aplikacja nie uległa awarii przy kolejnych aktualizacjach platformy:

  • Jeśli Twoja aplikacja używa prywatnych bibliotek platformy, zaktualizuj ją, dodając do niej mieć własną kopię tych bibliotek lub użyć publicznych interfejsów API NDK.
  • Jeśli Twoja aplikacja korzysta z biblioteki innej firmy, która ma dostęp do symboli prywatnych, skontaktuj się z nami autor biblioteki, aby ją zaktualizować.
  • Pamiętaj, aby wraz z plikiem APK spakować wszystkie biblioteki inne niż NDK.
  • Używaj standardowych funkcji JNI zamiast getJavaVM i getJNIEnv od: libandroid_runtime.so: 
    AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h>
AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or
JavaVM::AttachCurrentThread from <jni.h>.
  • Użyj __system_property_get zamiast prywatnej lokalizacji property_get symbol z kolumny libcutils.so. Aby to zrobić, użyj funkcji __system_property_get z następującymi wartościami: 
    #include <sys/system_properties.h>

    Uwaga: dostępność i zawartość właściwości systemu to nie były testowane przez CTS. Lepszym rozwiązaniem jest unikanie stosowania tych usług.

  • Użyj lokalnej wersji symbolu SSL_ctrl z: libcrypto.so. Na przykład połącz statycznie libcyrpto.a w .so lub dodaj dynamicznie połączoną wersję libcrypto.so z pakietu BoringSSL/OpenSSL i spakuj ją w pakiecie APK.

Android for Work

Android 7.0 zawiera zmiany dotyczące aplikacji kierowanych na Android for Work, w tym zmiany w instalacji certyfikatu, resetowanie hasła, użytkownik dodatkowy zarządzania i dostępu do identyfikatorów urządzeń. Jeśli tworzysz aplikacje dla środowisk Android for Work, sprawdź te zmiany i wprowadź odpowiednio do potrzeb aplikacji.

  • Musisz zainstalować delegowany instalator certyfikatów, zanim DPC będzie mógł ustawić tę opcję . W przypadku aplikacji profilowych i aplikacji właściciela urządzenia kierowanych na Androida 7.0 (poziom API 24): należy zainstalować delegowany instalator certyfikatów przed zasadami dotyczącymi urządzeń wywołania kontrolera (DPC) DevicePolicyManager.setCertInstallerPackage() Jeśli instalator nie jest zainstalowany, system wysyła komunikat IllegalArgumentException
  • Resetowanie ograniczeń dotyczących haseł dla administratorów urządzeń ma teraz zastosowanie do profilu właścicieli. Administratorzy urządzeń nie mogą już używać DevicePolicyManager.resetPassword(), aby wyczyścić lub zmienić hasła już ustawionych. Administratorzy urządzenia nadal mogą ustawić hasło, ale tylko gdy urządzenie nie ma hasła, kodu PIN ani wzoru.
  • Właściciele urządzeń i profili mogą zarządzać kontami nawet wtedy, gdy obowiązują ograniczenia ustawiony. Właściciele urządzeń i profili mogą wywoływać interfejsy API do zarządzania kontem nawet jeśli obowiązują ograniczenia użytkownika DISALLOW_MODIFY_ACCOUNTS.
  • Właściciele urządzeń mogą łatwiej zarządzać użytkownikami pomocniczymi. Gdy urządzenie jest działające w trybie właściciela urządzenia, ograniczenie DISALLOW_ADD_USER jest ustawiana automatycznie. Uniemożliwia to użytkownikom tworzenie niezarządzanych zasobów dodatkowych użytkowników. Ponadto CreateUser() i Metody createAndInitializeUser() zostały wycofane; nowy Zastępuje je metoda DevicePolicyManager.createAndManageUser().
  • Właściciele urządzeń mają dostęp do ich identyfikatorów. Właściciel urządzenia ma dostęp do Adres MAC sieci Wi-Fi urządzenia przy użyciu DevicePolicyManager.getWifiMacAddress() Jeśli Wi-Fi nigdy została włączona na urządzeniu, ta metoda zwraca wartość null.
  • Ustawienie Tryb pracy kontroluje dostęp do aplikacji służbowych. Gdy tryb pracy jest wyłączony, Menu z aplikacjami oznacza, że aplikacje służbowe są niedostępne, wyszarzone. Włączam w trybie roboczym przywraca normalne działanie.
  • W przypadku instalowania pliku PKCS #12 zawierającego łańcuch certyfikatów klienta i odpowiedni klucz prywatny z interfejsu ustawień, certyfikat CA w interfejsie łańcuch plików nie jest już zainstalowany w magazynie zaufanych danych uwierzytelniających. Dzięki temu nie wpływa na wynik działania KeyChain.getCertificateChain(), gdy aplikacje próbują pobrać klienta łańcucha certyfikatów. Jeśli jest wymagany, należy zainstalować certyfikat CA do pamięci zaufanych danych logowania w interfejsie Ustawienia osobno, przy użyciu Format z kodowaniem DER z rozszerzeniem .crt lub .cer.
  • Począwszy od Androida 7.0 zarządzanie rejestracją odcisku palca i miejscem na dane jest zarządzane na użytkownika. Jeśli klient Device Policy (DPC) właściciela profilu jest kierowany na poziom API 23 (lub starszej) na urządzeniu z Androidem 7.0 (poziom interfejsu API 24), użytkownik musi nadal można ustawić odcisk palca na urządzeniu, ale aplikacje służbowe nie dostęp do odcisku palca na urządzeniu. Gdy DPC kieruje reklamy na interfejs API na poziomie 24 lub wyższym, użytkownik może ustawić użyj odcisku palca specjalnie do pracy w profilu służbowym. W tym celu wybierz kolejno Ustawienia > Bezpieczeństwo > Bezpieczeństwo profilu służbowego
  • Obecny stan szyfrowania ENCRYPTION_STATUS_ACTIVE_PER_USER: zwrócone przez DevicePolicyManager.getStorageEncryptionStatus(), użytkownikowi wskazuje, że szyfrowanie jest aktywne, a klucz szyfrowania jest powiązany z użytkownika. Nowy stan jest zwracany tylko wtedy, gdy DPC kieruje na interfejs API na poziomie 24 lub wyższym. W przypadku aplikacji kierowanych na wcześniejsze poziomy interfejsu API: ENCRYPTION_STATUS_ACTIVE nawet wtedy, gdy klucz szyfrowania jest przypisany do użytkownika lub profilu.
  • W Androidzie 7.0 kilka metod, które normalnie wpływają na cały zachowuje się inaczej, jeśli na urządzeniu jest zainstalowany profil służbowy z osobne zadanie służbowe. Zamiast wpływu na całe urządzenie, te funkcje mają zastosowanie tylko do profilu służbowego. (Pełną listę takich metod znajdziesz w dokumentacji DevicePolicyManager.getParentProfileInstance()). Przykład: DevicePolicyManager.lockNow() blokuje tylko profil służbowy, a nie zablokowanie całego urządzenia. W przypadku każdej z tych metod możesz pobrać przez wywołanie metody w instancji nadrzędnej DevicePolicyManager; można znaleźć tego rodzica przez Dzwonię pod numer DevicePolicyManager.getParentProfileInstance(). Jeśli na przykład zadzwonisz lockNow() instancji nadrzędnej całe urządzenie jest zablokowane.

Przechowywanie adnotacji

Android 7.0 zawiera błąd, który powodował, że widoczność adnotacji była ignorowana. Ten problem umożliwił środowisku wykonawczym dostęp do adnotacji, które nie powinny być dostępne w jaki sposób. Adnotacje obejmowały:

  • VISIBILITY_BUILD: ma być widoczny tylko w czasie kompilacji.
  • VISIBILITY_SYSTEM: ma być widoczny w czasie działania, ale tylko dla bazowego systemu.

Jeśli Twoja aplikacja polegała na tym działaniu, dodaj zasadę przechowywania do adnotacji, które muszą być dostępne w czasie działania. Służą do tego @Retention(RetentionPolicy.RUNTIME).

Zmiany domyślnej konfiguracji TLS/SSL

Android 7.0 wprowadza te zmiany w domyślnej konfiguracji TLS/SSL używane przez aplikacje do obsługi HTTPS i innego ruchu TLS/SSL:

  • Zestawy szyfrów RC4 są teraz wyłączone.
  • Zestawy szyfrów CHACHA20-POLY1305 są teraz włączone.

Domyślnie wyłączone RC4 może prowadzić do awarii HTTPS lub TLS/SSL gdy serwer nie negocjuje nowoczesnych zestawów szyfrów. Preferowaną metodą jest poprawienie konfiguracji serwera a także nowoczesne zestawy szyfrów i protokoły. Najlepiej TLSv1.2 i AES-GCM. powinna być włączona, a zestawy szyfrów Forward Secrecy (ECDHE) powinny być włączone i preferowane.

Możesz też zmodyfikować aplikację tak, aby używała niestandardowego interfejsu SSLSocketFactory do komunikacji z serwerem. w fabryce należy utworzyć SSLSocket w instancjach z niektórymi zestawami szyfrów wymaganymi przez serwer włączone oprócz domyślnych zestawów szyfrów.

Uwaga: te zmiany nie dotyczą WebView.

Aplikacje kierowane na Androida 7.0

Te zmiany w działaniu dotyczą wyłącznie aplikacji, na które są kierowane Androida 7.0 (poziom interfejsu API 24) lub nowszego. aplikacje kompatybilne z Androidem 7.0, lub ustaw targetSdkVersion na Androida 7.0 lub nowszego ich aplikacje do prawidłowej obsługi tych zachowań (w stosownych przypadkach).

Zmiany serializacji

Android 7.0 (poziom interfejsu API 24) naprawił błąd przy obliczaniu wartości domyślnej. serialVersionUID, który nie jest zgodny ze specyfikacją.

Klasy, które stosują Serializable i nie określono jawnego pola serialVersionUID, zauważy zmianę domyślnego identyfikatora serialVersionUID, co spowodowałoby wyjątek. ma być odrzucany przy próbie deserializacji instancji klasy, która została są zserializowane na wcześniejszej wersji lub serializowane przez aplikację kierowaną na wcześniejsze wersji. Komunikat o błędzie będzie wyglądał mniej więcej tak: 

local class incompatible: stream classdesc serialVersionUID = 1234, local class serialVersionUID = 4567

Aby rozwiązać te problemy, musisz dodać pole serialVersionUID do każdej klasy, której dotyczy problem, wartością stream classdesc serialVersionUID z komunikatu o błędzie, np. 1234 in tę sprawę. Zmiana ta jest zgodna ze wszystkimi zaleceniami sprawdzonych metod w którym piszesz kod serializacji. Działa on ze wszystkimi wersjami Androida.

Usunięty błąd był związany z obecnością obrazów metod inicjowania, np. <clinit>. Według o obecności lub braku statycznej metody inicjowania w funkcji będzie mieć wpływ na domyślną wartość serialVersionUID obliczoną dla tej klasy. Przed naprawieniem błędu obliczenia obejmowały też sprawdzenie klasy superklasy pod kątem wartości static inicjator, jeśli klasa go nie miała.

Należy doprecyzować, że ta zmiana nie dotyczy aplikacji kierowanych na interfejs API na poziomie 23 lub niższe, klasy, które mają pole lub klasy serialVersionUID ze statyczną metodą inicjowania.

Inne ważne kwestie

  • Jeśli aplikacja działa na Androidzie 7.0, ale jest kierowana na niższy poziom interfejsu API, a użytkownik zmieni rozmiar wyświetlacza, proces aplikacji zatrzymuje się. Aplikacja musi być w stanie właściwie radzić sobie z tą sytuacją. Jeśli tego nie zrobisz, urządzenie ulegnie awarii. gdy użytkownik przywróci je z Ostatnich.

    Przetestuj aplikację, aby upewnić się, że takie zachowanie nie występuje. Aby to zrobić, wywołaj identyczną awarię podczas ręcznego zamykania aplikacji przez DDMS.

    Aplikacje kierowane na Androida 7.0 (poziom interfejsu API 24) i nowsze nie są automatycznie znika po zmianach gęstości; ale mogą też nie reagować zmian konfiguracji.

  • Aplikacje na Androidzie 7.0 powinny płynnie obsługiwać zmiany konfiguracji, i nie powinien ulegać awarii przy kolejnych uruchomieniach. Możesz sprawdzić działanie aplikacji zmieniając rozmiar czcionki (Ustawienia > Wyświetlacz > Rozmiar czcionki), a następnie przywrócenie aplikację z sekcji Ostatnie.
  • Z powodu błędu we wcześniejszych wersjach Androida system nie oflagował pisma do gniazda TCP w wątku głównym jako naruszenie trybu ścisłego. Android 7.0 naprawia ten błąd. Aplikacje, które wykazują takie zachowanie, zgłaszają teraz android.os.NetworkOnMainThreadException. Ogólnie wykonywanie operacji sieciowych w wątku głównym nie jest dobrym pomysłem, ponieważ mają zwykle duże opóźnienie, które powoduje błędy ANR i zacinanie.
  • Domyślna rodzina metod Debug.startMethodTracing() to teraz przechowywanie danych wyjściowych w katalogu dla określonego pakietu w pamięci współdzielonej, zamiast na najwyższym poziomie. jej pamięci. Oznacza to, że aplikacje nie muszą już prosić o uprawnienie WRITE_EXTERNAL_STORAGE, aby korzystać z tych interfejsów API.
  • Wiele interfejsów API platform zaczęło sprawdzać wysyłane duże ładunki w Binder transakcjach oraz system zwraca teraz TransactionTooLargeExceptions jako RuntimeExceptions, zamiast ich dyskretnego logowania lub blokowania. Jeden typowym przykładem jest przechowywanie zbyt dużej ilości danych w Activity.onSaveInstanceState(), co powoduje, że ActivityThread.StopInfo wysyła zapytanie RuntimeException, gdy aplikacja jest kierowana na Androida 7.0.
  • Jeśli aplikacja publikuje Runnable zadań w View, View nie jest dołączone do okna, system umieszcza zadanie Runnable w kolejce na liście View; zadanie Runnable nie zostanie wykonane, dopóki Podłączono plik View do okna. To działanie rozwiązuje następujące błędy:
    • Jeśli aplikacja została opublikowana w temacie View z innego wątku niż zamierzony w wątku interfejsu w oknie, w efekcie Runnable może zostać uruchomiony w niewłaściwym wątku.
    • Jeśli zadanie Runnable zostało opublikowane w wątku innym niż w wątku loopera, aplikacja może udostępnić zadanie Runnable.
  • Jeśli aplikacja na Androida 7.0 z DELETE_PACKAGES próbuje usunąć pakiet, ale został on zainstalowany przez inną aplikację, system wymaga potwierdzenia przez użytkownika. W takim przypadku aplikacje powinny oczekiwać, STATUS_PENDING_USER_ACTION jako stan zwrotu podczas wywołania PackageInstaller.uninstall()
  • Dostawca JCA o nazwie Crypto został wycofany, ponieważ jego jedyna algorytm SHA1PRNG jest kryptograficznie słaby. Aplikacje nie mogą już używać SHA1PRNG do (niebezpiecznie) pobiera klucze, ponieważ ten dostawca nie jest już i dostępności informacji. Więcej informacji znajdziesz na blogu post Zabezpieczenia „Crypto” dostawca wycofany na Androidzie N.