Android 7.0 dla deweloperów

Android 7.0 Nougat oferuje użytkownikom i deweloperom wiele nowych funkcji i możliwości. W tym dokumencie znajdziesz informacje o nowościach dla deweloperów.

Zapoznaj się z zmianami w działaniu Androida 7.0, aby dowiedzieć się, w jakich obszarach zmiany dotyczące platformy mogą wpływać na Twoje aplikacje.

Aby dowiedzieć się więcej o funkcjach dla użytkowników Androida 7.0, wejdź na www.android.com.

Obsługa trybu wielu okien

W Androidzie 7.0 wprowadzamy na platformie nową, pożądaną funkcję wielozadaniowości – obsługę wielu okien.

Użytkownicy mogą teraz otwierać 2 aplikacje na ekranie jednocześnie.

  • Na telefonach i tabletach z Androidem 7.0 użytkownicy mogą w trybie podzielonego ekranu uruchomić 2 aplikacje obok siebie lub jedną nad drugą. Użytkownicy mogą zmieniać rozmiar aplikacji, przeciągając między nimi linię podziału.
  • Na urządzeniach z Androidem TV aplikacje mogą przechodzić w tryb obrazu w obrazie, co pozwala im wyświetlać treści, gdy użytkownik przegląda inne aplikacje lub wchodzi z nimi w interakcje.
Aplikacje mobilne w trybie podzielonego ekranu

Rysunek 1. Aplikacje działające w trybie podzielonego ekranu.

Zwłaszcza na tabletach i innych urządzeniach z większymi ekranami obsługa trybu wielu okien zapewnia nowe sposoby angażowania użytkowników. Możesz nawet włączyć przeciąganie i upuszczanie w aplikacji, aby umożliwić użytkownikom wygodne przeciąganie treści do lub z aplikacji. To świetny sposób na zwiększenie wygody użytkowników.

Możesz łatwo dodać do aplikacji obsługę trybu wielu okien i skonfigurować sposób jej obsługi. Możesz na przykład określić minimalne dopuszczalne wymiary aktywności, aby uniemożliwić użytkownikom zmianę rozmiaru aktywności poniżej tego rozmiaru. Możesz też wyłączyć w swojej aplikacji wyświetlanie w trybie wielu okien, dzięki czemu system będzie wyświetlał aplikację tylko w trybie pełnoekranowym.

Więcej informacji znajdziesz w dokumentacji dla deweloperów obsługi wielu okien.

Ulepszenia powiadomień

W Androidzie 7.0 zmieniliśmy powiadomienia, aby ich obsługa była łatwiejsza i szybsza. Oto niektóre zmiany:

  • Aktualizacje szablonów: aktualizujemy szablony powiadomień, aby jeszcze bardziej zwrócić uwagę na baner powitalny i awatara. Deweloperzy będą mogli korzystać z nowych szablonów przy niewielkich zmianach w kodzie.
  • Dostosowywanie stylu wiadomości: więcej etykiet interfejsu powiązanych z powiadomieniami możesz dostosować za pomocą klasy MessagingStyle. Możesz skonfigurować wiadomość, tytuł wątku i widok treści.
  • Grupowanie powiadomień: system może grupować wiadomości, np. według tematu wiadomości, i wyświetlać grupę. Użytkownik może wykonać na nich działania, takie jak Odrzuć lub Archiwizuj. Jeśli masz zaimplementowane powiadomienia na Androidzie Wear, prawdopodobnie znasz ten model.
  • Bezpośrednia odpowiedź: w przypadku aplikacji do komunikacji w czasie rzeczywistym system Android obsługuje odpowiedzi w tekście, dzięki czemu użytkownicy mogą szybko odpowiedzieć na SMS-a lub SMS-a bezpośrednio w interfejsie powiadomień.
  • Widoki niestandardowe: 2 nowe interfejsy API umożliwiają wykorzystanie dekoracji systemu, takich jak nagłówki powiadomień i działania, podczas korzystania z widoków niestandardowych w powiadomieniach.
Wyświetlanie na urządzeniu mobilnym powiadomień o połączonych wiadomościach
Urządzenie mobilne wyświetla powiadomienie o pojedynczej wiadomości
Urządzenie mobilne wyświetla odpowiedź na wiadomość w tekście w interfejsie powiadomień

Rysunek 2. Zbiorcze powiadomienia i bezpośrednia odpowiedź.

Aby dowiedzieć się, jak wdrożyć nowe funkcje, zapoznaj się z przewodnikiem dotyczącym powiadomień.

Kompilacja JIT/AOT prowadzona przez profil

W Androidzie 7.0 dodaliśmy kompilator Just in Time (JIT) z profilowaniem kodu do ART, dzięki czemu może on stale poprawiać wydajność uruchomionych aplikacji na Androida. Kompilator JIT uzupełnia obecny kompilator Ahead of Time (AOT) ART i pomaga poprawić wydajność działania, zaoszczędzić miejsce na dane oraz przyspieszyć aktualizacje aplikacji i systemu.

Kompilacja oparta na profilu pozwala ART zarządzać kompilacją AOT/JIT dla każdej aplikacji zgodnie z jej rzeczywistym użyciem oraz warunkami na urządzeniu. Na przykład ART przechowuje profil szybkich metod każdej aplikacji oraz może wstępnie kompilować i zapisywać w pamięci podręcznej te metody, aby zapewnić jak największą wydajność. Nie są skompilowane inne części aplikacji, dopóki nie zostaną one użyte.

Nie tylko poprawia wydajność najważniejszych części aplikacji, ale też kompilacja prowadzona przez profil pomaga zmniejszyć ogólną ilość pamięci RAM aplikacji, w tym powiązane pliki binarne. Ta funkcja jest szczególnie ważna na urządzeniach z małą ilością pamięci.

ART zarządza kompilacją prowadzoną przez profil w sposób, który minimalizuje jej wpływ na baterię urządzenia. Kompilacja odbywa się tylko wtedy, gdy urządzenie jest bezczynne i ładuje się, co pozwala zaoszczędzić czas i baterię, ponieważ wykonuje tę pracę z wyprzedzeniem.

Szybka ścieżka do instalacji aplikacji

Jedną z najbardziej wymiernych zalet kompilatora JIT ART jest szybkość instalacji aplikacji i aktualizacji systemu. Nawet duże aplikacje, których optymalizacja i instalacja na Androidzie 6.0 wymagała kilku minut, można teraz zainstalować w zaledwie kilka sekund. Aktualizacje systemu są również szybsze, ponieważ nie trzeba wykonywać dodatkowych czynności optymalizacyjnych.

Uśpienie w ruchu...

W Androidzie 6.0 wprowadziliśmy Doze – tryb systemu, który oszczędza baterię przez odłożenie działania procesora i sieci przez aplikacje, gdy urządzenie jest bezczynne – np. na stole lub w szufladzie.

Teraz w Androidzie 7.0 funkcja Doze idzie o krok dalej i oszczędza baterię, gdy jesteś poza domem. Gdy ekran jest wyłączony przez pewien czas i urządzenie jest odłączone, funkcja Doze stosuje do aplikacji podzbiór znanych ograniczeń procesora i sieci. Dzięki temu użytkownicy mogą oszczędzać baterię, nawet gdy mają urządzenie w kieszeni.

Ilustracja pokazująca, jak Uśpienie stosuje pierwszy poziom ograniczeń aktywności systemu, aby wydłużyć czas pracy na baterii

Rysunek 3. Uśpienie stosuje teraz ograniczenia, aby wydłużyć czas pracy baterii nawet wtedy, gdy urządzenie jest nieaktywne.

Na chwilę po wyłączeniu ekranu urządzenie na baterii ogranicza dostęp do sieci i opóźnia zadania oraz synchronizację. W trakcie krótkich okresów konserwacji aplikacje mają dostęp do sieci, a wszystkie ich odroczone zadania lub synchronizacje są wykonywane. Włączenie ekranu lub podłączenie urządzenia wycofuje urządzenie z trybu uśpienia.

Gdy urządzenie się nie rusza, a ekran jest wyłączony i przez pewien czas włączony na baterii, uśpienie stosuje pełne ograniczenia dotyczące procesora i sieci w przypadku alarmów PowerManager.WakeLock, AlarmManager i skanowań GPS/Wi-Fi.

Sprawdzone metody dostosowywania aplikacji do funkcji Uśpienie są takie same niezależnie od tego, czy urządzenie się rusza. Jeśli więc aplikacja została już zaktualizowana, nie musisz nic robić. Jeśli nie, już teraz zacznij dostosowywać swoją aplikację do funkcji Uśpienie.

Projekt Svelte: optymalizacje tła

Projekt Svelte to nieustanne dążenie do minimalizacji ilości pamięci RAM przez systemy i aplikacje w całym ekosystemie na różnych urządzeniach z Androidem. W Androidzie 7.0 Projekt Svelte koncentruje się na optymalizacji sposobu działania aplikacji w tle.

Przetwarzanie w tle to ważny element większości aplikacji. Właściwe korzystanie z niego może sprawić, że wrażenia użytkownika będą niesamowite – natychmiastowe, szybkie i dobrze dopasowane do kontekstu. Nieprawidłowo obsługiwane przetwarzanie w tle może niepotrzebnie zajmować pamięć RAM (i baterię) i wpływać na wydajność systemu przez inne aplikacje.

Od Androida 5.0 JobScheduler jest preferowanym sposobem wykonywania pracy w tle w sposób korzystny dla użytkowników. Aplikacje mogą planować zadania, a jednocześnie umożliwiać optymalizację systemu na podstawie warunków związanych z pamięcią, zasilaniem i połączeniem. JobScheduler zapewnia kontrolę i łatwość obsługi. Chcemy, aby wszystkie aplikacje z niego korzystały.

Możesz też skorzystać z usługi GCMNetworkManager, która wchodzi w skład Usług Google Play i oferuje podobne harmonogramy zadań, które są zgodne ze starszymi wersjami Androida.

Stale rozszerzamy funkcje JobScheduler i GCMNetworkManager, aby spełniały kolejne wymagania. Na przykład w Androidzie 7.0 możesz teraz planować pracę w tle na podstawie zmian u dostawców treści. Jednocześnie zaczynamy wycofywać niektóre starsze wzorce, które mogą zmniejszyć wydajność systemu, zwłaszcza na urządzeniach z małą ilością pamięci.

W Androidzie 7.0 usuwamy 3 często używane komunikaty pośrednie – CONNECTIVITY_ACTION, ACTION_NEW_PICTURE i ACTION_NEW_VIDEO, ponieważ mogą one wybudzać procesy w wielu aplikacjach jednocześnie i wykorzystywać pamięć oraz baterię. Jeśli Twoja aplikacja je otrzymuje, skorzystaj z Androida 7.0, aby przejść na JobScheduler i powiązane interfejsy API.

Szczegółowe informacje znajdziesz w dokumentacji optymalizacji w tle.

Widok powierzchni

Android 7.0 wprowadza ruch synchroniczny do klasy SurfaceView, co w niektórych przypadkach zapewnia większą wydajność baterii niż TextureView. Podczas renderowania treści wideo i 3D aplikacje z przewijaniem i animowaną pozycją wideo zużywają mniej energii z użyciem SurfaceView niż TextureView.

Klasa SurfaceView umożliwia bardziej ekonomiczne komponowanie na ekranie, ponieważ jest komponowane na specjalnym sprzęcie i innym niż zawartość okna aplikacji. W rezultacie tworzy mniej kopii pośrednich niż TextureView.

Pozycja treści obiektu SurfaceView jest teraz aktualizowana synchronicznie z zawartością aplikacji, która zawiera. Jednym z wyników tej zmiany jest to, że proste tłumaczenia lub skalę filmu odtwarzanego na urządzeniu SurfaceView nie powodują już wyświetlania czarnych pasów przy poruszającym się widoku.

Od Androida 7.0 zdecydowanie zalecamy oszczędzanie energii przez używanie SurfaceView zamiast TextureView.

Oszczędzanie danych

Oszczędzanie danych w Ustawieniach

Rysunek 4. Oszczędzanie danych w Ustawieniach.

Z czasem użytkowania urządzenia mobilnego koszt abonamentu na komórkową transmisję danych zwykle przewyższa koszt samego urządzenia. Dla wielu użytkowników komórkowa transmisja danych jest kosztowna i chce zaoszczędzić.

W Androidzie 7.0 wprowadzamy tryb Oszczędzanie danych – nową usługę systemową, która pomaga zmniejszyć wykorzystanie komórkowej transmisji danych przez aplikacje, niezależnie od tego, czy używają roamingu, pod koniec cyklu rozliczeniowego czy z małym przedpłaconym pakietem danych. Oszczędzanie danych daje użytkownikom kontrolę nad tym, jak aplikacje wykorzystują komórkową transmisję danych, i pozwala deweloperom zwiększyć wydajność usług, gdy Oszczędzanie danych jest włączone.

Gdy użytkownik włączy Oszczędzanie danych w Ustawieniach, a urządzenie korzysta z sieci z pomiarem użycia danych, system blokuje transmisję danych w tle i sygnalizuje, że aplikacje na pierwszym planie używają ich w miarę możliwości, np. ograniczając szybkość transmisji bitów, obniżając jakość obrazu, opóźniając zapisywanie optymistyczne itd. Użytkownicy mogą zezwolić określonym aplikacjom na używanie danych z pomiarem użycia danych w tle nawet wtedy, gdy Oszczędzanie danych jest włączone.

Android 7.0 poszerza zakres ConnectivityManager, umożliwiając aplikacjom pobieranie ustawień Oszczędzania danych i monitorowanie zmian ustawień. Wszystkie aplikacje powinny sprawdzać, czy użytkownik włączył funkcję oszczędzania danych, oraz starać się ograniczyć użycie danych na pierwszym planie i w tle.

Interfejs API Vulkan

Android 7.0 integruje z platformą VulkanTM, nowy interfejs API renderowania 3D. Podobnie jak OpenGLTM ES, Vulkan to otwarty standard dla grafiki 3D i renderowania prowadzony przez grupę Khronos Group.

Interfejs Vulkan został zaprojektowany od podstaw tak, aby zminimalizować obciążenie procesora po stronie sterownika i umożliwić aplikacji bardziej bezpośrednie sterowanie działaniem GPU. Interfejs Vulkan umożliwia też lepszą równoległe działanie, umożliwiając wielu wątkom jednoczesne wykonywanie zadań, takich jak tworzenie bufora poleceń.

Narzędzia i biblioteki Vulkan dla programistów są wbudowane w pakiet SDK Androida 7.0. Obejmują one:

  • Nagłówki
  • Warstwy weryfikacji (biblioteki debugowania)
  • kompilator do cieniowania SPIR-V
  • Biblioteka kompilacji programu do cieniowania w środowisku wykonawczym SPIR-V

Z interfejsu Vulkan można korzystać tylko w aplikacjach na urządzeniach z interfejsem Vulkan, takich jak Nexus 5X, Nexus 6P i Nexus Player. Ściśle współpracujemy z naszymi partnerami, aby jak najszybciej udostępnić interfejs Vulkan na większej liczbie urządzeń.

Więcej informacji znajdziesz w dokumentacji interfejsu API.

Interfejs Quick Settings Tile API

Kafelki Szybkich ustawień w obszarze powiadomień

Rysunek 5. kafelków Szybkich ustawień w obszarze powiadomień.

Szybkie ustawienia to popularny i prosty sposób ujawniania najważniejszych ustawień i działań bezpośrednio w obszarze powiadomień. W Androidzie 7.0 zwiększyliśmy zakres Szybkich ustawień, dzięki czemu są one jeszcze bardziej przydatne i wygodne.

Dodaliśmy więcej miejsca na dodatkowe kafelki Szybkich ustawień, do których użytkownicy mogą uzyskać dostęp w podzielonym na strony obszarze wyświetlania, przesuwając palcem w lewo lub w prawo. Użytkownicy mają też kontrolę nad tym, jakie kafelki Szybkich ustawień się wyświetlają i gdzie się wyświetlają – użytkownicy mogą dodawać i przenosić kafelki przez przeciąganie ich i upuszczanie.

Dla deweloperów Android 7.0 dodaje też nowy interfejs API, który pozwala definiować własne kafelki Szybkich ustawień, aby zapewnić użytkownikom łatwy dostęp do najważniejszych elementów sterujących i działań w aplikacji.

Kafelki Szybkich ustawień są zarezerwowane dla elementów sterujących lub działań, które są pilnie wymagane lub często używane, i nie powinny być używane jako skróty do uruchamiania aplikacji.

Po zdefiniowaniu kafelków możesz je wyświetlać użytkownikom, którzy będą mogli dodać je do Szybkich ustawień, przeciągając je i upuszczając.

Informacje na temat tworzenia kafelka aplikacji znajdziesz w dokumentacji referencyjnej Tile.

Blokowanie numerów

Android 7.0 obsługuje teraz blokowanie numerów na platformie i udostępnia interfejs API platformy, który umożliwia dostawcom usług obsługę listy zablokowanych numerów. Domyślna aplikacja do SMS-ów, domyślna aplikacja telefoniczna i aplikacje operatora mogą odczytywać z listy zablokowanych numerów i na niej zapisywać dane. Inne aplikacje nie mają do niej dostępu.

Dzięki temu, że blokowanie numerów stanie się standardową funkcją platformy, Android umożliwia aplikacjom blokowanie numerów na różnych urządzeniach w spójny sposób. Zalety aplikacji to między innymi:

  • Numery zablokowane na połączeniach są też blokowane w SMS-ach
  • Zablokowane numery mogą być niezmienne przy resetowaniu i na różnych urządzeniach dzięki funkcji tworzenia i przywracania kopii zapasowej
  • Wiele aplikacji może korzystać z tej samej listy zablokowanych numerów

Dodatkowo integracja aplikacji operatora na Androidzie oznacza, że operatorzy mogą odczytywać listę zablokowanych numerów na urządzeniu i blokować je po stronie usługi, by blokować niechciane połączenia i SMS-y w jakikolwiek sposób, np. za pomocą punktu końcowego VOIP czy telefonu przekazującego.

Więcej informacji znajdziesz w dokumentacji referencyjnej BlockedNumberContract.

Filtrowanie połączeń

Android 7.0 zezwala domyślnej aplikacji Telefon na filtrowanie połączeń przychodzących. W tym celu aplikacja Telefon implementuje nowy CallScreeningService, który umożliwia aplikacji telefonu wykonywanie różnych działań na podstawie Call.Details połączenia przychodzącego, takich jak:

  • Odrzuć połączenie przychodzące
  • Nie zezwalaj na wywoływanie rejestru połączeń
  • Nie pokazuj użytkownikowi powiadomienia o połączeniu

Więcej informacji znajdziesz w dokumentacji referencyjnej CallScreeningService.

Obsługa wielu języków, więcej języków

Android 7.0 umożliwia teraz użytkownikom wybranie w Ustawieniach wielu języków, co poprawia obsługę w dwóch językach. Aplikacje mogą korzystać z nowego interfejsu API, aby pobierać wybrane przez użytkownika języki i oferować bardziej zaawansowane środowisko dla użytkowników korzystających z wielu języków, np. wyświetlać wyniki wyszukiwania w wielu językach i nie oferować tłumaczenia stron w języku, który użytkownik już zna.

Oprócz obsługi wielu języków Android 7.0 rozszerza też zakres dostępnych języków. Oferuje ponad 25 odmian w powszechnie używanych językach, takich jak angielski, hiszpański, francuski i arabski. Dodaliśmy też częściowo obsługę ponad 100 nowych języków.

Aplikacje mogą pobrać listę języków ustawionych przez użytkownika, wywołując LocaleList.GetDefault(). Aby obsługiwać większą liczbę języków, Android 7.0 zmienia sposób rozwiązywania zasobów. Pamiętaj, aby przetestować i sprawdzić, czy Twoje aplikacje działają zgodnie z oczekiwaniami z wykorzystaniem nowej logiki rozpoznawania zasobów.

Więcej informacji na temat nowego sposobu wykorzystania zasobów i sprawdzonych metod, z których możesz korzystać, znajdziesz w artykule Pomoc wielojęzyczna.

Nowe emotikony

Android 7.0 wprowadza dodatkowe emotikony i funkcje związane z emotikonami, w tym emotikony odcieni skóry oraz obsługę selektorów wariantów. Jeśli Twoja aplikacja obsługuje emotikony, postępuj zgodnie z poniższymi wskazówkami, aby korzystać z tych funkcji związanych z emotikonami.

  • Przed wstawieniem emotikona sprawdź, czy urządzenie zawiera emotikon. Aby sprawdzić, które emotikony są widoczne w czcionce systemowej, użyj metody hasGlyph(String).
  • Sprawdź, czy emotikon obsługuje selektory wariantów. Selektory wariantów pozwalają wyświetlać określone emotikony w kolorze lub czarno-białym. Na urządzeniach mobilnych aplikacje powinny przedstawiać emotikony w kolorze, a nie czarno-białe. Jeśli jednak Twoja aplikacja wyświetla emotikony w tekście, powinna używać czarno-białej wersji. Aby określić, czy dany emotikon ma odmianę, użyj selektora odmiany. Pełną listę znaków z odmianami znajdziesz w sekcji o sekwencjach odmian emotikonów w dokumentacji Unicode dotyczącej odmian.
  • Sprawdź, czy emotikon obsługuje odcień skóry. Android 7.0 pozwala użytkownikom dostosować renderowany odcień skóry emotikonów zgodnie z własnymi preferencjami. Aplikacje klawiatury powinny zapewniać wizualne wskazówki dotyczące emotikonów w różnych odcieniach skóry i umożliwiać użytkownikom wybór odcienia skóry. Aby określić, które emotikony systemowe zawierają modyfikatory odcieni skóry, użyj metody hasGlyph(String). Informacje o tym, które emotikony używają odcieni skóry, znajdziesz w dokumentacji Unicode.

Interfejsy API ICU4J na Androida

Android 7.0 oferuje teraz podzbiór interfejsów API ICU4J na platformie Android w pakiecie android.icu. Migracja jest łatwa i obejmuje głównie zmianę przestrzeni nazw com.java.icu na android.icu. Jeśli w swoich aplikacjach używasz już pakietu ICU4J, przejście na interfejsy API android.icu dostępne w platformie Androida może znacznie obniżyć rozmiar pliku APK.

Więcej informacji o interfejsach API Android ICU4J znajdziesz na stronie pomocy ICU4J.

WebView | komponent WebView

Chrome + WebView – razem

Od Chrome w wersji 51 na Androidzie 7.0 i nowszych pakiet APK Chrome na urządzeniu służy do dostarczania i renderowania systemowych komponentów WebView Androida. To podejście zmniejsza wykorzystanie pamięci na urządzeniu i zmniejsza przepustowość wymaganą do aktualizacji komponentu WebView (samodzielny pakiet APK komponentu WebView nie będzie już aktualizowany, dopóki włączony jest Chrome).

Aby wybrać dostawcę WebView, włącz Opcje programisty i kliknij Implementacja WebView. Jako implementację komponentu WebView możesz użyć dowolnej zgodnej wersji Chrome (deweloperskiej, beta lub stabilnej), która jest zainstalowana na urządzeniu, lub samodzielnego pakietu APK WebView.

Wieloprocesowe

Począwszy od Chrome 51 i Androida 7.0, gdy włączona jest opcja programistyczna „Multiproces WebView”, komponent WebView będzie uruchamiać treści z internetu w osobnym procesie piaskownicy.

Czekamy na opinie na temat zgodności i wydajności środowiska wykonawczego w N przed włączeniem wieloprocesowego komponentu WebView w przyszłej wersji Androida. W tej wersji spodziewane są regresje czasu uruchamiania, całkowite wykorzystanie pamięci i wydajność renderowania oprogramowania.

Jeśli zauważysz nieoczekiwane problemy w trybie wielu procesów, poinformuj nas o nich. Skontaktuj się z zespołem WebView zajmującym się narzędziem do śledzenia błędów Chromium.

Uruchamianie kodu JavaScript przed wczytaniem strony

Począwszy od aplikacji kierowanych na Androida 7.0 kontekst JavaScript będzie resetowany po wczytaniu nowej strony. Obecnie kontekst jest przenoszony w przypadku pierwszej strony wczytywanej w nowej instancji WebView.

Programiści, którzy chcą wstawić JavaScript do komponentu WebView, powinni wykonać skrypt po rozpoczęciu wczytywania strony.

Geolokalizacja w niezabezpieczonych źródłach

Począwszy od aplikacji kierowanych na Androida 7.0 interfejs API geolokalizacji będzie dozwolony tylko w bezpiecznych źródłach (przez HTTPS). Ta zasada ma na celu ochronę prywatnych informacji użytkowników, gdy używają niezabezpieczonego połączenia.

Testowanie za pomocą komponentu WebView w wersji beta

Komponent WebView jest regularnie aktualizowany, dlatego zalecamy częste testowanie zgodności z aplikacją za pomocą kanału wersji beta komponentu WebView. Aby rozpocząć testowanie przedpremierowych wersji komponentu WebView na Androidzie 7.0, pobierz i zainstaluj Chrome w wersji deweloperskiej lub Chrome Beta, a potem wybierz ją jako implementację WebView w opcjach programisty w sposób opisany powyżej. Problemy należy zgłaszać za pomocą narzędzia do śledzenia błędów Chromium, abyśmy mogli je wyeliminować przed opublikowaniem nowej wersji WebView.

Interfejs API OpenGLTM ES 3.2

Android 7.0 dodaje interfejsy platformy i obsługę platformy OpenGL ES 3.2, w tym:

  • Wszystkie rozszerzenia z pakietu rozszerzeń Android (AEP) oprócz EXT_texture_sRGB_decode.
  • Zmiennoprzecinkowe bufory ramek umożliwiające HDR i odroczone cieniowanie.
  • BaseVertex pobiera wywołania, aby umożliwić lepsze wsadzanie i przesyłanie strumieniowe.
  • Rozbudowana kontrola dostępu do bufora w celu ograniczenia narzutu WebGL.

Interfejs Framework API dla OpenGL ES 3.2 w Androidzie 7.0 jest udostępniany w klasie GLES32. Jeśli używasz OpenGL ES 3.2, pamiętaj, aby zadeklarować to wymaganie w pliku manifestu, używając tagu <uses-feature> i atrybutu android:glEsVersion.

Więcej informacji o korzystaniu z OpenGL ES, w tym o sprawdzaniu wersji OpenGL ES obsługiwanej przez urządzenie w czasie działania, znajdziesz w przewodniku po interfejsie API OpenGL ES.

Nagrywanie w Android TV

Android 7.0 dodaje możliwość nagrywania i odtwarzania treści z usług wejściowych Android TV przez nowe interfejsy API nagrywania. Opierając się na istniejących interfejsach API do przesuwania w czasie, telewizyjne usługi wejściowe mogą kontrolować to, jakie dane kanału mogą być nagrywane i jak zapisywane są nagrania, a także zarządzać interakcjami użytkowników z nagranymi treściami.

Więcej informacji znajdziesz w artykule Interfejsy API nagrywania na Androidzie TV.

Android for Work

Android for Work wprowadza wiele nowych funkcji i interfejsów API na urządzenia z Androidem 7.0. Poniżej znajdziesz najważniejsze informacje. Pełną listę funkcji znajdziesz na liście funkcji Androida Enterprise.

Test zabezpieczający logowanie na profilu służbowym

Właściciele profili kierowanych na pakiet N SDK mogą określać osobne zabezpieczenia bezpieczeństwa dla aplikacji działających w profilu służbowym. Wyzwanie służbowe wyświetla się, gdy użytkownik próbuje otworzyć dowolną aplikację służbową. Test zabezpieczający odblokowuje profil służbowy i w razie potrzeby odszyfrowuje go. W przypadku właścicieli profili ACTION_SET_NEW_PASSWORD prosi użytkownika o ustawienie wyzwania w pracy, a ACTION_SET_NEW_PARENT_PROFILE_PASSWORD prosi użytkownika o ustawienie blokady urządzenia.

Właściciele profili mogą ustawiać różne zasady dotyczące kodu dostępu dla wyzwania służbowego (np. czas potrzebny na podanie kodu PIN lub to, czy można użyć odcisku palca do odblokowania profilu), korzystając z metod setPasswordQuality(), setPasswordMinimumLength() i powiązanych. Właściciel profilu może też ustawić blokadę urządzenia za pomocą instancji DevicePolicyManager zwróconej przez nową metodę getParentProfileInstance(). Dodatkowo właściciele profili mogą dostosować ekran z danymi logowania na potrzeby testu służbowego za pomocą nowych metod setOrganizationColor() i setOrganizationName().

Wyłączanie trybu pracy

Na urządzeniu z profilem służbowym użytkownicy mogą przełączać tryb pracy. Gdy tryb pracy jest wyłączony, użytkownik zarządzany jest tymczasowo wyłączony, co powoduje wyłączenie aplikacji profilu służbowego, synchronizacji w tle i powiadomień. Obejmuje to aplikację właściciela profilu. Gdy tryb pracy jest wyłączony, system wyświetla ikonę stałego stanu, aby przypomnieć użytkownikowi, że nie może uruchamiać aplikacji służbowych. Launcher informuje, że działające aplikacje i widżety są niedostępne.

Stały VPN

Właściciele urządzeń i właściciele profili mogą zadbać o to, aby aplikacje służbowe zawsze łączyły się przez określoną sieć VPN. System automatycznie uruchamia tę sieć VPN po uruchomieniu urządzenia.

Nowe metody DevicePolicyManager to setAlwaysOnVpnPackage() i getAlwaysOnVpnPackage().

Usługi VPN mogą być powiązane bezpośrednio z systemem bez interakcji z aplikacjami, dlatego klienty VPN muszą obsługiwać nowe punkty wejścia do stałej sieci VPN. Tak jak wcześniej usługi są wskazywane systemowi przez filtr intencji pasujący do działania android.net.VpnService.

Użytkownicy mogą też ręcznie ustawić klienty zawsze włączone, które implementują metody VPNService, wybierając Ustawienia> Więcej> VPN. Opcja włączenia stałego VPN w Ustawieniach jest dostępna tylko wtedy, gdy klient VPN jest kierowany na interfejs API na poziomie 24.

Dostosowana obsługa administracyjna

Aplikacja może dostosować proces obsługi administracyjnej właściciela profilu i właściciela urządzenia przy użyciu firmowych kolorów i logo. DevicePolicyManager.EXTRA_PROVISIONING_MAIN_COLOR dostosowuje kolor przepływu. DevicePolicyManager.EXTRA_PROVISIONING_LOGO_URI dostosuje proces, dodając logo firmy.

Udoskonalone ułatwienia dostępu

Android 7.0 oferuje teraz ustawienia widoczności bezpośrednio na ekranie powitalnym dla konfiguracji nowego urządzenia. Dzięki temu użytkownicy mogą znacznie łatwiej odkrywać i konfigurować na urządzeniach funkcje ułatwień dostępu, w tym gest powiększenia, rozmiar czcionki, rozmiar wyświetlacza i TalkBack.

Gdy te ułatwienia dostępu są lepiej widoczne, użytkownicy z większym prawdopodobieństwem wypróbują Twoją aplikację. Pamiętaj, by przetestować swoje aplikacje z wyprzedzeniem i włączyć te ustawienia. Aby je włączyć, kliknij Ustawienia > Ułatwienia dostępu.

Również w Androidzie 7.0 usługi ułatwień dostępu pomagają użytkownikom z niepełnosprawnością ruchową dotykać ekranu. Nowy interfejs API umożliwia tworzenie usług z funkcjami takimi jak śledzenie twarzy, ruch oczu czy skanowanie punktowe, które zaspokajają potrzeby użytkowników.

Więcej informacji znajdziesz w dokumentacji referencyjnej GestureDescription.

Bezpośredni rozruch

Bezpośredni rozruch skraca czas uruchamiania urządzenia i pozwala zarejestrowanym aplikacjom działać w ograniczony sposób nawet po niespodziewanym ponownym uruchomieniu. Jeśli na przykład zaszyfrowane urządzenie zostanie zrestartowane, gdy użytkownik uśpił, zarejestrowane alarmy, wiadomości i połączenia przychodzące mogą nadal powiadamiać użytkownika jak zwykle. Oznacza to również, że usługi ułatwień dostępu mogą być również dostępne natychmiast po ponownym uruchomieniu.

Bezpośredni rozruch wykorzystuje szyfrowanie plików w Androidzie 7.0, aby umożliwić szczegółowe zasady szyfrowania danych zarówno systemu, jak i aplikacji. System korzysta z magazynu szyfrowanego przez urządzenie do przechowywania wybranych danych systemowych i jawnie zarejestrowanych danych aplikacji. Domyślnie magazyn szyfrowany za pomocą danych logowania jest używany do przechowywania wszystkich innych danych systemowych, danych użytkowników, aplikacji i danych aplikacji.

Podczas uruchamiania system uruchamia się w trybie ograniczonego dostępu z dostępem tylko do danych zaszyfrowanych na urządzeniu, bez ogólnego dostępu do aplikacji czy danych. Jeśli masz komponenty, które chcesz uruchamiać w tym trybie, możesz je zarejestrować, ustawiając odpowiednią flagę w pliku manifestu. Po ponownym uruchomieniu system aktywuje zarejestrowane komponenty, rozgłaszając intencję LOCKED_BOOT_COMPLETED. System sprawdza, czy przed odblokowaniem dostępne są zaszyfrowane dane aplikacji zarejestrowane na urządzeniu. Wszystkie inne dane będą niedostępne, dopóki użytkownik nie potwierdzi swoich danych logowania na ekranie blokady, aby je odszyfrować.

Więcej informacji znajdziesz w sekcji Uruchamianie bezpośrednie.

Atestacja klucza

W Androidzie 7.0 wprowadziliśmy atestację kluczy – nowe narzędzie zabezpieczające, które pomaga upewnić się, że pary kluczy przechowywane w magazynie kluczy opartym na sprzętowym urządzeniu prawidłowo chronią informacje poufne używane przez aplikację. Korzystając z tego narzędzia, masz większą pewność, że Twoja aplikacja współpracuje z kluczami przechowywanymi na bezpiecznym sprzęcie, nawet jeśli urządzenie, na którym uruchomiono aplikację, ma dostęp do roota. Jeśli w swoich aplikacjach używasz kluczy ze sprzętowego magazynu kluczy, zalecamy korzystanie z tego narzędzia – zwłaszcza wtedy, gdy używasz ich do weryfikacji informacji poufnych w aplikacji.

Atest klucza umożliwia sprawdzenie, czy para kluczy RSA lub EC została utworzona i zapisana w sprzętowym magazynie kluczy urządzenia w zaufanym środowisku wykonawczym urządzenia (TEE). Narzędzie pozwala też na korzystanie z usługi zewnętrznej (np. serwera backendu aplikacji) do określania i zdecydowanego weryfikowania zastosowań oraz poprawności pary kluczy. Te funkcje zapewniają dodatkowy poziom bezpieczeństwa, który chroni parę kluczy, nawet jeśli ktoś uzyska dostęp do roota na urządzeniu lub naruszy bezpieczeństwo platformy Androida, która na nim działa.

Uwaga: tylko niewielka liczba urządzeń z Androidem 7.0 obsługuje poświadczanie klucza na poziomie sprzętowym. Pozostałe urządzenia z Androidem 7.0 korzystają z atestu klucza na poziomie oprogramowania. Zanim sprawdzisz właściwości obsługiwanych sprzętowych kluczy w środowisku produkcyjnym, sprawdź, czy urządzenie obsługuje atestację klucza sprzętowego. W tym celu sprawdź, czy łańcuch certyfikatów atestu zawiera certyfikat główny podpisany kluczem głównym atestu Google oraz czy element attestationSecurityLevel w strukturze danych opisu klucza jest ustawiony na poziom zabezpieczeń TrustedEnvironment.

Więcej informacji znajdziesz w dokumentacji dla deweloperów dotyczącej atestu klucza.

Konfiguracja zabezpieczeń sieci

W Androidzie 7.0 aplikacje mogą bezpiecznie dostosowywać działanie swoich bezpiecznych połączeń (HTTPS, TLS) bez konieczności modyfikowania kodu, korzystając z deklaratywnej konfiguracji zabezpieczeń sieci zamiast konwencjonalnych interfejsów API podatnych na błędy (np. X509TrustManager).

Obsługiwane funkcje:

  • Niestandardowe kotwice zaufania. Umożliwia aplikacji dostosowywanie urzędów certyfikacji, które są zaufane w przypadku bezpiecznych połączeń. Dotyczy to na przykład zaufania do konkretnych certyfikatów podpisanych samodzielnie lub ograniczonego zestawu publicznych urzędów certyfikacji.
  • Zastąpienia tylko do debugowania. Umożliwia deweloperowi bezpieczne debugowanie bezpiecznych połączeń aplikacji bez zwiększania ryzyka dla zainstalowanej bazy.
  • Rezygnacja z ruchu w formacie Cleartext. Pozwala aplikacji na ochronę przed przypadkowym ruchem nieszyfrowanym.
  • Przypinanie certyfikatu. Zaawansowana funkcja, która umożliwia aplikacji ograniczanie, które klucze serwera są zaufane dla bezpiecznych połączeń.

Więcej informacji znajdziesz w artykule Konfigurowanie zabezpieczeń sieci.

Domyślny zaufany urząd certyfikacji

Domyślnie aplikacje kierowane na Androida 7.0 ufają tylko certyfikatom dostarczonym przez system i nie ufają już urzędom certyfikacji dodanym przez użytkowników. Aplikacje kierowane na Androida 7.0 (poziom interfejsu API 24), które chcą ufać urzędom certyfikacji dodanym przez użytkowników, powinny korzystać z konfiguracji zabezpieczeń sieci, aby określić sposób zaufania CA użytkowników.

Schemat podpisu pliku APK w wersji 2

W Androidzie 7.0 wprowadzamy schemat podpisywania plików APK w wersji 2 – nowy schemat podpisywania aplikacji, który zapewnia krótszy czas instalacji i lepszą ochronę przed nieuprawnionymi modyfikacjami plików APK. Domyślnie Android Studio 2.2 i wtyczka Androida do Gradle 2.2 podpisują Twoją aplikację zarówno przy użyciu schematu podpisu plików APK w wersji 2, jak i tradycyjnego schematu podpisywania, w którym stosuje się podpisywanie JAR.

Chociaż zalecamy stosowanie w swojej aplikacji schematu podpisu plików APK w wersji 2, ten nowy schemat nie jest wymagany. Jeśli aplikacja nie kompiluje się prawidłowo podczas korzystania z schematu podpisu plików APK w wersji 2, możesz wyłączyć nowy schemat. Proces wyłączenia powoduje, że Android Studio 2.2 i wtyczka Androida do Gradle 2.2 podpisują Twoją aplikację tylko przy użyciu tradycyjnego schematu podpisywania. Aby podpisać tylko za pomocą tradycyjnego schematu, otwórz plik build.gradle na poziomie modułu, a następnie dodaj wiersz v2SigningEnabled false do konfiguracji podpisywania wersji:

  android {
    ...
    defaultConfig { ... }
    signingConfigs {
      release {
        storeFile file("myreleasekey.keystore")
        storePassword "password"
        keyAlias "MyReleaseKey"
        keyPassword "password"
        v2SigningEnabled false
      }
    }
  }

Uwaga: jeśli podpiszesz aplikację za pomocą schematu podpisu plików APK w wersji 2 i wprowadzisz w niej dalsze zmiany, podpis aplikacji zostanie unieważniony. Dlatego przed podpisaniem aplikacji za pomocą schematu podpisu plików APK w wersji 2 używaj takich narzędzi jak zipalign, a nie później.

Więcej informacji znajdziesz w dokumentach Android Studio, które opisują, jak podpisywać aplikację w Android Studio i jak skonfigurować plik kompilacji na potrzeby podpisywania aplikacji przy użyciu wtyczki Androida do Gradle.

Zakres dostępu do katalogu

W Androidzie 7.0 aplikacje mogą używać nowych interfejsów API, aby prosić o dostęp do określonych katalogów w pamięci zewnętrznej, w tym do katalogów na nośniku wymiennym, takim jak karty SD. Nowe interfejsy API znacznie upraszczają dostęp aplikacji do standardowych katalogów pamięci zewnętrznej, takich jak Pictures. Aplikacje, takie jak aplikacje do obsługi zdjęć, mogą używać tych interfejsów API, a nie interfejsu READ_EXTERNAL_STORAGE, który zapewnia dostęp do wszystkich katalogów pamięci masowej, lub interfejsu Storage Access Framework, który sprawia, że użytkownik przechodzi do katalogu.

Dodatkowo nowe interfejsy API upraszczają proces przyznawania aplikacji dostępu do pamięci zewnętrznej. Gdy używasz nowych interfejsów API, system używa prostego interfejsu uprawnień, w którym wyraźnie widać, do którego katalogu aplikacja prosi o dostęp.

Więcej informacji znajdziesz w dokumentacji dla deweloperów ograniczonego dostępu do katalogu.

Pomoc do skrótów klawiszowych

W Androidzie 7.0 użytkownik może nacisnąć Meta + /, aby wyświetlić ekran Skróty klawiszowe, na którym będą widoczne wszystkie skróty dostępne zarówno w systemie, jak i w zaznaczonej aplikacji. Jeśli skróty są dostępne, system automatycznie pobiera je z menu aplikacji. Możesz też udostępniać własne, dostrojone listy skrótów wyświetlanych na ekranie. Możesz to zrobić, zastępując metodę onProvideKeyboardShortcuts().

Uwaga: na niektórych klawiaturach jest to klawisz Meta. Na klawiaturze Maca jest to klawisz Command, na klawiaturze Windows – klawisz Windows, a na klawiaturze Pixela C i systemu operacyjnego ChromeOS – klawisz Wyszukaj.

Aby uruchomić Asystenta skrótów klawiszowych z dowolnego miejsca w aplikacji, wywołaj requestShowKeyboardShortcuts() z poziomu odpowiedniej aktywności.

Interfejs API niestandardowego wskaźnika

W Androidzie 7.0 wprowadziliśmy interfejs Custom Pointer API, który umożliwia dostosowywanie wyglądu, widoczności i działania wskaźnika. Ta funkcja jest szczególnie przydatna, gdy użytkownik wchodzi w interakcję z obiektami interfejsu za pomocą myszy lub touchpada. Domyślny wskaźnik używa standardowej ikony. Zawiera też zaawansowane funkcje, takie jak zmiana wyglądu ikony wskaźnika w zależności od ruchów myszą lub touchpadem.

Aby ustawić ikonę wskaźnika, zastąp metodę onResolvePointerIcon() klasy View. Ta metoda używa obiektu PointerIcon do rysowania ikony odpowiadającej konkretnemu zdarzeniu ruchu.

Interfejs Sustained Performance API

W przypadku długotrwałych aplikacji wydajność może się znacznie wahać, ponieważ system ogranicza silniki w układzie w miarę osiągania wyznaczonych przez nie temperatury. Te wahania oznaczają zmieniający się cel dla deweloperów tworzących aplikacje o wysokiej wydajności i działającej od dłuższego czasu.

Aby sprostać tym ograniczeniom, Android 7.0 zapewnia obsługę trybu o stałej wydajności, dzięki czemu OEM może przekazywać wskazówki dotyczące wydajności urządzenia w przypadku długo działających aplikacji. Dzięki tym wskazówkom deweloperzy mogą dostosowywać aplikacje do przewidywalnego i spójnego poziomu wydajności urządzenia w dłuższym okresie.

Deweloperzy aplikacji mogą wypróbować ten nowy interfejs API w Androidzie 7.0 tylko na urządzeniach Nexus 6P. Aby korzystać z tej funkcji, ustaw flagę okna długotrwałej wydajności dla okna, które ma być uruchamiane w trybie o stałej wydajności. Ustaw tę flagę za pomocą metody Window.setSustainedPerformanceMode(). System automatycznie wyłączy ten tryb, gdy okno nie będzie już widoczne.

Obsługa VR

Android 7.0 zapewnia obsługę platformy i optymalizacje pod kątem nowego trybu VR, aby umożliwić deweloperom tworzenie wysokiej jakości aplikacji mobilnych VR dla użytkowników. Dostępne są różne ulepszenia wydajności, w tym dostęp do specjalnego rdzenia dla aplikacji VR. W swoich aplikacjach możesz korzystać z inteligentnego monitorowania ruchów głowy i powiadomień stereo z funkcją VR. Co najważniejsze, Android 7.0 zapewnia bardzo małe opóźnienia grafiki. Pełne informacje o tworzeniu aplikacji VR na Androida 7.0 znajdziesz w przewodniku Google VR SDK na Androida.

W Androidzie 7.0 deweloperzy usług drukowania mogą teraz wyświetlać dodatkowe informacje o poszczególnych drukarkach i zadaniach drukowania.

Podczas wyświetlania listy pojedynczych drukarek usługa drukowania może teraz ustawiać ikony poszczególnych drukarek na 2 sposoby:

Możesz też podać aktywność dotyczącą drukarki, aby wyświetlić dodatkowe informacje, wywołując funkcję setInfoIntent().

Postęp i stan zadań drukowania możesz określić w powiadomieniu o zadaniach drukowania, wywołując odpowiednio metodę setProgress() i setStatus().

Interfejs Frame Metrics API

Interfejs Frame Metrics API umożliwia aplikacji monitorowanie wydajności renderowania interfejsu użytkownika. Interfejs API zapewnia tę możliwość, udostępniając strumieniowy interfejs Pub/Sub API do przesyłania informacji o czasie klatek w bieżącym oknie aplikacji. Zwrócone dane odpowiadają tym, które wyświetla adb shell dumpsys gfxinfo framestats, między innymi ostatnich 120 klatek.

Interfejs Frame Metrics API umożliwia pomiar wydajności interfejsu na poziomie interakcji w środowisku produkcyjnym bez połączenia USB. Ten interfejs API umożliwia zbieranie danych z większą szczegółowością niż adb shell dumpsys gfxinfo. Taki wyższy poziom szczegółowości jest możliwe, ponieważ system może zbierać dane o konkretnych interakcjach w aplikacji, a system nie musi rejestrować globalnego podsumowania działania całej aplikacji ani usuwać żadnego stanu globalnego. Dzięki tej możliwości można zbierać dane o wydajności i wychwytywać regresje w wydajności interfejsu użytkownika w rzeczywistych przypadkach użycia w aplikacji.

Aby monitorować okno, wdróż metodę wywołania zwrotnego OnFrameMetricsAvailableListener.onFrameMetricsAvailable() i zarejestruj ją w tym oknie.

Interfejs API udostępnia obiekt FrameMetrics, który zawiera dane o czasie przesyłane przez podsystem renderujący dla różnych etapów cyklu życia ramki. Obsługiwane dane to: UNKNOWN_DELAY_DURATION, INPUT_HANDLING_DURATION, ANIMATION_DURATION, LAYOUT_MEASURE_DURATION, DRAW_DURATION, SYNC_DURATION, COMMAND_ISSUE_DURATION, SWAP_BUFFERS_DURATION,TOTAL_DURATION i FIRST_DRAW_FRAME.

Pliki wirtualne

W poprzednich wersjach Androida aplikacja mogła korzystać z platformy Storage Access Framework, aby umożliwić użytkownikom wybieranie plików z ich kont w chmurze, takich jak Dysk Google. Nie było jednak sposobu reprezentowania plików, które nie miały bezpośredniego reprezentacji kodu bajtowego. Każdy plik musiał zapewniać strumień wejściowy.

Android 7.0 wprowadza do platformy Storage Access Framework koncepcję plików wirtualnych. Funkcja plików wirtualnych umożliwia interfejsowi DocumentsProvider zwracanie identyfikatorów URI dokumentów, których można używać z intencją ACTION_VIEW, nawet jeśli nie są one reprezentowane bezpośrednio kodem bajtowym. Android 7.0 umożliwia też udostępnianie alternatywnych formatów plików użytkownika – wirtualnych i innych.

Więcej informacji o otwieraniu plików wirtualnych znajdziesz w sekcji Otwieranie plików wirtualnych w przewodniku po platformach Storage Access Framework.