Przegląd środowiska wykonawczego SDK

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

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. Deweloperzy aplikacji mogą też nie zdawać sobie w pełni sprawy z zasięgu funkcji 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 pomóc nam w kształtowaniu przyszłych wersji środowiska wykonawczego pakietu SDK, w tym w zakresie obsługi 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 i 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 wykrywać nieprawidłowy ruch i zapobiegać oszustwom reklamowym 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 dokumentu nazywanym pakietem SDK używanym w czasie działania) 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. Wymaga to zaufanej dystrybucji i mechanizmu instalacji, aby zapewnić prawidłowe zainstalowanie pakietów SDK w czasie działania pakietu SDK aplikacji.

Ten mechanizm pomaga 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 rozpowszechnianiem pakietów SDK.

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

Proces obejmuje te kroki: 1. Deweloperzy pakietów SDK przesyłają ich wersje do sklepów z aplikacjami oddzielnie od samych aplikacji. 1. Deweloperzy aplikacji określają zależności pakietu SDK według wersji, kompilacji i wersji aplikacji, a następnie przesyłają wersję aplikacji, która nie zawiera rzeczywistych zależności pakietu SDK. 1. Gdy użytkownik pobiera aplikację, proces instalacji korzysta z określonych zależności pakietu SDK, aby pobrać je ze sklepu z aplikacjami.

Ten nowy mechanizm dystrybucji umożliwia niezależne aktualizacje pakietu SDK pod warunkiem spełnienia tych wymagań:

• wstecznie zgodne poprawki błędów, które nie dodają żadnych nowych funkcji, nowych interfejsów API, zmian w dotychczasowych interfejsach API ani nie wprowadzają zmian w zachowaniu;
• Zgodność wsteczna z ulepszeniami funkcji wykrywania lub oceny oszustw.

Implementacja tych funkcji zależy od sklepu.

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 środowiska wykonawczego pakietu SDK. W następnych sekcjach proponujemy szereg zmian w tych ogólnych kategoriach:

• 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. Zdajemy sobie sprawę, że może to być znacząca zmiana dla niektórych członków ekosystemu. Dlatego aktywnie prosimy o Twoją opinię. Prześlij ją za pomocą problemu w systemie śledzenia błędów.

Dostęp

Zarządzanie prywatnością w systemie oznacza zarządzanie dostępem różnych stron 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ść przesłania żą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 ich normalnego działania oraz zminimalizowanie śledzenia w różnych 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 będzie 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, rozmiar miejsca na dane nie będzie podlegał dowolnym ograniczeniom. 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 języka 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 składał się wyłącznie z kodu bajtowego Dex, a nie obsługiwał dostępu JNI.

Zdajemy sobie sprawę, że w niektórych 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 działające 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 mogłyby 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 ramach środowiska uruchomieniowego pakietu SDK jest dozwolone korzystanie z odzwierciedlenia i wywoływania interfejsów 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ę zabronionych 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ć prywatność. W przypadku pakietu SDK proponujemy dalsze ograniczenie dostępu do identyfikatorów, które mogą być używane do śledzenia między aplikacjami.

Interfejsy SDK Runtime API 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 zakłada te zmiany 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 Androidzie 14, gdy aplikacja jest na pierwszym planie, środowisko uruchomieniowe pakietu SDK działa z wysokim priorytetem i nie jest w większości przypadków zamykane. Gdy aplikacja przejdzie na drugi plan, priorytet procesu środowiska uruchomieniowego pakietu SDK spadnie i można go zakończyć. Priorytet procesu środowiska uruchomieniowego pakietu SDK pozostaje niski nawet wtedy, gdy 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.importance aplikacji 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 środowiska wykonawczego pakietu SDK za pomocą jednej z tych metod:

  • Proponowana metoda oferuje deweloperom aplikacji powiązane metody wywołania cyklu życia, które umożliwiają wykrywanie zakończenia działania środowiska wykonawczego pakietu SDK.
  • Jeśli środowisko uruchomieniowe pakietu 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 przyszłych 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 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 korzystać ze standardowych funkcji 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 taki sam sposób jak w przypadku reklam innych niż natywne. To 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, np. 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. W ramach naszej propozycji chcemy umożliwić pakietom SDK udostępnianie interfejsów API aplikacjom i zapewnić, aby aplikacje mogły korzystać z 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 porządkowania danych był definiowany przez programistów pakietu SDK i generowany przez oficjalne narzędzia kompilacji typu open source, które opracujemy.

Ta propozycja ma na celu odciążenie deweloperów aplikacji i pakietów SDK od tworzenia szablonów kodowania, a zarazem zapewnienie deweloperom pakietów SDK większej elastyczności i zapewnienie, że kod pakietu SDK będzie działał w czasie działania pakietu SDK, co pozwoli nam zrealizować nasze cele związane z prywatnością. Jeśli zdecydujemy się na ten kierunek, język definiowania interfejsu API i narzędzie do jego tworzenia zostaną zaprojektowane 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.
• 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. Gdy wystąpią te zdarzenia, zostaną wywołane wywołania zwrotne.

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. Nasz projekt 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 rozważane przez nas podejście:

Platforma udostępniałaby nowe interfejsy API, które umożliwiłyby aplikacjom wczytywanie pakietów SDK dynamicznie w ramach procesu środowiska uruchomieniowego pakietu SDK, otrzymywanie powiadomień o zmianach stanu tego procesu oraz interakcję z pakietami SDK wczytanymi w ramach ś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 za pomocą tych czynności:

1. 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ć.

   Poniższy fragment kodu przedstawia przykład interfejsu API:

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

2. 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óry sposób wybierzesz, musisz zachować spójność między pakietem SDK a aplikacją wywołującą. Na diagramach jako przykład użyto interfejsu AIDL.

3. SdkSandboxManager odbiera 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 ona wywołać funkcję requestSurfacePackage() i pobrać odpowiednią funkcję SurfaceControlViewHost.SurfacePackage.

   Ten fragment kodu pokazuje przykład użycia interfejsu API:

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

2. Aplikacja może następnie umieścić zwrócone dane SurfacePackage w SurfaceView za pomocą interfejsu API setChildSurfacePackage w SurfaceView.

   Ten fragment kodu pokazuje przykład użycia 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 zestawy SDK w tej samej aplikacji często muszą ze sobą współpracować. Może się to zdarzyć, gdy dany pakiet SDK jest zbudowany z podstawowych pakietów SDK i 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ą używane 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ów SandboxedSdk dla wszystkich załadowanych pakietów SDK RE. Umożliwia to pakietowi RE-SDK 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 jest uruchamiany w aplikacji, działa tak samo jak sama aplikacja wywołująca drugi pakiet SDK w środowisku wykonawczym SDK.
  • Jeśli wywołujący pakiet SDK działa w środowisku wykonawczym pakietu SDK, zalecamy udostępnienie metody za pomocą interfejsu IBinder opisanego w sekcji „Interfejs aplikacji do pakietu SDK”, który kod w aplikacji wysłuchuje, przetwarza i odpowiada za pomocą podanych wywołań zwrotnych.
  • Pakiety SDK do wyświetlania reklam, które nie są włączone w czasie wykonywania, mogą nie być w stanie się zarejestrować. Proponujemy utworzenie pośredniczącego pakietu SDK, który zawiera dowolne pakiety SDK partnera 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 przedpremierowej)
• Komunikacja między pakietami SDK w aplikacji a środowiskiem wykonawczym SDK (dostępna w najnowszej wersji w ramach wersji przedpremierowej dla programistó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:

1. Mediacja i określanie stawek. Wiele pakietów SDK do reklamy oferuje funkcje zapośredniczenia lub określania stawek, w ramach których 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 ten pakiet. Z powodu wymienionych wyżej funkcji podstawowych pakiet SDK koordynujący (czy to RE, czy nie) powinien mieć dostęp do wszystkich pakietów SDK RE i niebędących RE w ramach normalnego działania. W tym kontekście renderowanie jest przedmiotem ciągłych badań.
2. 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.
3. 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ć ContentProvider ani 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 mają zastosowanie również do uzyskiwania dostępu do ContentProvider za 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 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 kontrole mogą być też stosowane przez dowolne narzędzia do tworzenia, 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 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 do ponownego użycia oraz w odpowiednich przypadkach zaktualizować wywołania przestarzałych lub nieobsługiwanych funkcji na nowsze odpowiedniki. W trakcie tworzenia nasza propozycja wymaga od deweloperów wykonania kilku czynności.

Programiści aplikacji

Aplikacje muszą określać zależności od 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 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ą to pakiety RE. Aplikacje łączące pakiety SDK statycznie 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, oraz wersję podrzędną:

• 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 starsze, a także urządzenia z Androidem 14 na poziomie podstawowym z bardzo ograniczonymi zasobami systemowymi (jak wspomniano w sekcji dotyczącej 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 niebędące 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ą być dostępne na komputerze, aby umożliwić sprawdzanie kodu, kompilację i tworzenie wersji. Spodziewamy się, ż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 w zwykły sposób. 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 w 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 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 związana z żadnym konkretnym kanałem dystrybucji.

Dzięki temu:

• Zadbaj o jakość i spójność pakietów SDK.
• uproszczenie publikowania dla deweloperów pakietów SDK;
• przyspieszenie wdrażania krytycznych poprawek pakietu SDK w zainstalowanych aplikacjach;

Aby umożliwić dystrybucję pakietu SDK, kanał dystrybucji musi obsługiwać te funkcje:

• Deweloperzy pakietów SDK mogą publikować swoje pakiety SDK w sklepie lub na platformie oraz wykonywać operacje konserwacyjne.
• Zadbaj o integralność pakietów SDK i aplikacji oraz rozwiązuj problemy z ich zależnościami.
• wdrażać na urządzeniach pakiety SDK 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, dopóki nie zostanie wycofane zgodnie z zasadami sklepu z aplikacjami. Wycofanie targetSdkVersion może nastąpić szybciej niż w przypadku aplikacji.targetSdkVersion 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 kanarka, który pozwoli testerom zewnętrznym i wewnętrznym dołączyć do grupy, która otrzyma proponowany zestaw ograniczeń dla następnej wersji Androida. Pomoże nam to uzyskać opinie i potwierdzić zaproponowane zmiany w zestawie ograniczeń.

Najczęstsze pytania

1. Co to jest pakiet SDK związany z reklamami?

   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, w 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.

2. 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 ich pakiety SDK 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. Pakiet SDK Runtime nie jest jednak zgodny ze wszystkimi wersjami pakietu SDK. Poza udokumentowanymi ograniczeniami środowisko wykonawcze SDK jest prawdopodobnie nieodpowiednie dla pakietów SDK, które wymagają komunikacji z aplikacją hostującą w czasie rzeczywistym lub z dużą przepustowością.

3. 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 prywatności pożądanej przez użytkowników Androida. Wdrożenie takiej funkcji 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ę.

4. Czy przeniesienie pakietów SDK do procesu SDK Runtime 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.

5. 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?

   Pracujemy nad zapewnieniem możliwości powiadamiania środowiska uruchomienia pakietu SDK o zdarzeniach cyklu życia aplikacji klienta na poziomie aplikacji (np. o przechodzeniu aplikacji na pierwszy lub drugi 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 Runtime SDK – przewodnik dla programistów