Platforma Android korzysta z koncepcji piaskownicy aplikacji, aby zapewnić niezawodne wykonywanie i ochronę kodu aplikacji oraz granice procesów. W aplikacjach często występuje kod innych firm, często w formie pakietów SDK, np. pakietów SDK do reklam lub analityki. Dzięki temu deweloperzy aplikacji mogą skupić się na wyróżnieniu swojej aplikacji, korzystając jednocześnie z pracy ekspertów w danym temacie, aby zwiększyć skalę działania ponad to, co mogliby osiągnąć samodzielnie.
Podobnie jak w przypadku większości systemów operacyjnych, na Androidzie pakiety SDK są wykonywane w sandboksie aplikacji hosta i dziedziczą te same uprawnienia co aplikacja hosta, a także mają dostęp do pamięci i magazynu danych aplikacji hosta. Chociaż ta architektura umożliwia elastyczne integrowanie pakietów SDK i aplikacji, stwarza też potencjalne możliwości nieujawnionego gromadzenia i udostępniania danych użytkowników. Ponadto deweloperzy aplikacji mogą nie zdawać sobie w pełni sprawy z funkcjonalności pakietu SDK innej firmy i danych, do których ma on dostęp, przez co trudno jest im uwzględnić w swoich aplikacjach gromadzenie i udostępnianie danych.
W Androidzie 14 dodaliśmy nową funkcję platformy, która umożliwia uruchamianie pakietów SDK innych firm w dedykowanym środowisku wykonawczym o nazwie środowisko wykonawcze SDK. Środowisko wykonawcze SDK zapewnia te mocniejsze zabezpieczenia i gwarancje dotyczące gromadzenia i udostępniania danych użytkowników:
- zmodyfikowane środowisko wykonawcze,
- dobrze zdefiniowane uprawnienia i prawa dostępu do danych dla pakietów SDK;
Chcemy uzyskać opinie społeczności reklamodawców aplikacji mobilnych na temat tego projektu. Zachęcamy też do przesyłania opinii z szerszej społeczności deweloperów, abyśmy mogli kształtować przyszłe wersje środowiska wykonawczego pakietu SDK, w tym obsługę dodatkowych przypadków użycia.
Cele
Ta propozycja ma na celu osiągnięcie następujących celów:
- Ogranicz nieujawniony dostęp i udostępnianie danych aplikacji użytkownika przez zewnętrzne interfejsy SDK za pomocą izolacji procesów i dobrze zdefiniowanych ustawień dostępu do interfejsu API oraz danych. Więcej informacji o izolacji procesów znajdziesz w osobnej sekcji tego dokumentu.
- Ogranicz niejawne śledzenie sposobu korzystania z aplikacji przez zewnętrzne pakiety SDK, ograniczając dostęp do unikalnych, stałych identyfikatorów.
- przyspieszyć bezpieczną dystrybucję aktualizacji pakietu SDK w aplikacjach, zmniejszając obciążenie deweloperów aplikacji i użytkowników; Więcej informacji o zaproponowanym modelu zaufanej dystrybucji pakietów SDK znajdziesz w innej sekcji tego dokumentu.
- Pomagać deweloperom aplikacji w lepszym uwzględnianiu w swoich aplikacjach sposobów dostępu do danych i udostępniania danych.
- Pomagaj deweloperom pakietów SDK zapobiegać modyfikowaniu ich przez inne pakiety SDK poprzez ograniczanie pewnych niebezpiecznych konstrukcji językowych, takich jak kod JNI.
- Pomaga pakietom SDK do wyświetlania reklam w wykrywaniu nieprawidłowego ruchu i oszustw reklamowych oraz zapobieganiu im dzięki pełnej kontroli nad wyświetlaniem multimediów w widokach zdalnych.
- jak najbardziej ograniczyć niepotrzebny wpływ na deweloperów aplikacji i pakietów SDK;
Pakiety SDK są wykonywane w oddzielnym procesie.
Proponowane środowisko wykonawcze pakietu SDK umożliwia kompatybilnym pakietom SDK (w dalszej części tego dokumentu nazywanym pakietami SDK używanymi w czasie działania aplikacji) działanie w oddzielnym procesie aplikacji. Platforma umożliwia dwukierunkową komunikację między procesem aplikacji a środowiskiem wykonawczym pakietu SDK. Szczegółowe informacje znajdziesz w sekcji dotyczącej komunikacji w tym dokumencie. Pakiety SDK innych niż RE pozostaną w aplikacji tak jak dotąd. Te zmiany ilustrują poniższe diagramy:
Nowy zaufany model dystrybucji pakietów SDK
Proponowane oddzielenie pakietu SDK od aplikacji motywuje do zastosowania innej koncepcji oddzielnego rozpowszechniania pakietu SDK i aplikacji. Nasz projekt wymaga zaufanej dystrybucji i mechanizmu instalacji, aby zapewnić, że prawidłowe pakiety SDK są instalowane w czasie działania pakietu SDK aplikacji. Pomaga to chronić użytkowników i deweloperów aplikacji przed wczytywaniem nieprawidłowych pakietów SDK, a jednocześnie umożliwia sklepom z aplikacjami znaczne zmniejszenie obciążenia deweloperów związanego z dystrybucją pakietów SDK.
Pakiety SDK nie będą już musiały być łączone statycznie i pakowane razem z aplikacjami przed przesłaniem do sklepu z aplikacjami w celu dystrybucji. Zamiast tego zastosowano następującą procedurę:
- Deweloperzy pakietów SDK mogą przesyłać do sklepów z aplikacjami wersje pakietów SDK oddzielnie od samych aplikacji.
- Deweloperzy aplikacji mogą określić zależności pakietu SDK według wersji i kompilacji, a następnie przesłać wersję aplikacji, która nie zawiera rzeczywistych zależności pakietu SDK.
- Gdy użytkownik pobiera aplikację, proces instalacji może użyć określonych przez nią zależności pakietu SDK, aby pobrać je ze sklepu z aplikacjami.
Ten nowy mechanizm dystrybucji umożliwiłby deweloperom pakietów SDK wprowadzanie nieprzerwanych zmian (czyli bez zmian w interfejsach API lub ich semantyce) w pakietach SDK i ich dystrybucję na urządzenia bez udziału deweloperów aplikacji. Te zmiany w pakiecie SDK, które nie powodują przerw w działaniu aplikacji, można wdrożyć lub wycofać bez konieczności czekania, aż deweloperzy aplikacji ponownie utworzyli aplikacje z nowymi pakietami SDK, lub na to, aż użytkownicy zaktualizują aplikacje. Zmiany powodujące przerwanie nadal będą wymagać aktualizacji przez deweloperów aplikacji, ale deweloperzy pakietów SDK będą mogli szybciej i w bardziej ujednolicony sposób udostępniać najnowsze zmiany i poprawki, które nie powodują przerwania, większej liczbie osób, co pozwoli zminimalizować obsługę wersji.
Proponowane zmiany w rozprowadzaniu pakietu SDK ilustrują diagramy poniżej:
zmiany w sposobie tworzenia, uruchamiania i rozpowszechniania pakietów SDK i aplikacji;
To wstępna propozycja elastycznej technologii dystrybucji i czasu działania pakietu SDK. W następnych sekcjach proponujemy szereg zmian w ramach tych ogólnych kategorii:
- Dostęp: uprawnienia, pamięć, miejsce na dane
- Wykonanie: języki, zmiany w czasie wykonywania, cykl życia, renderowanie multimediów
- Komunikacja: komunikacja między aplikacją a pakietem SDK oraz między pakietami SDK
- Tworzenie: jak kompilować, debugować i testować ten model
- Rozpowszechnianie: jak rozpowszechniać, aktualizować i przywracać wersje Androida, aplikacje i pakiety SDK
Dokument zawiera też najczęstsze pytania.
To wstępna propozycja projektu, która może być ważną zmianą dla niektórych członków ekosystemu. Dlatego prosimy o przesyłanie opinii za pomocą śledzika problemów.
Dostęp
Zarządzanie prywatnością w systemie oznacza zarządzanie tym, w jaki sposób różne strony mogą uzyskiwać dostęp do różnych zasobów. Aby spełnić nasze oczekiwania dotyczące prywatności, proponujemy zaktualizowanie modelu dostępu do aplikacji, pakietów SDK i danych użytkownika zgodnie z zasadą jak najmniejszych uprawnień, aby zapobiec nieuprawnionemu dostępowi do potencjalnie poufnych danych.
Uprawnienia pakietu SDK
Jako oddzielny proces środowisko wykonawcze pakietu SDK będzie mieć własny, dobrze zdefiniowany zestaw uprawnień, a nie będzie dziedziczyć uprawnień przyznanych przez użytkownika aplikacji. Na podstawie wstępnych badań dotyczących uprawnień używanych przez pakiety SDK związane z reklamami proponujemy, aby środowisko wykonawcze pakietu SDK miało domyślnie dostęp do tych uprawnień:
INTERNET: dostęp do Internetu, aby nawiązać połączenie z usługą internetową.ACCESS_NETWORK_STATE: informacje o sieciach.READ_BASIC_PHONE_STATE: dostęp do informacji o stanie telefonu, np. o typie sieci komórkowej.- Uprawnienia dostępu do interfejsów API chroniących prywatność, które zapewniają podstawowe funkcje reklamowe bez konieczności uzyskiwania dostępu do identyfikatorów międzyaplikacyjnym.
AD_ID: możliwość żądania identyfikatora wyświetlania reklam. Dostęp do tego uprawnienia byłby również ograniczony przez aplikację.
Obecnie sprawdzamy, czy i jak autoryzować dodatkowe uprawnienia, aby ograniczyć wpływ na użytkowników pod względem prywatności i używalności. Prosimy o opinię na temat przypadków użycia, które nie są obsługiwane przez ten zestaw uprawnień.
Pamięć
Środowisko wykonawcze pakietu SDK będzie mieć własną izolowaną przestrzeń pamięci, ponieważ będzie mieć własny proces. Ta struktura domyślnie odmawia dostępu pakietowi SDK do przestrzeni pamięci aplikacji, a aplikacja nie ma dostępu do przestrzeni pamięci pakietu SDK. Proponujemy zachowanie tego domyślnego zachowania, aby zachować zgodność z zasadą minimalnych uprawnień.
Miejsce na dane
Celem tej propozycji jest zrównoważenie potrzeby dostępu pakietów SDK do pamięci w ramach normalnego działania oraz zminimalizowanie śledzenia w wielu aplikacjach i procesach za pomocą trwałej pamięci. Proponujemy następującą zmianę sposobu dostępu do miejsca na dane:
- Aplikacja nie będzie mieć bezpośredniego dostępu do pamięci pakietu SDK i odwrotnie.
- Zewnętrzna pamięć urządzenia nie będzie dostępna dla pakietów SDK.
- W ramach każdego środowiska wykonawczego SDK dostępne byłyby zarówno miejsce na dane dostępne dla wszystkich pakietów SDK, jak i miejsce na dane prywatne dla danego pakietu SDK.
Podobnie jak w przypadku obecnego modelu miejsca na dane, samo miejsce na dane nie będzie miało dowolnych limitów rozmiaru. Pakiety SDK mogą używać pamięci do przechowywania w buforze zasobów. To miejsce na dane jest okresowo czyszczone, gdy zestaw SDK nie jest aktywny.
Wykonanie
Aby zapewnić prywatność w systemie obejmującym aplikacje, pakiety SDK i użytkowników, kontekst wykonywania (formaty kodu, konstrukcje językowe, dostępne interfejsy API i dane systemowe) musi wzmacniać te granice prywatności lub przynajmniej nie umożliwiać ich obchodzenia. Jednocześnie chcemy zachować dostęp do bogatej platformy i większości funkcji dostępnych w pakietach SDK. Proponujemy zestaw aktualizacji środowiska wykonawczego, które pozwolą osiągnąć ten balans.
Kod
Kod Androida (aplikacje i pakiety SDK) jest interpretowany głównie przez środowisko wykonawcze Androida (ART), niezależnie od tego, czy został napisany w języku Kotlin czy Java. Bogactwo ART i oferowane przez niego konstrukcje językowe w połączeniu z możliwością weryfikacji, którą zapewnia w porównaniu z alternatywami, zwłaszcza z kodem natywnym, wydaje się zapewniać odpowiednią równowagę między funkcjonalnością a prywatnością. Proponujemy, aby kod pakietu SDK używanego w czasie działania aplikacji składał się wyłącznie z kodu bajtowego Dex, a nie obsługiwał dostępu JNI.
Zdajemy sobie sprawę, że w pewnych przypadkach, np. przy korzystaniu z niestandardowego pakietu SQLite, który ze względu na używanie kodu natywnego, należy zastąpić alternatywą, np. wbudowaną wersją SQLite w pakiecie Android SDK.
SELinux
W Androidzie każdy proces (w tym te, które działają jako root) jest uruchamiany w określonym kontekście SELinux, co pozwala jądrowi zarządzać kontrolą dostępu do usług systemowych, plików, urządzeń i innych procesów. Aby zachować większość zastosowań pakietu SDK, a jednocześnie zminimalizować możliwość obejścia zabezpieczeń prywatności, proponujemy następujące zmiany w kontekście SELinux aplikacji niesystemowej dla środowiska wykonawczego pakietu SDK:
- Dostępny byłby ograniczony zestaw usług systemowych. (w trakcie opracowywania)
- Pakiety SDK będą mogły wczytywać i wykonywać tylko kod w swoim pliku APK.
- Dostępny byłby ograniczony zestaw właściwości systemu. (w trakcie opracowywania)
Interfejsy API
W czasie działania pakietu SDK można używać mechanizmu odbicia lustrzanego i wywoływać interfejsy API. Pakiet SDK nie może jednak używać odbicia lustrzanego ani wywoływać interfejsów API w innym pakiecie SDK z włączoną obsługą czasu wykonywania. Pełną listę zakazanych interfejsów API opublikujemy w przyszłej aktualizacji.
Dodatkowo w ostatnich wersjach platformy Androida dostęp do trwałych identyfikatorów jest coraz bardziej ograniczany, aby zwiększyć ochronę prywatności. W przypadku pakietu SDK proponujemy dalsze ograniczenie dostępu do identyfikatorów, które mogą być używane do śledzenia między aplikacjami.
Interfejsy API środowiska wykonawczego pakietu SDK są dostępne tylko z aplikacji działających na pierwszym planie.
Próba uzyskania dostępu do interfejsów API SdkSandboxManager z aplikacji w tle powoduje wygenerowanie wyjątku SecurityException.
Ponadto RE-SDK nie może używać interfejsów API powiadomień do wysyłania powiadomień do użytkowników w dowolnym momencie.
Lifecycle
Pakiety SDK aplikacji obecnie podążają za cyklem życia aplikacji hosta, co oznacza, że gdy aplikacja przechodzi na pierwszy lub drugi plan, zamyka się lub jest wymuszająco zatrzymana przez system operacyjny z powodu braku pamięci, pakiety SDK aplikacji również to robią. Nasza propozycja oddzielenia pakietów SDK aplikacji do innego procesu oznacza te zmiany w cyklu życia:
- Aplikację może zamknąć użytkownik lub system operacyjny. Środowisko wykonawcze SDK zostanie automatycznie zamknięte natychmiast po tym.
Środowisko wykonawcze pakietu SDK może zostać zakończone przez system operacyjny z powodu braku pamięci lub nieobsługiwanej obsługi wyjątku w pakiecie SDK.
W przypadku Androida 14, gdy aplikacja jest na pierwszym planie, środowisko wykonawcze SDK działa z wysokim priorytetem i nie jest w większości przypadków zamykane. Gdy aplikacja przechodzi na drugi plan, priorytet procesu środowiska uruchomieniowego pakietu SDK spada i może zostać zakończony. Priorytet procesu środowiska uruchomieniowego pakietu SDK pozostaje niski, nawet jeśli aplikacja wraca na pierwszy plan. W konsekwencji istnieje duże prawdopodobieństwo, że zostanie ono zamknięte z powodu obciążenia pamięci w porównaniu z aplikacją.
W Androidzie 14 i nowszych wersjach priorytety procesów aplikacji i czasu wykonywania pakietu SDK są dopasowane. Priorytety przetwarzania
ActivityManager.RunningAppProcessInfo.importanceaplikacji i czasu wykonywania pakietu SDK powinny być mniej więcej takie same.Jeśli środowisko wykonawcze pakietu SDK zostanie zamknięte, gdy aplikacja jest aktywna (np. gdy w pakiecie SDK wystąpi nieobsługiwany wyjątek), stan środowiska wykonawczego pakietu SDK, w tym wszystkie wcześniej załadowane pakiety SDK i widoki zdalne, zostaną utracone. Deweloperzy aplikacji mogą rozwiązać problem z zakończeniem działania środowiska wykonawczego pakietu SDK za pomocą jednej z tych metod:
- Proponowana zmiana udostępnia deweloperom aplikacji powiązane metody wywołania cyklu życia, aby umożliwić im wykrywanie zakończenia działania środowiska wykonawczego pakietu SDK.
- Jeśli środowisko uruchomieniowe SDK zostanie zamknięte podczas wyświetlania reklam, reklamy mogą nie działać zgodnie z oczekiwaniami. Na przykład widok może być zamrożony na ekranie i nie będzie już interaktywny. Aplikacja może usunąć widok reklamy, jeśli nie wpływa na komfort użytkownika.
- Aplikacja może podjąć kolejną próbę załadowania pakietów SDK i poprosić o reklamy.
- W Androidzie 14, jeśli środowisko wykonawcze SDK zostanie zamknięte, gdy są w nim załadowane pakiety SDK, a deweloper aplikacji nie zarejestrował wspomnianych wcześniej metod wywołania cyklu życia, aplikacja zostanie zamknięta domyślnie. Tylko procesy aplikacji, które wczytały pakiety SDK, są zamykane i zamykają się normalnie.
- Obiekty bindera zwracane przez pakiet SDK do komunikacji z nim (takie jak
SandboxedSdk) rzucająDeadObjectException, jeśli są używane przez aplikację.
Ten model cyklu życia może ulec zmianie w kolejnych aktualizacjach.
W przypadku ciągłych awarii deweloper aplikacji powinien zaplanować łagodne obniżenie jakości bez pakietu SDK lub powiadomić użytkownika, jeśli pakiet SDK jest niezbędny do prawidłowego działania głównej funkcji aplikacji. Więcej informacji o tej interakcji aplikacji z pakietem SDK znajdziesz w sekcji dotyczącej komunikacji w tym dokumencie.
Pakiety SDK inne niż RE mogą nadal używać standardowych elementów systemu operacyjnego dostępnych dla wbudowanej aplikacji, w tym usług, działań i transmisji, podczas gdy pakiety SDK RE nie mogą tego robić.
Przypadki szczególne
Te przypadki nie są obsługiwane i mogą powodować nieoczekiwane działanie:
- Jeśli wiele aplikacji ma ten sam identyfikator UID, środowisko uruchomieniowe pakietu SDK może nie działać prawidłowo. W przyszłości możemy dodać obsługę udostępnionych identyfikatorów UID.
- W przypadku aplikacji z wieloma procesami ładowanie pakietu SDK powinno odbywać się w głównym procesie.
Renderowanie multimediów
Niektóre zestawy SDK renderują treści takie jak tekst, obrazy i filmy w określonym przez aplikację widoku. Aby to osiągnąć, proponujemy zrenderowanie zdalne, w którym pakiet SDK będzie renderować treści multimedialne w środowisku wykonawczym pakietu SDK, ale użyje interfejsu API SurfaceControlViewHost, aby umożliwić renderowanie treści w widoku określonym przez aplikację. Umożliwia to pakietowi SDK renderowanie multimediów w sposób prywatny dla użytkownika, a także zapobieganie nieprawidłowym lub oszukańczym interakcjom użytkownika z renderowanymi multimediami oraz ich wykrywanie.
Reklamy natywne, które nie są renderowane przez pakiet SDK, ale przez aplikację, będą obsługiwane przez pakiety SDK w środowisku wykonawczym SDK. Proces zbierania sygnałów i pobierania kreacji będzie przebiegał w sposób spójny z reklamami innymi niż natywne. To jest aktywny obszar badań.
Reklamy wideo typu In-Stream to reklamy wyświetlane w odtwarzaczu w aplikacji. Ponieważ film jest odtwarzany w odtwarzaczu w aplikacji, a nie w odtwarzaczu lub widoku w pakiecie SDK, model renderowania różni się od innych formatów reklam. Aktywnie badamy mechanizmy, które obsługują zarówno wstawianie reklam po stronie serwera, jak i wstawianie reklam za pomocą pakietu SDK.
Stan systemu
Staramy się zminimalizować wpływ środowiska wykonawczego pakietu SDK na działanie systemu na urządzeniach użytkowników. W tym celu opracowujemy różne rozwiązania. Prawdopodobnie jednak niektóre podstawowe urządzenia z Androidem 14 o bardzo ograniczonych zasobach systemowych, takie jak Android (edycja Go), nie będą obsługiwać środowiska wykonawczego pakietu SDK ze względu na wpływ na działanie systemu. Wkrótce udostępnimy wymagania minimalne niezbędne do prawidłowego korzystania z czasu wykonywania pakietu SDK.
Komunikacja
Aplikacje i pakiety SDK działają obecnie w ramach tego samego procesu, więc komunikacja między nimi jest nieograniczona i bezpośrednia. Ponadto Android umożliwia komunikację między aplikacjami, nawet jeśli komunikacja rozpoczyna się i kończy w pakietach SDK. Ten model swobodnej komunikacji umożliwia różne przypadki użycia, a zarazem stwarza możliwość niejawnego udostępniania danych między aplikacjami i pakietami SDK w ich obrębie oraz między aplikacjami. Proponujemy w tym modelu komunikacji wprowadzić następujące zmiany, aby osiągnąć równowagę między wartością takiej komunikacji a realizacją naszych celów.
Aplikacja – pakiet SDK
Interfejs między aplikacją a pakietem SDK to najczęstsza ścieżka komunikacji z pakietem SDK, a interfejs API pakietu SDK to miejsce, w którym tkwi większość różnic i innowacji skierowanych do użytkowników. Chcemy zachować możliwość wprowadzania innowacji i różnicowania się w przypadku pakietów SDK. Dzięki temu nasze propozycje umożliwiają pakietom SDK udostępnianie interfejsów API aplikacjom i zapewniają, że aplikacje mogą korzystać z wszystkich tych innowacji.
Ze względu na strukturę granicy procesu w pakiecie SDK Runtime proponujemy stworzenie warstwy porządkowania dostępnej w aplikacji, która będzie przenosić wywołania interfejsu API i odpowiedzi lub wywołania zwrotne przez tę granicę między aplikacją a pakietem SDK. Proponujemy, aby interfejs tej warstwy przekazywania danych był definiowany przez programistów pakietu SDK i generowany przez oficjalne narzędzia do kompilacji typu open source, które opracujemy.
Ta propozycja ma na celu odciążenie deweloperów aplikacji i pakietów SDK od rutynowych zadań związanych z zarządzaniem typami danych, a zarazem zapewnić deweloperom pakietów SDK większą elastyczność i zapewnić, że kod pakietu SDK będzie działał w czasie działania pakietu SDK, co pozwoli nam realizować nasze cele związane z prywatnością. Jeśli zdecydujemy się na ten kierunek, język definicji interfejsu API i narzędzie do jego tworzenia będą musiały być opracowane z uwzględnieniem Twoich opinii.
Ogólny model interakcji wyglądałby tak:
- Aplikacja wywołuje pakiet SDK przez interfejs, przekazując wywołania zwrotne.
- Pakiet SDK asynchronicznie spełnia żądania i reaguje za pomocą funkcji wywołania zwrotnego.
- Można to zastosować do dowolnego modelu wydawca–subskrybent, co oznacza, że aplikacja może subskrybować zdarzenia w pakiecie SDK za pomocą wywołań zwrotnych, które będą wywoływane, gdy te zdarzenia wystąpią.
W ramach nowej struktury międzyprocesowej w propozycji występują 2 cykle życia procesu, którymi trzeba zarządzać: jeden dla samej aplikacji, a drugi dla środowiska uruchomieniowego pakietu SDK. Nasza propozycja ma na celu zautomatyzowanie jak największej liczby tych procesów, aby zminimalizować wpływ na deweloperów aplikacji i pakietów SDK. Poniższy diagram przedstawia jedno z rozważanych przez nas podejść:
Platforma udostępniałaby nowe interfejsy API, aby aplikacje mogły dynamicznie wczytywać pakiety SDK do procesu środowiska uruchomieniowego pakietu SDK, otrzymywać powiadomienia o zmianach stanu tego procesu oraz wchodzić w interakcje z pakietami SDK wczytanymi do środowiska uruchomieniowego pakietu SDK.
Wykres na poprzednim rysunku pokazuje komunikację aplikacji z pakietem SDK na niższym poziomie bez warstwy porządkowania.
Aplikacja komunikuje się z pakietem SDK działającym w procesie środowiska uruchomieniowego pakietu SDK w następujący sposób:
Zanim aplikacja mogła wchodzić w interakcję z pakietem SDK, musiała poprosić platformę o załadowanie tego pakietu. Aby zapewnić integralność systemu, aplikacje musiałyby określać pakiety SDK, które zamierzają wczytać w pliku manifestu. Te pakiety SDK byłyby jedynymi, które można by wczytać.
Przykładowy fragment kodu interfejsu API:
SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor, OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)Pakiet SDK otrzymuje powiadomienie o załadowaniu i zwraca interfejs. Ten interfejs jest przeznaczony do użytku przez proces aplikacji. Aby udostępnić interfejs poza granicami procesu, musisz go zwrócić jako obiekt
IBinder.Przewodnik po usługach przesyłania danych zawiera różne sposoby udostępniania
IBinder. Niezależnie od tego, którą metodę wybierzesz, musisz ją zastosować w pakiecie SDK i aplikacji wywołującej. Na diagramach przykładowo użyto interfejsu AIDL.SdkSandboxManagerodbiera interfejsIBinderi zwraca go do aplikacji.Aplikacja pobiera
IBinderi przekształca go w interfejs pakietu SDK, wywołując jego funkcje:IBinder binder = sandboxSdk.getInterface(); ISdkInterface mySdkInterface = ISdkInterface.Stub.asInterface(binder); mySdkInterface.something();
Aplikacja może też renderować multimedia z pakietu SDK, wykonując te czynności:
Jak wyjaśniono w sekcji dotyczącej renderowania multimediów w tym dokumencie, aby aplikacja mogła uzyskać pakiet SDK do renderowania multimediów w widoku, może ona wywołać funkcję
requestSurfacePackage()i pobrać odpowiednią funkcjęSurfaceControlViewHost.SurfacePackage.Poniższy fragment kodu przedstawia przykład interfejsu API:
SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams, Executor executor, OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)Aplikacja może następnie umieścić zwrócone dane
SurfacePackagewSurfaceViewza pomocą interfejsu APIsetChildSurfacePackagewSurfaceView.Poniższy fragment kodu przedstawia przykład interfejsu API:
SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
Proponujemy, aby interfejsy API IBinder i requestSurfacePackage() były ogólne i nie były wywoływane bezpośrednio przez aplikacje. Zamiast tego te interfejsy API byłyby wywoływane przez wygenerowane odwołanie do interfejsu API, o którym mowa powyżej, w warstwie „shim”, aby zmniejszyć obciążenie programistów aplikacji.
Pakiet SDK do pakietu SDK
Dwa pakiety SDK w tej samej aplikacji często muszą ze sobą współpracować. Może się to zdarzyć, gdy dany pakiet SDK jest zbudowany z elementów innych pakietów SDK. Może się to też zdarzyć, gdy 2 pakiety SDK od różnych stron muszą współpracować, aby spełnić żądanie aplikacji wywołującej.
Należy wziąć pod uwagę 2 kluczowe przypadki:
- Gdy oba pakiety SDK są włączone w czasie działania aplikacji. W tym przypadku oba pakiety SDK są uruchamiane w środowisku wykonawczym SDK ze wszystkimi zabezpieczeniami. Pakiety SDK nie mogą się komunikować tak, jak obecnie w aplikacji. W związku z tym dodaliśmy interfejs API
SdkSandboxController, który umożliwia pobieranie obiektówSandboxedSdkdla wszystkich załadowanych pakietów SDK RE. Umożliwia to pakietowi SDK RE komunikowanie się z innymi pakietami SDK załadowanymi w czasie działania pakietu SDK. - Gdy tylko 1 pakiet SDK jest używany w czasie działania.
- Jeśli wywołujący pakiet SDK działa w aplikacji, działa to tak samo jak w przypadku wywołania drugiego pakietu SDK przez samą aplikację w środowisku wykonawczym SDK.
- Jeśli wywołujący pakiet SDK działa w środowisku wykonawczym pakietu SDK, zalecamy ujawnienie metody za pomocą funkcji
IBinderopisanej w sekcji „Komunikacja aplikacji z pakietem SDK”, która w aplikacji będzie nasłuchiwać, przetwarzać i wywoływać metody wywołania z dostarczonymi wywołaniami zwrotnymi. - Pakiety SDK do wyświetlania reklam, które nie są włączone w czasie działania, mogą nie być w stanie zarejestrować się same. Proponujemy utworzenie pośredniczącego pakietu SDK, który zawiera pakiety SDK partnerów lub aplikacji jako bezpośrednie zależności aplikacji i zajmuje się rejestracją. Ten pakiet SDK mediatora nawiązuje komunikację między pakietami SDK bez środowiska wykonawczego lub innymi zależnościami aplikacji a pakietem mediatora z włączonym środowiskiem wykonawczym, który działa jako adapter.
Zestaw funkcji do komunikacji między pakietami SDK został podzielony na te kategorie:
- Komunikacja między pakietami SDK w środowisku wykonawczym SDK (dostępna w najnowszej wersji podglądu dla deweloperów)
- Komunikacja między pakietami SDK w aplikacji a środowiskiem wykonawczym SDK (dostępna w najnowszej wersji w ramach wersji dla deweloperów)
- Jak powinny działać wyświetlenia i renderowanie zdalne w przypadku zapośredniczenia (propozycja w trakcie opracowywania)
Podczas projektowania prymitywów bierzemy pod uwagę te przypadki użycia:
- Mediacja i określanie stawek. Wiele pakietów SDK do reklamy oferuje funkcję zapośredniczenia lub określania stawek, w ramach której pakiet SDK wywołuje różne inne pakiety SDK w celu wyświetlenia reklamy (zapośredniczenie) lub zebrania sygnałów w celu przeprowadzenia aukcji (określanie stawek). Zazwyczaj pakiet SDK koordynujący wywołuje inne pakiety SDK za pomocą adaptera udostępnionego przez pakiet SDK koordynujący. Z powodu powyższych funkcji podstawowych pakiet SDK koordynujący (czyli RE lub nie) powinien mieć dostęp do wszystkich pakietów SDK RE i niebędących RE, aby zapewnić prawidłowe działanie. W tym kontekście renderowanie jest przedmiotem naszych badań.
- Odkrywanie funkcji. Niektóre produkty SDK składają się z mniejszych pakietów SDK, które w ramach procesu wykrywania między pakietami SDK określają ostateczny zestaw funkcji udostępnianych deweloperowi aplikacji. W tym przypadku powinny być używane prymitywne funkcje rejestracji i wykrywania.
- Modele subskrypcji wydawców. Niektóre pakiety SDK są zaprojektowane tak, aby miały centralnego wydawcę zdarzeń, do którego inne pakiety SDK lub aplikacje mogą się subskrybować w celu otrzymywania powiadomień za pomocą wywołań zwrotnych. Powyższe prymitywy powinny obsługiwać ten przypadek użycia.
Aplikacja do aplikacji
Komunikacja między aplikacjami występuje, gdy co najmniej 1 z 2 procesów jest obsługiwany przez pakiet SDK z uruchomieniem w czasie wykonywania i jest potencjalnym wektorem nieujawnionego udostępniania danych. W konsekwencji środowisko wykonawcze SDK nie może nawiązać bezpośredniego kanału komunikacji z żadną aplikacją inną niż aplikacja kliencka ani z pakietami SDK w innym środowisku wykonawczym SDK utworzonym dla innej aplikacji. Osiąga się to w następujący sposób:
- Pakiet SDK nie może definiować w pliku manifestu komponentów takich jak
<service>,<contentprovider>czy<activity>. - Pakiet SDK nie może opublikować
ContentProviderani wysłać transmisji. - Pakiet SDK może uruchamiać aktywność należącą do innej aplikacji, ale z ograniczeniami dotyczącymi tego, co można wysłać w intencji. Nie można na przykład dodawać do tego zamiaru żadnych dodatkowych elementów ani działań niestandardowych.
- Pakiet SDK może tylko uruchamiać lub wiązać się z listą dozwolonych usług.
- Pakiet SDK ma dostęp tylko do podzbioru systemu
ContentProvider(np.com.android.providers.settings.SettingsProvider), w którym uzyskane dane nie zawierają identyfikatorów i nie można ich użyć do utworzenia odcisku palca użytkownika. Te kontrole dotyczą również uzyskiwania dostępu doContentProviderza pomocąContentResolver. - Pakiet SDK ma dostęp tylko do podzbioru chronionych odbiorników transmisji (takich jak
android.intent.action.AIRPLANE_MODE).
Tagi pliku manifestu
Po zainstalowaniu pakietu SDK PackageManager analizuje jego plik manifestu i nie instaluje go, jeśli zawiera on zabronione tagi. Pakiet SDK może na przykład nie definiować komponentów takich jak <service>, <activity>, <provider> czy <receiver>, a także nie deklarować w pliku manifestu elementu <permission>. Tagi, które nie zostały zainstalowane, nie są obsługiwane w środowisku wykonawczym pakietu SDK. Tagi, które nie powodują niepowodzenia instalacji, ale są po cichu ignorowane, mogą być obsługiwane w przyszłych wersjach Androida.
Te weryfikacje mogą być też stosowane przez dowolne narzędzia używane przez pakiet SDK do tworzenia pakietu SDK oraz w momencie przesyłania do sklepu z aplikacjami.
Pomoc dotycząca aktywności
Pakiety SDK w środowisku wykonawczym pakietu SDK nie mogą dodawać do pliku manifestu tagu aktywności ani uruchamiać własnych aktywności za pomocą Context.startActivity.
Zamiast tego platforma tworzy aktywności dla pakietów SDK na żądanie i udostępnia je tym pakietom.
Aktywność na platformie jest typu android.app.Activity. Aktywność platformy rozpoczyna się od jednej z aktywności aplikacji i jest częścią zadania aplikacji.
FLAG_ACTIVITY_NEW_TASK nie jest obsługiwane.
Aby pakiet SDK mógł rozpocząć aktywność, musi zarejestrować instancję typu SdkSandboxActivityHandler, która służy do powiadamiania o tworzeniu aktywności, gdy aplikacja wywołuje funkcję SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder), aby rozpocząć aktywność.
Proces żądania aktywności przedstawiono na wykresie poniżej.
Programowanie
Kluczową zasadą w tej propozycji jest w jak największym stopniu ograniczenie wpływu na ekosystem deweloperów. Ta propozycja oferuje deweloperom kompleksowy zestaw narzędzi programistycznych do tworzenia, kompilowania i debugowania aplikacji i pakietów SDK na potrzeby RE. Aby zapewnić integralność tej propozycji, wprowadziliśmy pewne zmiany w sposobie konfigurowania, tworzenia i kompilowania aplikacji i pakietów SDK do gier.
Tworzenie
Android Studio i powiązane narzędzia zostaną zaktualizowane, aby uwzględniały środowisko wykonawcze SDK. Dzięki temu deweloperzy będą mogli prawidłowo skonfigurować aplikacje i pakiety SDK RE oraz w odpowiednich przypadkach zaktualizować starsze lub nieobsługiwane wywołania na nowsze odpowiedniki. W trakcie fazy tworzenia nasza propozycja wymaga od deweloperów wykonania kilku czynności.
Programiści aplikacji
Aplikacje muszą określać zależności od pakietu SDK i certyfikatu pakietu SDK w pliku manifestu aplikacji. W ramach naszej propozycji traktujemy ją jako źródło informacji od dewelopera aplikacji. Na przykład:
- Nazwa: nazwa pakietu pakietu SDK lub biblioteki.
- Wersja główna: kod wersji głównej pakietu SDK.
- Podsumowanie certyfikatu: podsumowanie certyfikatu kompilacji pakietu SDK. W przypadku danej kompilacji zalecamy deweloperowi pakietu SDK uzyskanie i zarejestrowanie tej wartości w odpowiednim sklepie z aplikacjami.
Dotyczy to tylko pakietów SDK rozpowszechnianych w sklepach z aplikacjami, niezależnie od tego, czy są one zgodne z zasadami. Aplikacje, które statycznie łączą pakiety SDK, będą używać obecnych mechanizmów zależności.
Aby ograniczyć wpływ na programistów do minimum, ważne jest, aby po określeniu docelowego poziomu interfejsu API obsługującego środowisko wykonawcze pakietu SDK deweloperzy aplikacji mieli tylko jedną wersję, która działa na urządzeniach obsługujących środowisko wykonawcze pakietu SDK lub nie.
Deweloperzy pakietów SDK
W proponowanym przez nas rozwiązaniu deweloperzy pakietów SDK RE muszą w manifeście wyraźnie zadeklarować nowy element reprezentujący pakiet SDK lub element biblioteki. Dodatkowo należy podać podobny zestaw wartości, jak w przypadku zależności, z dodatkiem wersji podrzędnej:
- Nazwa: nazwa pakietu pakietu SDK lub biblioteki.
- Wersja główna: kod wersji głównej pakietu SDK.
- Wersja pomocnicza: kod wersji pomocniczej pakietu SDK.
Jeśli deweloperzy pakietów SDK RE mają inne pakiety SDK RE jako zależności na etapie kompilacji, prawdopodobnie będą musieli zadeklarować je w taki sam sposób, w jaki deweloper aplikacji deklaruje te same zależności. Pakiety SDK RE zależne od innych pakietów SDK niebędących RE byłyby powiązane ze sobą statycznie. Może to spowodować problemy, które zostaną wykryte w momencie kompilacji lub podczas testów, jeśli pakiety SDK innych niż RE wymagają funkcji, których środowisko wykonawcze SDK nie obsługuje, lub jeśli muszą działać w ramach procesu aplikacji.
Deweloperzy RE SDK prawdopodobnie będą nadal obsługiwać urządzenia bez RE, takie jak Android 12 lub starszy, a także urządzenia z Androidem 14 na poziomie podstawowym z bardzo ograniczonymi zasobami systemowymi, o których wspomina sekcja dotycząca stanu systemu w tym dokumencie. Pracujemy nad metodami, które pozwolą deweloperom SDK zachować jeden kod źródłowy, aby obsługiwać środowisko RE i środowiska inne niż RE.
Kompilacje
Programiści aplikacji
Spodziewamy się, że deweloperzy aplikacji nie zauważą dużych zmian w kroku kompilacji. Zależności pakietu SDK, niezależnie od tego, czy są rozpowszechniane lokalnie, czy w sklepie z aplikacjami (z uwzględnieniem lub bez uwzględnienia RE), muszą być dostępne na komputerze, aby można było przeprowadzić linting, kompilację i tworzenie wersji. Proponujemy, aby Android Studio ukrywało te informacje przed deweloperem aplikacji podczas normalnego korzystania z aplikacji i aby było to jak najbardziej przejrzyste.
Chociaż oczekujemy, że kompilacja DEBUG powinna zawierać cały kod i symbole, aby umożliwić debugowanie, kompilacje RELEASE mogą opcjonalnie zawierać wszystkie pakiety SDK rozpowszechniane w sklepie z aplikacjami (z opcją RE lub bez niej), które zostały usunięte z pliku końcowego.
Jesteśmy na wczesnym etapie projektowania i udostępnimy więcej informacji, gdy tylko będziemy mogli.
Deweloperzy pakietów SDK
Pracujemy nad rozwiązaniem, które umożliwi tworzenie wersji niestandardowych i standardowych pakietu SDK w jednym pliku do dystrybucji. Dzięki temu deweloperzy aplikacji nie musieliby obsługiwać osobnych wersji pakietu SDK dla wersji z uwzględnieniem RE i bez uwzględnienia RE.
Podobnie jak w przypadku aplikacji, wszystkie pakiety SDK z zależnościami rozpowszechniane w sklepach z aplikacjami muszą znajdować się na komputerze, aby umożliwić sprawdzanie kodu, kompilację i tworzenie wersji. Oczekujemy, że Android Studio będzie to robić bezproblemowo.
Testowanie
Programiści aplikacji
Zgodnie z naszą propozycją deweloperzy aplikacji mogliby testować swoje aplikacje na urządzeniach z Androidem 14 tak jak do tej pory. Po skompilowaniu aplikacji można ją zainstalować na urządzeniu RE lub w emulatorze. Dzięki temu procesowi instalacji odpowiednie pakiety SDK zostaną zainstalowane w pakiecie SDK Runtime na urządzeniu lub emulatorze, niezależnie od tego, czy zostały one pobrane z zdalnego repozytorium pakietu SDK, czy z pamięci podręcznej systemu kompilacji.
Deweloperzy pakietów SDK
Deweloperzy pakietów SDK zwykle testują swoje rozwiązania za pomocą własnych aplikacji testowych na urządzeniach i emulatorach. Nasza propozycja nie zmienia tego stanu rzeczy. Weryfikacja w aplikacji będzie przebiegać w taki sam sposób jak opisana powyżej dla deweloperów aplikacji. W przypadku zarówno aplikacji z usługami w tle, jak i bez nich będzie używany jeden artefakt kompilacji. Deweloperzy pakietów SDK będą mogli debugować swój kod niezależnie od tego, czy jest on w czasie wykonywania pakietu SDK, ale mogą wystąpić pewne ograniczenia w przypadku zaawansowanych narzędzi debugowania i profilowania. To jest aktywny obszar badań.
Dystrybucja
Nasza propozycja dotycząca rozdzielenia aplikacji od pakietów SDK umożliwiła dystrybucję pakietów SDK w sklepach z aplikacjami. Jest to ogólna możliwość, która nie jest charakterystyczna dla żadnego konkretnego sklepu z aplikacjami. Korzyści są oczywiste:
- Zadbaj o jakość i spójność pakietów SDK.
- uproszczenie publikowania dla deweloperów pakietów SDK;
- przyspieszenie wdrażania aktualizacji wersji pomocniczych pakietu SDK w zainstalowanych aplikacjach;
Aby umożliwić dystrybucję pakietu SDK, sklep z aplikacjami musi zapewniać większość z tych funkcji:
- Mechanizm umożliwiający deweloperom pakietów SDK przesyłanie do sklepu pakietów SDK przeznaczonych do dystrybucji w sklepie, aktualizowanie ich, przywracanie do poprzedniej wersji i usuwanie.
- Mechanizm zapewniający integralność pakietu SDK i jego pochodzenia oraz aplikacji i jej pochodzenia oraz rozwiązujący ich zależności.
- mechanizm ich wdrażania na urządzenia w sposób niezawodny i wydajny;
Zmiany ograniczeń na przestrzeni czasu
Spodziewamy się, że ograniczenia dotyczące kodu w środowisku wykonawczym pakietu SDK będą się zmieniać wraz z nowszymi wersjami Androida. Aby zapewnić zgodność aplikacji, nie zmienimy tych ograniczeń w ramach aktualizacji głównego modułu dla danego poziomu pakietu SDK. Zachowanie związane z danym targetSdkVersion jest zachowane do czasu wycofania obsługi tego targetSdkVersion zgodnie z zasadami sklepu z aplikacjami. Wycofanie targetSdkVersion może nastąpić w szybszym tempie niż w przypadku aplikacji.
Należy się spodziewać, że ograniczenia będą często zmieniać się w różnych wersjach pakietu Android SDK, zwłaszcza w pierwszych kilku wersjach.
Dodatkowo tworzymy mechanizm kanarków, który pozwoli testerom zewnętrznym i wewnętrznym dołączyć do grupy, w której obowiązuje proponowany zestaw ograniczeń dla następnej wersji Androida. Pomoże nam to uzyskać opinię i potwierdzić zaproponowane zmiany w zestawie ograniczeń.
Najczęstsze pytania
-
Co to jest pakiet SDK do obsługi reklam?
Pakiet SDK związany z reklamami to taki, który umożliwia kierowanie na użytkowników z wiadomościami o charakterze komercyjnym w aplikacjach, które nie należą do reklamodawcy. Obejmuje to m.in. pakiety SDK do analizy, za pomocą których można tworzyć grupy użytkowników do dalszego kierowania, pakiety SDK do wyświetlania reklam, pakiety SDK do zapobiegania nadużyciom i do zwalczania oszustw w reklamach, pakiety SDK do zwiększania zaangażowania użytkowników oraz pakiety SDK do przypisywania.
-
Czy w środowisku wykonawczym SDK może działać dowolny pakiet SDK?
Chociaż początkowo skupiamy się na pakietach SDK związanych z reklamami, deweloperzy pakietów SDK niezwiązanych z reklamami, którzy chcą chronić prywatność użytkowników i wierzą, że mogą działać zgodnie z wymienionymi powyżej warunkami, mogą przesyłać opinie na temat swoich pakietów SDK działających w środowisku wykonawczym SDK. Środowisko wykonawcze SDK nie jest jednak zgodne ze wszystkimi wersjami pakietu SDK. Poza udokumentowanymi ograniczeniami środowisko wykonawcze SDK nie jest odpowiednie dla pakietów SDK, które wymagają komunikacji z aplikacją hostującą w czasie rzeczywistym lub z dużą przepustowością.
-
Dlaczego warto wybrać izolację procesu zamiast izolacji w czasie wykonywania procesu w języku Java?
Obecnie środowisko uruchomieniowe oparte na Javie nie zapewnia łatwego dostępu do zabezpieczeń, które są niezbędne do zapewnienia użytkownikom Androida prywatności. Wdrożenie takiego rozwiązania wymagałoby prawdopodobnie wieloletniego wysiłku, ale nie dałoby gwarancji sukcesu. Dlatego Piaskownica prywatności wykorzystuje granice procesu, czyli sprawdzoną i dobrze zrozumiałą technologię.
-
Czy przeniesienie pakietów SDK do procesu runtime pakietu SDK pozwoli zaoszczędzić miejsce na pobranie lub na dysku?
Jeśli wiele aplikacji jest zintegrowanych z pakietami SDK używanymi w czasie działania w tej samej wersji, może to zmniejszyć rozmiar pobierania i zajętą przestrzeń na dysku.
-
Do jakich zdarzeń z cyklu życia aplikacji, np. do zdarzeń związanych z przejściem aplikacji w tło, będą mieć dostęp pakiety SDK w środowisku wykonawczym SDK?
Aktywnie pracujemy nad zapewnieniem możliwości powiadamiania pakietu SDK o zdarzeniach cyklu życia aplikacji klienta na poziomie aplikacji (np. o przechodzeniu aplikacji na drugi plan i powrocie na pierwszy plan). Projekt i przykładowy kod zostaną udostępnione w nadchodzącej wersji przedpremierowej dla programistów.
Polecane dla Ciebie
- Uwaga: tekst linku jest wyświetlany, gdy obsługa JavaScript jest wyłączona
- Pakiet SDK Runtime – przewodnik dla programistów