Z każdym dniem zbliża się moment, kiedy to będzie miał zastosowanie wymóg ze strony Google, aby wszystkie aplikacje docelowo korzystały z jak najwyższej docelowej wersji API na platformie Android. Tak naprawdę wszystko rozpoczęło się już w sierpniu, ponieważ to właśnie od tego miesiąca każda nowa aplikacja musiała spełniać ten wymóg, ale od listopada zostanie rozszerzony on również na aplikacje już od jakiegoś czasu znajdujące się w Sklepie Play. Cały ten zabieg ma na celu zapewnienie jak najwyższego poziomu bezpieczeństwa aplikacji oraz ich wydajności.
Jeśli jeszcze nie posiadasz zaktualizowanej swojej aplikacji, przyjrzyj się poniższym punktom, aby dowiedzieć się, co tak naprawdę napotkasz na swojej drodze podczas aktualizacji wartości parametru targetSdkVersion do wersji od 23 do 26.
Aktualizacja do API 23 - Android Marshmallow (6.0)
Ta wersja API systemu Android wprowadziła zasadniczo dwie najbardziej widoczne nowości. Pierwszą z nich są funkcje Doze i App Standby, które mają za zadanie wydłużenie czasu działania urządzenia. Ogólnie rzecz biorąc, zasada ich działania polega na tym, że po jakimś czasie od wygaszenia ekranu, urządzenie przechodzi w tryb uśpienia, a tylko od czasu do czasu wykonywane są działania w tle, które mają na celu, na przykład sprawdzenie, czy nie należy użytkownikowi wyświetlić jakiegoś powiadomienia.
Drugą bardzo ważną zmianą jest nowy system uprawnień: Runtime Permissions. Poprzednio były one przyznawane już podczas instalacji aplikacji. Przykładowo pobierając aplikację ze Sklepu Play, użytkownik był informowany, o tym jakich uprawnień aplikacja wymaga i bez przydzielenia tych uprawnień aplikacja nie mogła zostać zainstalowana. Od API 23 nie ma już takiej opcji, a aplikacja musi prosić o uprawnienia w trakcie działania i tylko wówczas, gdy dane uprawnienie będzie faktycznie wymagane. Przykładowo, kiedy jakaś część naszej aplikacji będzie potrzebowała dostępu do kontaktów, należy poprosić użytkownika o przyznanie uprawnień, a kiedy nie udzieli nam tej zgody, po prostu należy go poinformować o braku uprawnień, w związku z czym ta jedna funkcjonalność aplikacji nie będzie działała. Oczywiście użytkownik powinien móc jednak zdecydować się na przyznanie uprawnień i uruchomienie zablokowanej funkcjonalności. Oczywiście musimy być też przygotowani na to, że użytkownik w każdej chwili mógł wycofać uprawnienia z poziomu ustawień systemu, więc nie może to spowodować zawieszenia się aplikacji.
Więcej na temat przyznawania uprawnień znajduje się w tym poradniku.
Aktualizacja do API 24 - Android Nougat (7.0)
Podczas naszej drogi podczas aktualizacji targetSdkVersion napotkamy na następujące zmiany związane z tą wersją API.
Bardzo dużą zmianą, ale niekoniecznie wymaganą dla naszej aplikacji, jest wprowadzenie opcji wielu okien (multi-window). Dzięki niej możemy mieć w tej samej chwili włączone dwie aplikacje. Rozmiary okiem można zmieniać w zakresie dwa takie same, pierwsze większe lub drugie większe. Wdrożenie tej funkcjonalności nie jest wymagane, ale na pewno w niejednym przypadku poprawi użytkownikom naszej aplikacji przyjemność z niej korzystania.
API 24 wprowadziło również aktualizację do mechanizmu Doze wprowadzonego z poprzednią wersją API.
Z kolei bardzo ważną zmianą wprowadzoną przez API 24 jest wymóg użycia FileProvider’a podczas dzielenia się plikami naszej aplikacji z innymi aplikacjami. Wcześniej założenie było takie, że inna aplikacja może odczytywać pliki z pamięci zewnętrznej, ale niekoniecznie musi tak być. Bez uwzględnienia tych zmian, nasza aplikacja zakończy swoje działanie z wyjątkiem FileUriExposedException. Tak, więc jeśli w dalszym ciągu do dzielenia się plikami z innymi aplikacjami używasz URI file:// zamiast content:// zainteresuj się tym poradnikiem.
Aktualizacja do API 25 - Android Nougat (7.1)
Tutaj należy przede wszystkim wspomnieć o dwóch wprowadzonych nowościach. Nie są to zmiany bardzo ważne z punktu widzenia aktualizacji naszej aplikacji, ale jednak mogą one przyczynić się do jej lepszego odbioru przez użytkowników.
Pierwsza z nich to skróty aplikacji, które umożliwiają dodanie do ikony aplikacji na ekranie głównym maksymalnie pięciu skrótów. Jest to bardzo dobre miejsce na dodanie możliwości szybkiego przejścia do tworzenia nowej wiadomości lub przejścia do najczęściej wykorzystywanych przez użytkowników funkcji.
Drugą z nowości jest już tylko kosmetyka, a dokładnie chodzi o możliwość ustawienia okrągłej ikony aplikacji (atrybut android:roundIcon w pliku AndroidManifest.xml).
Aktualizacja do API 26 - Android Oreo (8.0)
Tutaj już pojawia się kilka zmian, na które musimy zwrócić uwagę. Oczywiście znajdziemy tutaj też zmiany, które pozwolą nam rozbudować naszą aplikację o nowe ciekawe funkcje. Są to m.in.: tryb Picture-in-Picture, rozbudowa powiadomień, “pobieralne” fonty, fonty w plikach XML czy komponent TextView, który automatycznie dostosowuje swój rozmiar. Oczywiście nowości jest jeszcze więcej, ale skupmy się teraz na naszych obowiązkach.
Od tej wersji API wywołanie metody startService() może spowodować wyjątek kiedy nie ma uprawnień do tworzenia usług działających w tle. Pojawiła się nowa metoda startForegroundService(), która umożliwia uruchomienie usługi na pierwszym planie i możliwe jest uruchomienie takiej usługi, nawet kiedy aplikacja działa w tle. Jednak jest tutaj jeden wyjątek. Aplikacja musi wywołać metodę startForeground() w ciągu pięciu sekund od uruchomienia takiej usługi.
W związku z tym, że ta wersja API wprowadza bardzo wiele limitów odnośnie do działania w tle, musimy zajrzeć do naszego pliku manifestu, aby sprawdzić, czy nie znajdują się tam broadcast’y spoza listy dostępnej pod tym adresem.
Aktualizacja lokalizacji urządzenia również doczekała się tutaj pewnych obostrzeń podczas jej działania w tle. Podczas gdy nasza aplikacja korzysta z Usług Google Play, wówczas do nasłuchiwania zmian lokalizacji należy używać FusedLocationProviderClient. Inną opcją jest geofencing.
Na koniec jeszcze jedna bardzo ważna zmiana, tym razem związana z powiadomieniami. Od tej wersji API, aplikacja musi obsługiwać kanały powiadomień, w przeciwnym wypadku powiadomienia z naszej aplikacji nie zastaną w ogóle wyświetlone. Kanały powiadomień możemy porównać do kategorii, na które możemy podzielić powiadomienia występujące w naszej aplikacji. Oczywiście jest to ukłon w stronę użytkownika, ponieważ umożliwiają one decydowanie, które powiadomienia są dla użytkownika ważne lub mniej, a których nie chciałby widzieć w ogóle.
Meta
W ten właśnie sposób przeszliśmy przez aktualizację aplikacji, aby była ona zgodna z API 26, które będzie wymagane podczas aktualizacji aplikacji będących w Sklepie Play przed sierpniem bieżącego roku. Niektóre zmiany są znaczące i mogą wymagać wprowadzenia wielu zmian do kodu aplikacji, więc prace najlepiej wykonać będzie z wyprzedzeniem przed nastaniem listopada. Dodam jeszcze tutaj, że powyższe wymagania od listopada będą dotyczyły tylko aktualizacji aplikacji więc aplikacje, które już znajdują się na sklepie, ale nie będą aktualizowane, nie zostaną usunięte.
W sieci natknąłem się na wiele komentarzy osób, które interesują się technologiami mobilnymi, ale nie będącymi programistami, z obawami, że Google zamierza wprowadzić wymóg stosowania API w wersji 26 w aplikacjach dostępnych na Google Play, ale nie wszyscy posiadają na swoich urządzeniach Androida 8.0. Otóż nie ma powodów do obaw, ponieważ ważny w tym momencie jest atrybut targetSdkVersion, czyli wersja docelowa systemu, dla której stworzona jest aplikacja. Twórca aplikacji może oczywiście umożliwić jej instalację na urządzeniach z co najmniej Androidem Oreo, ale do tego celu służy zupełnie inny atrybut: minSdkVersion. Jednak tak naprawdę mało kto się na to zdecyduje, ponieważ na obecną chwilę z Androida Oreo korzysta 12.1% urządzeń logujących się do Sklepu Google Play.