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](https://developer.android.google.cn/static/images/android-7.0/doze-diagram-1.png?authuser=8&hl=pl)
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](https://developer.android.google.cn/static/images/android-7.0/doze-diagram-2.png?authuser=8&hl=pl)
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:
- Aplikacje kierowane na Androida 7.0 (poziom interfejsu API 24) i nowsze wersje nie otrzymują
CONNECTIVITY_ACTION
nadaje się, jeśli: określić odbiornik w pliku manifestu. Aplikacje będą nadal będą otrzymywaćCONNECTIVITY_ACTION
transmisję, jeśli zostaną zarejestrowane jegoBroadcastReceiver
zContext.registerReceiver()
a kontekst wciąż jest aktualny. - System nie wysyła już transmisji
ACTION_NEW_PICTURE
aniACTION_NEW_VIDEO
. Ta optymalizacja dotyczy wszystkich aplikacji, nie tylko tych kierowanych na Androida 7.0.
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:
-
Właściciel nie powinien już złagodzić uprawnień dotyczących plików prywatnych,
a także próbą zrobienia tego za pomocą
MODE_WORLD_READABLE
lubMODE_WORLD_WRITEABLE
, wywołaSecurityException
Uwaga: to ograniczenie nie jest jeszcze w pełni egzekwowane. Aplikacje mogą nadal modyfikować uprawnienia do katalogu prywatnego za pomocą natywne interfejsy API lub interfejs API
File
. Zdecydowanie jednak Zniechęcasz do złagodzenia uprawnień do katalogu prywatnego. -
Przekazywanie identyfikatorów URI
file://
poza domenę pakietu może spowodować opuszczenie tagu z odbiornikiem z niedostępną ścieżką. W związku z tym próby pominięcia Aktywator URIfile://
FileUriExposedException
Zalecany sposób udostępniania zawartości prywatnego pliku korzysta z elementuFileProvider
. -
DownloadManager
nie może już udostępniać prywatnie zapisane pliki według nazwy. Starsze aplikacje mogą mieć niedostępna ścieżka przy próbie uzyskania dostępu do:COLUMN_LOCAL_FILENAME
. Kierowanie na aplikacje Android 7.0 lub nowszy wyzwalaSecurityException
, gdy próby uzyskania dostępuCOLUMN_LOCAL_FILENAME
starszych aplikacji, które ustawiają lokalizację pobierania na publiczną lokalizację przez za pomocąDownloadManager.Request.setDestinationInExternalFilesDir()
lubDownloadManager.Request.setDestinationInExternalPublicDir()
ma nadal dostęp do ścieżki wCOLUMN_LOCAL_FILENAME
, jednak to zdecydowanie odradzamy. preferowany sposób uzyskiwania dostępu do pliku; widoczne przezDownloadManager
używaContentResolver.openFileDescriptor()
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](https://developer.android.google.cn/static/images/android-7.0/screen-zoom-1.png?authuser=8&hl=pl)
![Ekran pokazujący efekt zwiększenia rozmiaru wyświetlacza urządzenia z obrazem systemu Android 7.0](https://developer.android.google.cn/static/images/android-7.0/screen-zoom-2.png?authuser=8&hl=pl)
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
igetJNIEnv
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 lokalizacjiproperty_get
symbol z kolumnylibcutils.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 statycznielibcyrpto.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 komunikatIllegalArgumentException
- 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. PonadtoCreateUser()
i MetodycreateAndInitializeUser()
zostały wycofane; nowy Zastępuje je metodaDevicePolicyManager.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 przezDevicePolicyManager.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ędnejDevicePolicyManager
; można znaleźć tego rodzica przez Dzwonię pod numerDevicePolicyManager.getParentProfileInstance()
. Jeśli na przykład zadzwoniszlockNow()
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 uprawnienieWRITE_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 terazTransactionTooLargeExceptions
jakoRuntimeExceptions
, zamiast ich dyskretnego logowania lub blokowania. Jeden typowym przykładem jest przechowywanie zbyt dużej ilości danych wActivity.onSaveInstanceState()
, co powoduje, żeActivityThread.StopInfo
wysyła zapytanieRuntimeException
, gdy aplikacja jest kierowana na Androida 7.0. -
Jeśli aplikacja publikuje
Runnable
zadań wView
,View
nie jest dołączone do okna, system umieszcza zadanieRunnable
w kolejce na liścieView
; zadanieRunnable
nie zostanie wykonane, dopóki Podłączono plikView
do okna. To działanie rozwiązuje następujące błędy: -
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łaniaPackageInstaller.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.