Przegląd środowiska wykonawczego SDK

Platforma Android wykorzystuje koncepcję piaskownicy aplikacji, aby zachować solidne granice wykonywania i bezpieczeństwa kodu aplikacji, a także granice procesów. Aplikacje często zawierają kod innych firm, zwykle w postaci pakietów SDK, takich jak pakiety SDK do reklam lub analityki. Dzięki temu programiści mogą skupić się na wyróżnieniu swojej aplikacji, a jednocześnie wykorzystywać pracę ekspertów w danej dziedzinie, aby zwiększyć skalę swoich działań ponad to, co mogliby łatwo osiągnąć samodzielnie.

Podobnie jak w większości systemów operacyjnych, w Androidzie pakiety SDK są wykonywane w piaskownicy aplikacji hosta i dziedziczą te same uprawnienia i pozwolenia co aplikacja hosta, a także mają dostęp do jej pamięci i miejsca na dane. Ta architektura umożliwia elastyczną integrację pakietów SDK i aplikacji, ale stwarza też możliwość nieujawnionego zbierania i udostępniania danych użytkowników. Deweloperzy aplikacji mogą nie mieć pełnej świadomości zakresu funkcji pakietu SDK innej firmy i danych, do których ma on dostęp, co utrudnia uwzględnienie praktyk zbierania i udostępniania danych w ich aplikacji.

W Androidzie 14 dodaliśmy nową funkcję platformy, która umożliwia pakietom SDK innych firm działanie w dedykowanym środowisku wykonawczym o nazwie środowisko wykonawcze SDK. Środowisko wykonawcze SDK zapewnia następujące 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

Aktywnie zbieramy opinie społeczności reklamodawców aplikacji mobilnych na temat tego projektu. Zachęcamy też całą społeczność deweloperów do przekazywania opinii, które pomogą nam 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 tych celów:

• Ogranicz nieujawniony dostęp do danych aplikacji użytkownika i ich udostępnianie przez SDK innych firm za pomocą izolacji procesów oraz dobrze zdefiniowanego interfejsu API i kontroli dostępu do danych. Więcej informacji o izolacji procesów znajdziesz w osobnej sekcji tego dokumentu.
• Ograniczanie nieujawnionego śledzenia korzystania z aplikacji przez użytkownika za pomocą pakietów SDK innych firm przez ograniczenie dostępu pakietów SDK do unikalnych, trwałych identyfikatorów.
• Bezpiecznie przyspieszaj rozpowszechnianie aktualizacji pakietów SDK w aplikacjach, zmniejszając obciążenie deweloperów aplikacji i użytkowników. Więcej informacji o proponowanym modelu zaufanej dystrybucji pakietów SDK znajdziesz w innej sekcji tego dokumentu.
• Pomóż deweloperom aplikacji lepiej uwzględniać sposoby dostępu do danych i ich udostępniania w swoich aplikacjach.
• Pomaganie deweloperom pakietów SDK w zapobieganiu manipulacjom ze strony innych pakietów SDK poprzez ograniczanie niektórych niebezpiecznych konstrukcji językowych, takich jak kod JNI.
• Pomagają pakietom SDK do wyświetlania reklam wykrywać nieprawidłowy ruch i oszustwa reklamowe oraz im zapobiegać dzięki pełnej kontroli nad zdalnymi widokami wyświetlającymi multimedia.
• Zminimalizować w jak największym stopniu nieuzasadniony wpływ na deweloperów aplikacji i pakietów SDK.

Pakiety SDK są wykonywane w odseparowanym procesie

Proponowane środowisko wykonawcze SDK umożliwia działanie zgodnych pakietów SDK – w dalszej części tego dokumentu nazywanych pakietami SDK używanymi w czasie działania aplikacji – w osobnym procesie aplikacji. Platforma ułatwia dwukierunkową komunikację między procesem aplikacji a jej środowiskiem wykonawczym SDK. Szczegółowe informacje znajdziesz w sekcji dotyczącej komunikacji w tym dokumencie. Pakiety SDK inne niż RE pozostaną w procesie aplikacji tak jak obecnie. Te zmiany ilustrują poniższe diagramy:

---

Nowy zaufany model dystrybucji pakietów SDK

Proponowane oddzielenie pakietu SDK od aplikacji jest powodem wprowadzenia kolejnej koncepcji oddzielenia, tym razem w przypadku dystrybucji pakietu SDK i aplikacji. Wymaga to zaufanego mechanizmu dystrybucji i instalacji, aby zapewnić instalowanie w środowisku wykonawczym pakietu SDK aplikacji odpowiednich pakietów SDK.

Ten mechanizm pomaga chronić użytkowników i deweloperów aplikacji przed wczytywaniem nieprawidłowych pakietów SDK, a sklepom z aplikacjami umożliwia znaczne zmniejszenie obciążenia związanego z dystrybucją pakietów SDK przez deweloperów aplikacji.

Pakiety SDK nie muszą już być statycznie połączone i spakowane razem z aplikacjami przed przesłaniem do sklepu z aplikacjami w celu dystrybucji.

Proces ten obejmuje te kroki:

1. Deweloperzy pakietów SDK przesyłają ich wersje do sklepów z aplikacjami, oddzielnie od samych aplikacji.
2. Deweloperzy aplikacji określają zależności pakietu SDK według wersji i kompilacji oraz przesyłają wersję aplikacji, która nie zawiera rzeczywistych zależności pakietu SDK.
3. Gdy użytkownik pobierze tę aplikację, proces instalacji użyje określonych zależności pakietu SDK aplikacji, a następnie pobierze je ze sklepu z aplikacjami.

Ten nowy mechanizm dystrybucji umożliwia niezależne aktualizacje pakietów SDK pod następującymi warunkami:

• Poprawki błędów wstecznie zgodne, które nie dodają żadnych nowych funkcji, interfejsów API ani zmian w istniejących interfejsach API ani nie wprowadzają zmian w działaniu.
• Zgodne wstecznie ulepszenia funkcji wykrywania lub oceny oszustw.

Wdrożenie tych funkcji zależy od sklepu.

Poniższe diagramy ilustrują proponowane zmiany w dystrybucji pakietu SDK:

---

Zmiany w sposobie tworzenia, uruchamiania i dystrybucji pakietów SDK i aplikacji

To wstępna propozycja elastycznego środowiska wykonawczego pakietu SDK i technologii dystrybucji. W sekcjach poniżej proponujemy szereg zmian w tych kategoriach:

• Dostęp: uprawnienia, pamięć, miejsce na dane
• Wykonywanie: języki, zmiany w czasie działania, cykl życia, renderowanie multimediów
• Komunikacja: między aplikacją a pakietem SDK i między pakietami SDK
• Programowanie: jak tworzyć, debugować i testować w tym modelu
• Dystrybucja: jak rozpowszechniać, aktualizować i przywracać starsze wersje Androida, aplikacji i pakietów SDK

Ten dokument zawiera też najczęstsze pytania, które pomogą Ci znaleźć odpowiedzi na typowe pytania.

To wstępna propozycja projektu. Zdajemy sobie sprawę, że dla niektórych uczestników ekosystemu może to być istotna zmiana. Dlatego aktywnie prosimy o Twoje opinie i zachęcamy do przesyłania ich za pomocą narzędzia do śledzenia problemów.

Dostęp

Zarządzanie prywatnością systemu oznacza zarządzanie tym, jak różne podmioty mogą uzyskiwać dostęp do różnych zasobów. Aby spełnić naszą obietnicę dotyczącą prywatności, proponujemy zaktualizować model dostępu do aplikacji, pakietów SDK i danych użytkowników zgodnie z zasadą jak najmniejszych uprawnień, aby zapobiec nieujawnionemu dostępowi do potencjalnie poufnych danych.

Uprawnienia pakietu SDK

W ramach osobnego procesu środowisko wykonawcze SDK będzie miało własny, dobrze zdefiniowany zestaw uprawnień, zamiast dziedziczyć te, które użytkownik przyznał aplikacji. Na podstawie wstępnych badań uprawnień używanych przez pakiety SDK związane z reklamami proponujemy, aby domyślnie w środowisku wykonawczym SDK pakiety SDK miały dostęp do tych uprawnień:

• INTERNET: dostęp do internetu, aby móc komunikować się z usługą internetową.
• ACCESS_NETWORK_STATE: dostęp do informacji o sieciach.
• READ_BASIC_PHONE_STATE: dostęp do informacji o stanie telefonu, np. typu 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ędzy aplikacjami.
• AD_ID: Możliwość żądania identyfikatora wyświetlania reklam. Będzie to również zależeć od tego, czy aplikacja ma dostęp do tego uprawnienia.

Obecnie sprawdzamy, czy i jak autoryzować dodatkowe uprawnienia, aby ograniczyć wpływ na użytkowników końcowych z perspektywy prywatności i użyteczności. Prosimy o przesłanie opinii na temat przypadków użycia, które nie są objęte tym zestawem uprawnień.

Pamięć

Środowisko wykonawcze pakietu SDK ma własną odizolowaną przestrzeń pamięci, ponieważ działa w osobnym procesie. Taka struktura domyślnie odmawia pakietowi SDK dostępu do przestrzeni pamięci aplikacji, a aplikacja nie ma dostępu do przestrzeni pamięci pakietu SDK. Proponujemy zachowanie tego domyślnego działania, aby zachować zgodność z zasadą jak najmniejszych uprawnień.

Miejsce na dane

Ta propozycja ma na celu zrównoważenie potrzeby dostępu pakietów SDK do pamięci masowej na potrzeby ich normalnego działania oraz zminimalizowanie śledzenia w różnych aplikacjach i procesach za pomocą pamięci trwałej. Proponujemy następującą zmianę sposobu dostępu do miejsca na dane:

• Aplikacja nie będzie mieć bezpośredniego dostępu do pamięci pakietów SDK i odwrotnie.
• Zewnętrzna pamięć urządzenia nie będzie dostępna dla pakietów SDK.
• W każdym środowisku wykonawczym SDK znajdowałoby się miejsce na dane dostępne dla wszystkich pakietów SDK oraz miejsce na dane prywatne dla danego pakietu SDK.

Podobnie jak w przypadku obecnego modelu przechowywania danych, sama pamięć nie będzie miała arbitralnych ograniczeń rozmiaru. Zestawy SDK mogą używać pamięci do buforowania zasobów. Pamięć jest okresowo czyszczona, gdy pakiet SDK nie jest aktywnie używany.

Wykonanie

Aby zapewnić prywatność systemu między aplikacjami, pakietami SDK i użytkownikami, sam kontekst wykonania (formaty kodu, konstrukcje językowe, dostępne interfejsy API i dane systemowe) musi wzmacniać te granice prywatności lub przynajmniej nie stwarzać możliwości ich obejścia. Jednocześnie chcemy zachować dostęp do rozbudowanej platformy i większości funkcji środowiska wykonawczego, które obecnie mają pakiety SDK. Proponujemy zestaw aktualizacji środowiska wykonawczego, które pozwolą osiągnąć tę równowagę.

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 oferowanych przez niego konstrukcji językowych w połączeniu z możliwością weryfikacji w porównaniu z alternatywnymi rozwiązaniami, w szczególności z kodem natywnym, wydaje się odpowiednio równoważyć funkcjonalność i prywatność. 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.

Wiemy, że w niektórych przypadkach, np. w przypadku korzystania z niestandardowego pakietu SQLite, ze względu na użycie kodu natywnego konieczne będzie zastąpienie go alternatywnym rozwiązaniem, takim jak wbudowana w pakiet Android SDK wersja SQLite.

SELinux

W Androidzie każdy proces (w tym procesy działające jako root) jest uruchamiany w określonym kontekście SELinux, co umożliwia jądru zarządzanie kontrolą dostępu do usług systemowych, plików, urządzeń i innych procesów. Aby zachować większość przypadków użycia pakietu SDK, a jednocześnie zminimalizować możliwość obejścia ochrony prywatności, którą staramy się wprowadzić, proponujemy następujące zmiany w kontekście SELinux aplikacji niesystemowej w przypadku środowiska wykonawczego pakietu SDK:

• Dostępny będzie ograniczony zestaw usług systemowych. (w trakcie projektowania)
• Pakiety SDK będą mogły wczytywać i uruchamiać tylko kod w swoim pliku APK.
• Dostępny będzie ograniczony zestaw właściwości systemu. (w trakcie projektowania)

Interfejsy API

Używanie odbicia i wywoływanie interfejsów API w środowisku wykonawczym pakietu SDK jest dozwolone. Pakiet SDK nie będzie jednak mógł używać odbicia ani wywoływać interfejsów API w innym pakiecie SDK z włączonym środowiskiem wykonawczym. Pełną propozycję zabronionych interfejsów API przedstawimy w przyszłej aktualizacji.

Dodatkowo w najnowszych wersjach platformy Androida coraz bardziej ograniczamy dostęp do trwałych identyfikatorów, aby zwiększyć ochronę prywatności. W przypadku środowiska wykonawczego pakietu SDK proponujemy dalsze ograniczenie dostępu do identyfikatorów, które mogą być używane do śledzenia w różnych aplikacjach.

Interfejsy SDK Runtime API są dostępne tylko dla aplikacji działających na pierwszym planie. Próba uzyskania dostępu do interfejsów API SdkSandboxManagerz aplikacjidziałających w tle powoduje zgłoszenie wyjątku SecurityException.

Ponadto pakiety SDK RE nie mogą używać interfejsów API powiadomień do wysyłania powiadomień do użytkowników w dowolnym momencie.

Lifecycle

Pakiety SDK aplikacji są obecnie powiązane z cyklem życia aplikacji hosta. Oznacza to, że gdy aplikacja przechodzi na pierwszy plan lub z niego wychodzi, zamyka się lub jest zamykana 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 wiąże się z następującymi zmianami w cyklu życia:

• Aplikacja może zostać zamknięta przez użytkownika lub system operacyjny. Środowisko wykonawcze SDK zostanie natychmiast automatycznie zamknięte.

• Środowisko wykonawcze pakietu SDK może zostać zakończone przez system operacyjny z powodu zbyt dużego obciążenia pamięci lub nieobsłużonego wyjątku w pakiecie SDK.

  W przypadku Androida 14, gdy aplikacja jest na pierwszym planie, środowisko wykonawcze pakietu SDK działa z wysokim priorytetem i jest mało prawdopodobne, że zostanie zakończone. Gdy aplikacja przechodzi w tło, priorytet procesu środowiska wykonawczego pakietu SDK spada i może on zostać zakończony. Priorytet procesu środowiska wykonawczego pakietu SDK pozostaje niski, nawet jeśli aplikacja wróci na pierwszy plan. W związku z tym jest bardzo prawdopodobne, że w przypadku obciążenia pamięci zostanie ona zamknięta w porównaniu z aplikacją.

  W przypadku Androida 14 i nowszych wersji priorytety procesów aplikacji i środowiska wykonawczego pakietu SDK są zsynchronizowane. Priorytety procesów dla ActivityManager.RunningAppProcessInfo.importance w przypadku aplikacji i środowiska wykonawczego SDK powinny być w przybliżeniu takie same.

  Jeśli środowisko wykonawcze SDK zostanie zakończone, gdy aplikacja jest aktywna (np. w przypadku nieobsłużonego wyjątku w pakiecie SDK), stan środowiska wykonawczego SDK, w tym wszystkie wcześniej załadowane pakiety SDK i widoki zdalne, zostanie utracony. Deweloper aplikacji może poradzić sobie z zakończeniem działania środowiska wykonawczego SDK za pomocą jednej z tych metod:

  • Oferta zawiera powiązane metody wywołania zwrotnego cyklu życia, które deweloperzy aplikacji mogą wykorzystać do wykrywania momentu zakończenia działania środowiska wykonawczego SDK.
  • Jeśli środowisko wykonawcze pakietu SDK zakończy działanie podczas wyświetlania reklam, mogą one nie działać zgodnie z oczekiwaniami. Na przykład wyświetlenia mogą być zamrożone na ekranie i nie będą już interaktywne. Aplikacja może usunąć wyświetlenie reklamy, jeśli nie ma to wpływu na komfort użytkownika.
  • Aplikacja może podjąć kolejną próbę wczytania pakietów SDK i zgłoszenia żądań reklam.
  • W przypadku Androida 14, jeśli środowisko wykonawcze SDK zakończy działanie, gdy są w nim załadowane pakiety SDK, a deweloper aplikacji nie zarejestrował wspomnianych metod wywołania zwrotnego cyklu życia, aplikacja zostanie domyślnie zamknięta. Tylko procesy aplikacji, które załadowały SDK, zostaną zakończone i zamknięte w normalny sposób.
  • Obiekty Binder zwracane przez pakiet SDK do komunikacji z nim (np. SandboxedSdk) zgłaszają wyjątek DeadObjectException, jeśli są używane przez aplikację.

  Ten model cyklu życia może ulec zmianie w przyszłych aktualizacjach.

  W przypadku ciągłych awarii deweloper aplikacji powinien zaplanować płynne wycofywanie się z używania pakietu SDK lub powiadomić użytkownika, jeśli pakiet SDK jest kluczowy dla głównej funkcjonalności aplikacji. Więcej informacji o tej interakcji między aplikacją a pakietem SDK znajdziesz w sekcji dotyczącej komunikacji w tym dokumencie.

Pakiety SDK inne niż RE mogą nadal korzystać ze standardowych elementów systemu operacyjnego dostępnych dla aplikacji osadzonej, w tym usług, aktywności i transmisji, natomiast pakiety SDK RE nie mogą.

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 wykonawcze pakietu SDK może nie działać prawidłowo. Obsługa wspólnych identyfikatorów UID może zostać dodana w przyszłości.
• W przypadku aplikacji z wieloma procesami pakiet SDK należy wczytywać w procesie głównym.

Renderowanie multimediów

Istnieją pakiety SDK, które renderują treści takie jak tekst, obrazy i filmy w widoku określonym przez aplikację. W tym celu proponujemy podejście oparte na renderowaniu zdalnym, w którym pakiet SDK będzie renderować multimedia w środowisku wykonawczym SDK, ale użyje interfejsu SurfaceControlViewHost API, aby umożliwić renderowanie multimediów w widoku określonym przez aplikację. Dzięki temu pakiet SDK może renderować te multimedia w sposób zapewniający prywatność użytkownika, a jednocześnie pomagać w zapobieganiu nieprawidłowym lub nieuczciwym interakcjom użytkownika z renderowanymi multimediami i ich wykrywaniu.

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ć tak samo jak w przypadku reklam innych niż natywne. Jest to obszar, który jest aktywny w ramach badań.

Reklamy wideo typu In-Stream to reklamy wyświetlane w strumieniu wideo 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 poszukujemy mechanizmów, które będą obsługiwać zarówno wstawianie reklam po stronie serwera, jak i wstawianie reklam na podstawie pakietu SDK.

Stan systemu

Staramy się zminimalizować wpływ środowiska wykonawczego pakietu SDK na kondycję systemu na urządzeniach użytkowników i pracujemy nad sposobami, aby to osiągnąć. Najprawdopodobniej jednak niektóre urządzenia z Androidem 14 z bardzo ograniczonymi zasobami systemowymi, takie jak Android (Go edition), nie będą obsługiwać środowiska wykonawczego pakietu SDK ze względu na jego wpływ na kondycję systemu. Wkrótce udostępnimy minimalne wymagania niezbędne do prawidłowego korzystania z SDK Runtime.

Komunikacja

Aplikacje i pakiety SDK działają obecnie w tym samym procesie, więc komunikacja między nimi jest nieograniczona i nie wymaga pośrednictwa. Android umożliwia też komunikację między aplikacjami, nawet jeśli rozpoczyna się i kończy w pakietach SDK. Ten model swobodnej komunikacji umożliwia różne przypadki użycia, a jednocześnie stwarza możliwość nieujawnionego udostępniania danych między aplikacjami oraz między pakietami SDK w aplikacjach i między nimi. Proponujemy wprowadzenie w tym modelu komunikacji następujących zmian, które pozwolą nam zachować równowagę między wartością takiej komunikacji a realizacją naszych celów.

Komunikacja między aplikacją a pakietem 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 znajduje się większość innowacji i funkcji widocznych dla użytkownika. Chcemy zachować możliwość wprowadzania innowacji i wyróżniania się przez pakiety SDK. Dlatego nasza propozycja umożliwia pakietom SDK udostępnianie interfejsów API aplikacjom i zapewnia, że aplikacje mogą korzystać z tych wszystkich innowacji.

Ze względu na strukturę granic procesów środowiska wykonawczego pakietu SDK proponujemy utworzenie warstwy przekazywania, która będzie dostępna w aplikacji i będzie przenosić wywołania interfejsu API oraz odpowiedzi lub wywołania zwrotne przez tę granicę między aplikacją a pakietem SDK. Proponujemy, aby interfejs tej warstwy serializacji był definiowany przez deweloperów pakietów SDK i generowany przez oficjalne narzędzia do kompilacji typu open source, które opracujemy.

Dzięki tej propozycji chcemy zwolnić deweloperów aplikacji i pakietów SDK z powtarzalnej pracy związanej z przekształcaniem danych, a jednocześnie zapewnić deweloperom pakietów SDK elastyczność i zagwarantować, że kod pakietu SDK będzie działać w środowisku wykonawczym pakietu SDK, aby osiągnąć nasze cele związane z ochroną prywatności. Jeśli zdecydujemy się na to rozwiązanie, język definicji interfejsu API i narzędzia będą musiały zostać zaprojektowane z uwzględnieniem Twoich opinii.

Ogólny model interakcji wyglądałby tak:

• Aplikacja wywołuje pakiet SDK za pomocą interfejsu, przekazując wywołania zwrotne.
• SDK asynchronicznie realizuje żądania i odpowiada za pomocą wywołań zwrotnych.
• Można to uogólnić na dowolny model publikowania i subskrypcji, co oznacza, że aplikacja może subskrybować zdarzenia w pakiecie SDK za pomocą wywołań zwrotnych, a gdy te zdarzenia wystąpią, wywołania zwrotne zostaną wywołane.

Konsekwencją nowej struktury międzyprocesowej tej propozycji jest to, że trzeba będzie zarządzać dwoma cyklami życia procesów: jednym dla samej aplikacji, a drugim dla środowiska wykonawczego pakietu SDK. Nasza propozycja ma na celu jak największą automatyzację tego procesu, aby zminimalizować wpływ na deweloperów aplikacji i pakietów SDK. Poniższy diagram przedstawia rozważane przez nas podejście:

Platforma udostępni nowe interfejsy API, które umożliwią aplikacjom dynamiczne wczytywanie pakietów SDK do procesu środowiska wykonawczego SDK, otrzymywanie powiadomień o zmianach stanu procesu i interakcję z pakietami SDK wczytanymi do środowiska wykonawczego SDK.

Wykres na poprzednim rysunku przedstawia komunikację między aplikacją a pakietem SDK na niższym poziomie, bez warstwy przekształcania.

Aplikacja komunikuje się z pakietem SDK działającym w procesie środowiska wykonawczego pakietu SDK, wykonując te czynności:

1. Zanim aplikacja mogła wejść w interakcję z pakietem SDK, musiała poprosić platformę o jego wczytanie. Aby zapewnić integralność systemu, aplikacje będą określać pakiety SDK, które zamierzają załadować, w pliku manifestu. Tylko te pakiety SDK będą mogły być załadowane.

   Poniższy fragment kodu zawiera przykładowy interfejs API:

   SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor,
       OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)
   

2. Pakiet SDK otrzymuje powiadomienie o załadowaniu i zwraca swój interfejs. Ten interfejs jest przeznaczony do użytku przez proces aplikacji. Aby udostępnić interfejs poza granicami procesu, musi on zostać zwrócony jako obiekt IBinder.

   Przewodnik po usługach powiązanych zawiera różne sposoby udostępniania IBinder. Niezależnie od wybranej metody musi ona być spójna w przypadku pakietu SDK i aplikacji wywołującej. Na diagramach jako przykład użyto AIDL.

3. SdkSandboxManager otrzymuje interfejs IBinder i zwraca go do aplikacji.

4. Aplikacja pobiera IBinder i 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:

1. 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 wywołać funkcję requestSurfacePackage() i pobrać odpowiedni element SurfaceControlViewHost.SurfacePackage.

   Poniższy fragment kodu zawiera przykładowy interfejs API:

   SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams,
           Executor executor,
           OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)
   

2. Aplikacja może następnie osadzić zwrócony element SurfacePackage w SurfaceView za pomocą interfejsu setChildSurfacePackage API w SurfaceView.

   Poniższy fragment kodu zawiera przykładowy interfejs API:

   SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
   

Proponujemy, aby interfejsy IBinder i requestSurfacePackage() były ogólne i nie były przeznaczone do bezpośredniego wywoływania przez aplikacje. Zamiast tego te interfejsy API byłyby wywoływane przez wygenerowane odniesienie do interfejsu API omówione powyżej w warstwie „shim”, aby zmniejszyć obciążenie programistów aplikacji.

SDK do SDK

Dwa pakiety SDK w tej samej aplikacji często muszą się komunikować. Może to nastąpić, gdy dany pakiet SDK jest zaprojektowany tak, aby składał się z innych pakietów SDK, lub gdy 2 pakiety SDK od różnych podmiotów muszą współpracować, aby spełnić żądanie aplikacji wywołującej.

Należy wziąć pod uwagę 2 główne przypadki:

• Gdy oba pakiety SDK są używane w czasie działania aplikacji. W tym przypadku oba pakiety SDK działają w środowisku wykonawczym SDK z wszystkimi jego zabezpieczeniami. Pakiety SDK nie mogą się komunikować tak jak w aplikacji. W związku z tym dodaliśmy interfejs API w SdkSandboxController, który umożliwia pobieranie obiektów SandboxedSdk dla wszystkich wczytanych pakietów SDK RE. Umożliwia to pakietowi SDK środowiska wykonawczego komunikowanie się z innymi pakietami SDK załadowanymi w środowisku wykonawczym 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, nie różni się to niczym od wywołania przez samą aplikację drugiego pakietu SDK w środowisku wykonawczym SDK.
  • Jeśli wywołujący pakiet SDK działa w środowisku wykonawczym SDK, ta propozycja zaleca udostępnienie metody za pomocą IBinder opisanej w sekcji dotyczącej komunikacji między aplikacją a pakietem SDK, której kod w aplikacji nasłuchuje, przetwarza i odpowiada za pomocą podanych wywołań zwrotnych.
  • Pakiety SDK do wyświetlania reklam, które nie są włączone w środowisku wykonawczym, mogą nie być w stanie się zarejestrować. Proponujemy utworzenie pakietu SDK pośrednika, który zawiera pakiety SDK partnerów lub aplikacji jako bezpośrednie zależności aplikacji i obsługuje rejestrację. Ten pakiet SDK do mediacji nawiązuje komunikację między pakietami SDK niewywoływanymi w czasie działania aplikacji lub innymi zależnościami aplikacji a pakietem SDK do mediacji wywoływanym w czasie działania aplikacji, 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 przedpremierowej dla programistów)
• Komunikacja między pakietami SDK w aplikacji i środowiskiem wykonawczym SDK (dostępna w najnowszej wersji przedpremierowej dla programistów)
• Jak wyświetlenia i renderowanie zdalne powinny działać w przypadku zapośredniczenia (propozycja w trakcie opracowywania)

Podczas projektowania elementów podstawowych rozważamy te przypadki użycia:

1. Mediacja i określanie stawek Wiele pakietów SDK do reklamowania 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 do przeprowadzenia aukcji (określanie stawek). Zazwyczaj koordynujący pakiet SDK wywołuje inne pakiety SDK za pomocą adaptera dostarczonego przez koordynujący pakiet SDK. Biorąc pod uwagę powyższe elementy podstawowe, koordynujący pakiet SDK, niezależnie od tego, czy jest to pakiet SDK RE, powinien mieć dostęp do wszystkich pakietów SDK RE i innych pakietów SDK w celu normalnego działania. Renderowanie w tym kontekście jest przedmiotem ciągłych badań.
2. Odkrywanie funkcji Niektóre pakiety SDK składają się z mniejszych pakietów, które w procesie wykrywania wzajemnego określają ostateczny zestaw funkcji udostępniany deweloperowi aplikacji. Ma to umożliwić rejestracja i odkrywanie.
3. Modele subskrypcji wydawcy Niektóre pakiety SDK są zaprojektowane tak, aby mieć 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 elementy powinny obsługiwać ten przypadek użycia.

Aplikacja do aplikacji

Komunikacja między aplikacjami to sytuacja, w której co najmniej jeden z 2 procesów komunikujących się jest pakietem SDK z włączonym środowiskiem wykonawczym. Jest to potencjalny wektor nieujawnionego udostępniania danych. W związku z tym środowisko wykonawcze SDK nie może nawiązać bezpośredniego kanału komunikacji z żadną aplikacją inną niż aplikacja klienta ani z pakietami SDK w innym środowisku wykonawczym SDK utworzonym dla innej aplikacji. Jest to realizowane 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 publikować ContentProvider ani wysyłać transmisji.
• Pakiet SDK może uruchamiać aktywność należącą do innej aplikacji, ale z ograniczeniami dotyczącymi tego, co można wysyłać w intencji. Na przykład do tego zamiaru nie można dodawać dodatków ani działań niestandardowych.
• Pakiet SDK może uruchamiać tylko usługi z listy dozwolonych lub się z nimi łączyć.
• 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 cyfrowego użytkownika. Te kontrole dotyczą też dostępu do ContentProvider za pomocą ContentResolver.
• Pakiet SDK ma dostęp tylko do podzbioru chronionych odbiorników transmisji (np. 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. Na przykład pakiet SDK może nie definiować komponentów takich jak <service>, <activity>, <provider> czy <receiver> i może nie deklarować <permission> w pliku manifestu. Tagi, których nie udało się zainstalować, nie są obsługiwane w środowisku wykonawczym SDK. Tagi, które nie powodują niepowodzenia instalacji, ale są ignorowane, mogą być obsługiwane w przyszłych wersjach Androida.

Te kontrole mogą być też przeprowadzane przez narzędzia czasu kompilacji, których pakiet SDK używa do tworzenia pakietu SDK, oraz w momencie przesyłania do sklepu z aplikacjami.

Pomoc dotycząca aktywności

Pakiety SDK w środowisku wykonawczym SDK nie mogą dodawać tagu aktywności do pliku manifestu 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 pakietom SDK.

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ługiwany.

Context

Aby pakiet SDK mógł rozpocząć aktywność, musi zarejestrować instancję typu SdkSandboxActivityHandler, która służy do powiadamiania o utworzeniu aktywności, gdy aplikacja wywołuje SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder), aby rozpocząć aktywność.

Przepływ żądania aktywności przedstawiono na poniższym wykresie.

Programowanie

Kluczową zasadą tej propozycji jest maksymalne ograniczenie wpływu na ekosystem deweloperów. Ta propozycja oferuje deweloperom kompleksowy zestaw narzędzi do tworzenia, kompilowania i debugowania aplikacji i pakietów SDK RE. Aby zapewnić integralność tej propozycji, wprowadziliśmy pewne zmiany w sposobie konfigurowania, tworzenia i kompilowania aplikacji i pakietów SDK RE.

Tworzenie

Android Studio i powiązane narzędzia zostaną zaktualizowane, aby obsługiwać środowisko wykonawcze SDK. Pomoże to deweloperom prawidłowo skonfigurować aplikacje i pakiety SDK z ograniczonym dostępem do danych, a także zapewni aktualizację starszych lub nieobsługiwanych wywołań do nowszych alternatyw w odpowiednich przypadkach. W fazie tworzenia deweloperzy będą musieli wykonać kilka czynności, które proponujemy.

Programiści aplikacji

Aplikacje muszą określać zależności pakietu SDK RE i certyfikatu pakietu SDK w pliku manifestu aplikacji. W naszej propozycji traktujemy to jako źródło informacji od dewelopera aplikacji. Na przykład:

• Nazwa: nazwa pakietu SDK lub biblioteki.
• Wersja główna: kod wersji głównej pakietu SDK.
• Skrót certyfikatu: skrót certyfikatu kompilacji pakietu SDK. W przypadku danej kompilacji proponujemy, aby deweloper pakietu SDK uzyskał i zarejestrował tę wartość 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 RE. Aplikacje statycznie łączące pakiety SDK będą korzystać z obecnych mechanizmów zależności.

Zależy nam na tym, aby zmiany miały jak najmniejszy wpływ na programistów, dlatego ważne jest, aby po określeniu docelowego poziomu interfejsu API obsługującego środowisko wykonawcze pakietu SDK programiści aplikacji musieli mieć tylko jedną kompilację, niezależnie od tego, czy jest ona uruchamiana na urządzeniach obsługujących środowisko wykonawcze pakietu SDK, czy nie.

Deweloperzy pakietów SDK

W naszym proponowanym projekcie deweloperzy pakietów SDK do raportowania o wyjątkach muszą wyraźnie zadeklarować w manifeście nowy element reprezentujący pakiet SDK lub bibliotekę. Dodatkowo należy podać podobny zestaw wartości jak w przypadku zależności oraz wersję pomocniczą:

• Nazwa: nazwa 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 do wyświetlania reklam będą mieli inne pakiety SDK do wyświetlania reklam jako zależności w czasie kompilacji, prawdopodobnie będą musieli zadeklarować je w taki sam sposób, w jaki deweloper aplikacji zadeklarowałby tę samą zależność. Pakiety SDK RE zależne od pakietów SDK innych niż RE będą je łączyć statycznie. Może to powodować problemy, które zostałyby wykryte w czasie kompilacji lub podczas testów, jeśli pakiety SDK inne niż RE wymagają funkcji, których środowisko wykonawcze pakietu SDK nie obsługuje, lub jeśli muszą działać w procesie aplikacji.

Deweloperzy pakietu SDK RE prawdopodobnie będą chcieli nadal obsługiwać urządzenia bez funkcji RE, takie jak urządzenia z Androidem 12 lub starszym oraz, jak wspomniano w sekcji dotyczącej stanu systemu, urządzenia z Androidem 14 z bardzo ograniczonymi zasobami systemowymi. Pracujemy nad rozwiązaniami, które pozwolą deweloperom pakietów SDK zachować jedną bazę kodu do obsługi środowisk RE i innych.

Kompilacje

Programiści aplikacji

Spodziewamy się, że deweloperzy aplikacji nie odczują większych zmian w kroku kompilacji. Zależności pakietu SDK, niezależnie od tego, czy są rozpowszechniane lokalnie, czy w sklepie z aplikacjami (RE czy nie), muszą znajdować się na komputerze, aby można było przeprowadzić linting, kompilację i tworzenie wersji. Proponujemy, aby Android Studio w normalnym użytkowaniu ukrywało te szczegóły przed deweloperem aplikacji i sprawiało, że będą one jak najbardziej przejrzyste.

Oczekujemy, że wersja DEBUG będzie musiała zawierać cały kod i symbole, aby można było ją debugować. Wersje RELEASE mogą opcjonalnie nie zawierać wszystkich pakietów SDK rozpowszechnianych w sklepie z aplikacjami (niezależnie od tego, czy są to pakiety RE).

Jesteśmy na wczesnym etapie projektowania i będziemy udostępniać więcej informacji, gdy tylko będą dostępne.

Deweloperzy pakietów SDK

Pracujemy nad rozwiązaniem, które umożliwi tworzenie wersji pakietu SDK bez ograniczeń i z ograniczeniami w jednym artefakcie do dystrybucji. Dzięki temu deweloperzy aplikacji nie będą musieli obsługiwać osobnych wersji pakietu SDK dla regionów regulowanych i innych.

Podobnie jak w przypadku aplikacji, wszystkie pakiety SDK zależności rozpowszechniane w sklepie z aplikacjami muszą znajdować się na urządzeniu, aby można było przeprowadzić linting, kompilację i tworzenie kompilacji. Oczekujemy, że Android Studio ułatwi to bezproblemowo.

Testowanie

Programiści aplikacji

Zgodnie z naszą propozycją deweloperzy aplikacji będą mogli testować swoje aplikacje na urządzeniach z Androidem 14 w normalny sposób. Po skompilowaniu aplikacji będzie można ją zainstalować na urządzeniu RE lub w emulatorze. Ten proces instalacji zapewni zainstalowanie prawidłowych pakietów SDK w środowisku wykonawczym pakietu SDK na urządzeniu lub emulatorze, niezależnie od tego, czy pakiety SDK zostały pobrane ze zdalnego repozytorium pakietów SDK czy z pamięci podręcznej systemu kompilacji.

Deweloperzy pakietów SDK

Deweloperzy pakietów SDK zwykle używają wewnętrznych aplikacji testowych na urządzeniach i emulatorach, aby testować swoje rozwiązania. Nasza propozycja tego nie zmienia, a weryfikacja w aplikacji będzie przebiegać w taki sam sposób, jak opisano powyżej w przypadku deweloperów aplikacji. W przypadku aplikacji RE i innych aplikacji będzie używany jeden artefakt kompilacji. Deweloperzy pakietów SDK będą mogli przechodzić przez swój kod niezależnie od tego, czy znajduje się on w środowisku wykonawczym pakietu SDK, czy nie. Mogą jednak wystąpić pewne ograniczenia dotyczące zaawansowanych narzędzi do debugowania i profilowania. To jest obszar aktywnych badań.

Dystrybucja

Oddzielenie aplikacji od pakietów SDK umożliwiło dystrybucję pakietów SDK w sklepach z aplikacjami. Jest to funkcja platformy, która nie jest powiązana z żadnym kanałem dystrybucji.

Daje to następujące korzyści:

• Zapewnianie jakości i spójności pakietów SDK.
• Ułatwianie publikowania deweloperom pakietów SDK.
• Przyspieszanie wdrażania krytycznych aktualizacji pakietu SDK w zainstalowanych aplikacjach.

Aby obsługiwać dystrybucję pakietów SDK, kanał dystrybucji musi obsługiwać te funkcje:

• Deweloperzy pakietów SDK mogą publikować swoje pakiety SDK w sklepie lub na platformie i przeprowadzać operacje konserwacyjne.
• Zapewnij integralność pakietów SDK i aplikacji oraz rozwiąż ich zależności.
• wdrażać pakiety SDK na urządzeniach w spójny, niezawodny i wydajny sposób;

Ograniczenia zmieniające się z czasem

Oczekujemy, że ograniczenia dotyczące kodu w środowisku wykonawczym pakietu SDK będą się zmieniać w późniejszych wersjach Androida. Aby zapewnić zgodność aplikacji, nie będziemy zmieniać tych ograniczeń w przypadku aktualizacji modułów głównych dla danego poziomu pakietu SDK. Zachowanie powiązane z danym targetSdkVersion jest zachowywane do momentu wycofania obsługi tego targetSdkVersion zgodnie z zasadami sklepu z aplikacjami. Wycofanie targetSdkVersion może następować szybciej niż w przypadku aplikacji. Ograniczenia mogą się często zmieniać w różnych wersjach pakietu Android SDK, zwłaszcza w pierwszych kilku wersjach.

Dodatkowo tworzymy mechanizm kanaryjny, który umożliwi zewnętrznym i wewnętrznym testerom dołączenie do grupy otrzymującej proponowany zestaw ograniczeń dla następnej wersji Androida. Pomoże nam to uzyskać opinie i pewność co do proponowanych zmian w zestawie ograniczeń.

Najczęstsze pytania

1. Czym jest pakiet SDK związany z reklamami?

   SDK powiązany z reklamami to SDK, który ułatwia dowolną część kierowania komunikatów do użytkowników w celach komercyjnych w aplikacjach, które nie są własnością reklamodawcy. Obejmuje to m.in. pakiety SDK do analiz, w których można tworzyć grupy użytkowników na potrzeby późniejszego kierowania reklam, pakiety SDK do wyświetlania reklam, pakiety SDK do ochrony przed nadużyciami i oszustwami w reklamach, pakiety SDK do zwiększania zaangażowania oraz pakiety SDK do atrybucji.

2. Czy w środowisku wykonawczym SDK może działać dowolny pakiet SDK?

   Początkowo skupimy się na pakietach SDK związanych z reklamami, ale deweloperzy pakietów SDK niezwiązanych z reklamami, którzy chcą zachować prywatność użytkowników i uważają, że mogą działać na opisanych powyżej warunkach, mogą przekazywać opinie o swoich pakietach SDK działających w środowisku wykonawczym SDK. Środowisko wykonawcze pakietu SDK nie jest jednak zgodne ze wszystkimi projektami pakietów SDK. Oprócz udokumentowanych ograniczeń środowisko wykonawcze SDK prawdopodobnie nie nadaje się do pakietów SDK, które wymagają komunikacji w czasie rzeczywistym lub o wysokiej przepustowości z aplikacją hostującą.

3. Dlaczego warto wybrać izolację procesów zamiast izolacji w środowisku wykonawczym opartym na Javie w ramach procesu?

   Obecnie środowisko wykonawcze oparte na Javie nie ułatwia wyznaczania granic bezpieczeństwa niezbędnych do zapewnienia prywatności, na której zależy użytkownikom Androida. Wdrożenie takiego rozwiązania prawdopodobnie wymagałoby wieloletnich wysiłków, bez gwarancji sukcesu. Dlatego Piaskownica prywatności korzysta z granic procesu, czyli sprawdzonej i dobrze znanej technologii.

4. Czy przeniesienie pakietów SDK do procesu środowiska wykonawczego pakietu SDK zapewni mniejszy rozmiar pobierania lub oszczędność miejsca?

   Jeśli kilka aplikacji jest zintegrowanych z pakietami SDK używanymi w czasie działania w tej samej wersji, może to zmniejszyć rozmiar pobierania i zajętość miejsca na dysku.

5. Do jakich zdarzeń związanych z cyklem życia aplikacji, np. gdy aplikacja przechodzi w tryb działania w tle, pakiety SDK będą miały dostęp w środowisku wykonawczym SDK?

   Aktywnie pracujemy nad obsługą powiadomień o zdarzeniach związanych z cyklem życia aplikacji na poziomie aplikacji (np. przejście aplikacji w tło lub na pierwszy plan) w środowisku wykonawczym pakietu SDK. Projekt i przykładowy kod zostaną udostępnione w ramach nadchodzącej wersji przedpremierowej dla programistów.

Polecane dla Ciebie

• Uwaga: tekst linku jest wyświetlany, gdy JavaScript jest wyłączony.
• Przewodnik dla programistów dotyczący środowiska wykonawczego pakietu SDK