Zgodnie z zestawem zatwierdzeń w AOSP Google może zacząć ograniczać dostęp do nieudokumentowanych lub ukrytych interfejsów API w systemie Android P. Wiele markowych aplikacji korzysta z ukrytych interfejsów API w celu zwiększenia funkcjonalności, więc efekt może być powszechny.
Aktualizacja 28.02.18: Firma Google opublikowała dzisiaj na blogu post potwierdzający zmiany. Więcej szczegółów na końcu artykułu.
Chociaż niektórzy entuzjaści Androida są spekulacje od jakiego deseru zostanie nazwana następna wersja Androida, za kulisami dzieje się kilka interesujących wydarzeń. Zauważyliśmy kilka godnych uwagi nadchodzących funkcji w systemie Android P, ale nowsze odkrycie w ramach projektu Android Open Source Project (AOSP) okazało się znacznie bardziej interesujące. Zgodnie z tymi ostatnimi zatwierdzeniami dostęp aplikacji do interfejsów API, które nie są udokumentowane w zestawie SDK systemu Android (takich jak interfejsy API oznaczone atrybutem @hide) w javadoc, może zostać ograniczony.
Dlaczego to ma znaczenie
Zestaw Android Software Development Kit (SDK) zapewnia programistom biblioteki API i narzędzia potrzebne do testowania i tworzenia nowych aplikacji na Androida. Z każdą nową wersją Androida pojawia się cała gama nowych interfejsów API dostępnych dla programistów za pośrednictwem zestawu SDK systemu Android. To, jakie interfejsy API są dostępne dla aplikacji, zależy od wersji zestawu SDK ustawionej przez programistę. Dlatego Google nowe wymagania Sklepu Play są na tyle istotne, że wymuszą aktualizację aplikacji i migrację do korzystania z nowszych interfejsów API.
Hosty Google strony dokumentacji dla każdej klasy i wszystkich jej metod dostępnych na każdym poziomie API. Oto zestaw udokumentowanych interfejsów API dostępnych w oficjalnym zestawie SDK systemu Android. Możesz łatwo przeglądać listę zajęć za pomocą aplikacji na Androida, takiej jak niedawno wydana aplikacja Android SDK Search autorstwa Android Engineer Jake’a Whartona.
Cena: za darmo.
4.1.
Jednak nie wszystkie interfejsy API dostępne w każdej wersji Androida są udokumentowane przez Google lub dostępne w oficjalnym zestawie SDK systemu Android. Często istnieją przydatne interfejsy API nieudokumentowany, ale mimo to są bardzo przydatne. Nie zaleca się, aby programiści tworzyli swoje aplikacje przy użyciu nieudokumentowanych lub ukrytych interfejsów API, ale wielu tak robi, ponieważ po prostu nie ma alternatywy, jeśli chcą zaoferować określoną funkcję. Programiści korzystający z ukrytych lub nieudokumentowanych interfejsów API również mogą zapewnić sobie przewagę konkurencyjną, ponieważ mogą oferować funkcje, które oferują ich konkurenci, którzy trzymają się interfejsów API oferowanych przez Androida SDK — nie można.
Chociaż nie mogę podać listy aplikacji, które korzystają z nieudokumentowanych interfejsów API (programiści prawdopodobnie nie udostępniają których używają, ponieważ dałoby to przewagę ich konkurentom), lista jest prawdopodobnie raczej duży. Wnioskowałbym zatem, że wprowadzenie zakazu dostępu do ukrytych API byłoby znaczące. Mark Murphy, założyciel Oprogramowanie typu Commons, zgadza się:
Zgadzam się z oceną, że zbiorcze blokowanie dostępu do elementów z adnotacją @hide będzie poważnym problemem, jeśli tak się stanie. Mamy nadzieję, że niewiele aplikacji uzyskuje dostęp do tych elementów w ramach kluczowych funkcji. Podejrzewam jednak, że wiele markowych aplikacji czasami z nich korzysta, bezpośrednio lub za pośrednictwem biblioteki.
Co się dzieje w Androidzie P?
Te nadchodzące zmiany zostały po raz pierwszy zauważone przez starszego uznanego programistę XDA rovo89, twórca Ramy Xposed. Wskazał mi dwa zobowiązania, jedno z nich Który był połączone, które wprowadza nowe narzędzie do kompilacji o nazwie „hiddenapi”. To narzędzie modyfikuje flagi dostępu wszystkich członków klasy w pliku DEX if ich podpisy pojawiają się na wejściowej szarej lub czarnej liście, a jeśli tak, zaznaczone metody będą traktowane jako wewnętrzne API z ograniczonymi dostęp. Drugie zatwierdzenie opisuje, jak działa czarna lista API; uniemożliwia dostęp do klasa rozruchowa metody i pola oznaczone wyżej wymienionymi „hiddenapi”, do których programiści mogą uzyskać dostęp poprzez statyczne łączenie, odbicie i JNI.
Według rovo89 efekt końcowy tych dwóch zmian w Androidzie P jest następujący:
Jeśli te zatwierdzenia zostaną połączone, będzie to oznaczać, że aplikacje nie będą już mogły korzystać z ukrytych interfejsów API ani uzyskiwać do nich dostępu klasy, metody i pola, które są oznaczone @hide w AOSP i dlatego nie są częścią oficjalny SDK. Nie stanowiłoby to problemu w przypadku modułów Xposed, ponieważ mógłbym łatwo cofnąć te zatwierdzenia lub zezwolić modułom na to uzyskać dostęp do tych interfejsów API. Istnieje jednak wiele aplikacji, które korzystają z ukrytych interfejsów API, a te zawodzą przyszły.
Rzeczywiście, dalsze zobowiązania pokazują, że może to być to, co planuje Google. Ten popełniać stwierdza, co następuje:
Chociaż to konkretne zatwierdzenie nie zostało scalone, ponieważ zostało porzucone na rzecz 3 mniejszych zatwierdzeń, komunikat zatwierdzenia opisuje cel tych zmian. Kolejny zestaw popełnia pokazać, że Google zaproponuje alternatywy programistom, którzy chcą korzystać z niepublicznych interfejsów API:
Często jednak nie ma alternatyw dla niektórych ukrytych interfejsów API. W XDA możemy mówić na podstawie doświadczenia, ponieważ niestety ta zmiana może oznaczać koniec niektórych innowacyjnych aplikacji lub może wymagać ograniczenia ich przez niektóre znane aplikacje funkcjonalność. Nadchodząca zmiana wydaje się podobna w duchu do ostatniej rozprawienie się z usługami dostępności (to było na szczęście wstrzymany ponieważ Google ocenił innowacyjne zastosowania). Chociaż większość aplikacji korzystających z nieudokumentowanych interfejsów API robi to z błahych powodów, niektóre aplikacje mogą niewłaściwie je wykorzystać do niecnych celów.
Z tego powodu Google może blokować dostęp do wszystkich ukrytych interfejsów API w systemie Android P, aby chronić użytkowników przed nielicznymi osobami, które ich nadużywają. Trudno powiedzieć, jak duży wpływ może to mieć na użytkowników, ale jeśli jesteś programistą rozważając przejrzenie AOSP w celu znalezienia innowacyjnego zastosowania ukrytego API, możesz chcieć zrewidować.
Aktualizacja: Google potwierdza
W post na blogu opublikowanych dzisiaj, 28 lutego, Google potwierdził te zmiany. Powołując się na ryzyko awarii dla użytkowników, a następnie zmuszając programistów do wprowadzenia poprawek awaryjnych, Google twierdzi, że firma stopniowo zmierza w kierunku zniechęcania programistów do korzystania z rozwiązań innych niż SDK interfejsy. Począwszy od Androida P, ograniczenia zostaną rozszerzone i obejmą interfejsy języka Java pakietu SDK.
Firma twierdzi, że „niektóre metody i pola inne niż SDK będą objęte ograniczeniami”, chociaż nie określiła, które z nich będą objęte ograniczeniami. Początkowo ograniczenie skupi się na interfejsach, które są rzadko używane, a przez jakiś czas firma na to pozwoli programistom do dalszego korzystania z metod i pól innych niż SDK, tam gdzie przejście na metodę SDK jest technicznie uzasadnione wyzywający. Jednak ostatecznie ograniczenia ulegną poszerzeniu, dlatego twórcy aplikacji korzystających z metod innych niż SDK powinni jak najszybciej przejść na tę technologię w ramach przygotowań do systemu Android P. Jeśli chodzi o metody bez alternatywy dla pakietu SDK, Google prosi programistów o opublikowanie ich na swoich plikach narzędzie do śledzenia błędów z dodatkowymi informacjami.
Następna wersja zapoznawcza dla programistów, która rzekomo pojawi się wkrótce, umożliwi programistom testowanie istniejących aplikacji na czarnej lub szarej liście przed wydaniem ostatecznej wersji.