Przegląd środowiska wykonawczego SDK

Prześlij opinię

Na platformie Android stosowana jest koncepcja piaskownica aplikacji, solidne granice w zakresie wykonywania i zabezpieczeń kodu aplikacji oraz granice procesów. Powszechną praktyką w aplikacjach jest dodanie kodu innych firm, w postaci pakietów SDK takich jak pakiety SDK do wyświetlania reklam lub pakiety SDK Analytics. Takie ponowne wykorzystanie umożliwia pozwalają deweloperom skupić się na wyróżnianiu aplikacji, a jednocześnie wykorzystać ekspertów w danej dziedzinie, aby zwiększyć zakres swojej realizacji. .

Podobnie jak w większości systemów operacyjnych pakiety Android SDK są wykonywane w kodzie aplikacji hosta i dziedziczą te same uprawnienia i uprawnienia co aplikacja hosta oraz dostęp do pamięci i pamięci aplikacji hosta. Choć ta architektura umożliwia elastyczną integrację pakietów SDK i aplikacji, nieujawnionego zbierania i udostępniania danych użytkowników. Deweloperzy aplikacji nie mogą też mieć pełną świadomość zakresu funkcji pakietu SDK innej firmy oraz danych, dostęp, co utrudnia uwzględnienie zbierania danych i praktyki z zakresu udostępniania aplikacji.

W Androidzie 13 dodaliśmy nową funkcję platformy, która umożliwia pakiety SDK do uruchamiania w specjalnym środowisku wykonawczym nazywanym środowiskiem wykonawczym SDK. Środowisko wykonawcze SDK zapewnia poniższe silniejsze zabezpieczenia i gwarancje dotyczące zbieranie i udostępnianie danych użytkownika:

• Zmodyfikowane środowisko wykonawcze
• Dobrze zdefiniowane uprawnienia i prawa dostępu do danych dla pakietów SDK

.

Aktywnie zależy nam na opinii społeczności reklamującej aplikacje mobilne na temat w tym projekcie. Chętnie też poznamy opinie szerszej społeczności programistów, pomagają w kształtowaniu przyszłych iteracji środowiska wykonawczego SDK, w tym obsługi i dodatkowych zastosowań.

Cele

Celem tej propozycji jest osiągnięcie następujących celów:

• Ograniczanie nieujawnionego dostępu do danych aplikacji użytkownika i udostępniania ich innym firmom Pakiety SDK dzięki izolacji procesów i dobrze zdefiniowanej kontroli dostępu do interfejsów API oraz danych. Więcej informacji o izolacji procesów znajdziesz w osobnej sekcji poruszone w tym dokumencie.
• Ogranicz nieujawnione śledzenie korzystania z aplikacji przez użytkownika przez zewnętrzne pakiety SDK: a pakiety SDK nie mają dostępu do unikalnych, trwałych identyfikatorów.
• bezpiecznie przyspieszyć rozpowszechnianie aktualizacji pakietu SDK w aplikacjach przez zmniejszenie na programistów i użytkowników. Więcej informacji o proponowanych model dystrybucji zaufanego pakietu SDK w innej sekcji poruszone w tym dokumencie.
• Pomóż deweloperom aplikacji lepiej uwzględniać zasady dostępu do danych i ich udostępniania do aplikacji.
• Pomóż deweloperom w zapobieganiu modyfikacjom innych pakietów SDK przez ograniczenie pewnych niebezpiecznych konstrukcji językowych, takich jak kod JNI.
• Pomóż pakietom SDK do wyświetlania reklam w pełnym zakresie – wykrywanie nieprawidłowego ruchu i oszustw reklamowych sterować zdalnymi widokami multimediów.
• Postaraj się ograniczyć negatywny wpływ tego problemu na deweloperów aplikacji i pakietów SDK.

Pakiety SDK są uruchamiane w osobnym procesie

Proponowane środowisko wykonawcze SDK umożliwia korzystanie ze zgodnych pakietów SDK – omówionych w reszty tego dokumentu znajdziesz jako pakiety SDK z obsługą środowiska wykonawczego, które pozwalają dla każdej aplikacji. Platforma umożliwia dwukierunkowe komunikacji między procesem aplikacji a jej środowiskiem wykonawczym SDK. Zobacz sekcji dotyczącej komunikacji w tym dokumencie. Pakiety SDK inne niż RE pozostają w procesie. Na poniższych diagramach następujące zmiany:

---

Nowy zaufany model dystrybucji pakietów SDK

To zaproponowane oddzielenie pakietu SDK od aplikacji stanowi motywację do kolejnego podejścia: a druga do pakietu SDK i dystrybucji aplikacji. Nasza propozycja wymaga wiarygodnej dystrybucji i instalacji, aby zapewnić instalację właściwych pakietów SDK środowiska wykonawczego SDK aplikacji. Pomaga to chronić użytkowników i deweloperów aplikacji przed nieprawidłowymi wczytywane pakiety SDK, które pozwalają sklepom z aplikacjami znacznie zmniejszyć obciążenie dystrybucji pakietów SDK przez deweloperów aplikacji.

Pakiety SDK nie będą już musiały być statyczne i pakowane razem z ich aplikacje przed przesłaniem do sklepu z aplikacjami w celu dystrybucji. Poniżej zachodziłby zamiast tego:

1. Deweloperzy aplikacji mogą przesyłać pakiety SDK w różnych wersjach do sklepów z aplikacjami, oddzielnie z aplikacji.
2. Deweloperzy aplikacji mogą określić zależności pakietu SDK przez wersję, kompilację i przesłaną wersję aplikacji, która nie zawiera pakietu SDK; zależności.
3. Gdy użytkownik pobierze tę aplikację, w procesie instalacji może zostać użyty określonych zależności SDK w aplikacji, a potem pobrać je ze sklepu z aplikacjami.

Ten nowatorski mechanizm dystrybucji pozwoliłby deweloperom pakietów SDK nierozstrzygające zmian (tj. w interfejsach API ani w ich semantyce) w ich pakiety SDK i rozpowszechnianie ich na urządzeniach bez udziału deweloperów aplikacji; Te nienaruszające zmian w pakiecie SDK można wdrożyć lub wycofać bez musi poczekać, aż deweloperzy utworzą je ponownie nowe pakiety SDK lub poczekać, aż użytkownicy zaktualizują swoje aplikacje. Zmiany powodujące niezgodność wymagają aktualizacji przez deweloperów aplikacji, ale deweloperzy pakietów SDK mogą zmian i poprawek, które są szybsze i bardziej jednolite więcej osób, co pozwoli zminimalizować obsługę wersji.

Na diagramach poniżej widać proponowane zmiany w dystrybucji pakietu SDK:

.

---

Zmiany w sposobie tworzenia, uruchamiania i rozpowszechniania pakietów SDK oraz aplikacji

To jest wstępna propozycja elastycznego środowiska wykonawczego i dystrybucji pakietu SDK technologii. W poniższych sekcjach znajdziesz serię zmian następujące ogólne kategorie:

• Dostęp: uprawnienia, pamięć, miejsce na dane.
• Wykonanie: języki, zmiany czasu działania cykl życia, renderowanie multimediów
• Komunikacja: aplikacje typu App-to-SDK i SDK-to-SDK.
• Programowanie: jak kompilować, debugować i testować tego modelu
• Dystrybucja – informacje o tym, jak rozprowadzać, aktualizować wycofywanie zmian na różnych wersjach Androida, aplikacji i pakietów SDK;

Dokument zawiera też odpowiedzi na najczęstsze pytania.

To wstępna propozycja projektu. Zdajemy sobie sprawę, że może to być dla niektórych członków ekosystemu. Dlatego aktywnie nagabujemy i poproś o przesłanie opinii na stronie .

Dostęp

Zarządzanie prywatnością w systemie oznacza zarządzanie sposobem, w jaki różne podmioty dostęp do różnych zasobów. Aby dostosować się do naszej propozycji wartości dotyczącej prywatności, zaktualizowanie modelu dostępu do aplikacji, pakietów SDK i danych użytkownika, zasada jak najmniejszych uprawnień zapobiegająca nieujawnionemu dostępowi potencjalnie danych wrażliwych.

Uprawnienia pakietu SDK

Jako osobny proces środowisko wykonawcze SDK będzie miało własny, dobrze zdefiniowany zestaw uprawnienia, a nie dziedziczenie tych, które użytkownik przyznał aplikacji. Na podstawie wstępnych badań nad uprawnieniami wykorzystywanymi przez pakiety SDK dotyczące reklam. zaproponowanie, że te uprawnienia będą dostępne dla pakietów SDK w pakiecie SDK Domyślnie:

• INTERNET: dostęp do internetu umożliwiający komunikowanie się z usługą internetową.
• ACCESS_NETWORK_STATE: umożliwia dostęp do informacji o sieciach.
• READ_BASIC_PHONE_STATE: umożliwia dostęp do informacji o stanie telefonu, na przykład typu sieci komórkowej.
• Uprawnienia dostępu do interfejsów API chroniących prywatność, które zapewniają podstawowe możliwości wyświetlania reklam bez konieczności dostępu do identyfikatorów różnych aplikacji.
• AD_ID: Możliwość wysyłania próśb o identyfikator wyświetlania reklam. Ta grupa również będzie blokowana przez dostęp do tego uprawnienia.

Obecnie analizujemy, czy i w jaki sposób można upoważnić dodatkowe uprawnień, ograniczając wpływ prywatności i ochrony prywatności na użytkowników z perspektywy łatwości obsługi. Śr poproś o opinię w przypadkach użycia, które mogą nie być spełnione przez ten zestaw uprawnień.

Pamięć

Środowisko wykonawcze SDK będzie miało własne, wyodrębnione miejsce w pamięci dzięki własnemu procesowi. Ta struktura domyślnie będzie odrzucać SDK ma dostęp do pamięci aplikacji, przez co aplikacja nie byłaby w stanie mieć dostęp do pamięci pakietu SDK. Zalecamy zachowanie tej wartości domyślnej. działania zgodne z zasadą jak najmniejszych uprawnień.

Miejsce na dane

Ta oferta ma na celu zrównoważenie potrzeb, jakie pakiety SDK muszą mieć dostęp do pamięci masowej normalne działanie aplikacji oraz śledzenie między aplikacjami i procesami za pomocą pamięci trwałej. Zalecamy aktualizację dotyczącą miejsca na dane dostęp dzisiaj:

• Aplikacja nie będzie mieć bezpośredniego dostępu do miejsca na dane jej pakietów SDK (i odwrotnie).
• Pamięć zewnętrzna urządzenia nie będzie dostępna dla pakietów SDK.
• W ramach każdego środowiska wykonawczego SDK każdy pakiet SDK ma dostęp do pamięci masowej, i prywatną pamięć dla danego pakietu SDK.

Tak jak obecny model miejsca na dane, samo miejsce na dane nie ma żadnych dowolnych limitów i rozmiaru. Pakiety SDK mogą używać miejsca na dane do buforowania zasobów. To miejsce na dane jest dostępne okresowo jest usuwana, gdy pakiet SDK nie jest aktywny.

Wykonanie

Aby zapewnić prywatność w systemie między aplikacjami, pakietami SDK i użytkownikami, kontekst wykonania (formaty kodu, konstrukcje językowe, dostępne interfejsy API i dane systemowe) musi wzmocnić te granice prywatności, a przynajmniej nie wprowadzać możliwości ich obejścia. Jednocześnie chcemy zachować dostęp z rozbudowaną platformą i większością funkcji środowiska wykonawczego, z których pakiety SDK korzystają które obecnie posiadasz. Proponujemy tu zestaw aktualizacji środowiska wykonawczego, i znaleźć równowagę.

Kod

Kod na Androida (aplikacje i pakiety SDK) jest interpretowany głównie przez środowisko wykonawcze Androida (ART), niezależnie od tego, czy kod został napisany w Kotlin, czy w Javie. Bogactwo reklamy ART i konstrukcji języka, a także możliwości weryfikacji. w porównaniu z alternatywnymi rozwiązaniami, w szczególności kodem natywnym, zrównoważyć funkcjonalność i prywatność. Zalecamy, aby w czasie działania aplikacji zawierać wyłącznie kod bajtowy Dex, a nie obsługiwać dostęp JNI.

Zdajemy sobie sprawę, że istnieją przypadki użycia, takie jak stosowanie pakietów niestandardowo SQLite, który wymaga użycia kodu natywnego, trzeba zastąpić kodem np. dzięki wbudowanej w pakiecie Android SDK wersji SQLite.

SELinux

Na Androidzie każdy proces (także ten uruchomiony jako root) jest uruchamiany kontekst SELinux umożliwiający jądrze zarządzanie kontrolą dostępu do systemu. usług, plików, urządzeń i innych procesów. W trosce o utrzymanie w większości przypadków użycia SDK, minimalizując jednocześnie obejście prywatności zabezpieczeń, które próbujemy kontynuować, proponujemy następujące aktualizacje z kontekstu SELinux aplikacji innej niż systemowa dla środowiska wykonawczego SDK:

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

Interfejsy API

Dozwolone jest używanie interfejsów API odbicia i wywoływania w środowisku wykonawczym pakietu SDK. Pakiet SDK nie będzie jednak mógł używać refleksu ani wywoływać interfejsów API w innym pakietu SDK używanego w czasie działania aplikacji. Pełną propozycję zabronionych interfejsów API przedstawimy w przyszła aktualizacja.

Dodatkowo w ostatnich wersjach platformy Android coraz bardziej dostęp do trwałych identyfikatorów w celu poprawy ochrony prywatności. W przypadku pakietu SDK W środowisku wykonawczym proponujemy dodatkowe ograniczenie dostępu do identyfikatorów, których można używać do śledzenia w różnych aplikacjach.

Interfejsy API środowiska wykonawczego pakietu SDK są dostępne tylko w aplikacjach działających na pierwszym planie. Próbuję uzyskać dostęp do interfejsów API SdkSandboxManager z aplikacji w tle powoduje Rzucony SecurityException.

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

Lifecycle

Pakiety SDK są obecnie zgodne z cyklem życia aplikacji hostującej, co oznacza, że wchodzi na pierwszy plan, opuszcza go, wyłącza się lub zostaje wymuszone jego zatrzymanie przez z powodu braku pamięci, pakiety SDK aplikacji również to robią. Nasze propozycja podziału pakietów SDK aplikacji w inny proces oznacza, następujące zmiany w cyklu życia:

• Aplikację może zakończyć się użytkownik lub system operacyjny. Środowisko wykonawcze SDK zostanie automatycznie zakończona natychmiast po.

• Środowisko wykonawcze SDK może zostać zakończone przez system operacyjny ze względu na pamięć lub nieobsługiwany wyjątek w pakiecie SDK.

  W przypadku Androida 13, gdy aplikacja działa na pierwszym planie, środowisko wykonawcze SDK działa w o wysokim priorytecie i prawdopodobnie nie zostanie zamknięta. Gdy aplikacja przejdzie do priorytet procesu środowiska wykonawczego SDK zostanie zmniejszony i nie kwalifikuje się do rozwiązania umowy. Priorytet procesu środowiska wykonawczego SDK pozostaje bez zmian niski poziom nawet wtedy, gdy aplikacja wróci na pierwszy plan. W związku z tym bardzo prawdopodobnie zostanie zatrzymany pod wpływem zwiększonej ilości pamięci .

  W przypadku Androida 14 i nowszych priorytety procesów aplikacji i pakietu SDK Środowisko wykonawcze jest wyrównane. Priorytety procesów dotyczące ActivityManager.RunningAppProcessInfo.importance w przypadku aplikacji oraz Środowisko wykonawcze SDK powinno być mniej więcej takie samo.

  Jeśli środowisko wykonawcze SDK zostanie zamknięte w czasie, gdy aplikacja jest aktywna – jeśli na przykład w pakiecie SDK występuje nieobsługiwany wyjątek – środowisko wykonawcze SDK , w tym wszystkie wcześniej wczytane pakiety SDK i widoki zdalne, zostaną utracone. deweloper aplikacji może poradzić sobie z zatrzymaniem środowiska wykonawczego SDK za pomocą następujące metody:

  • Oferta pakietowa zawiera powiązane metody wywołania zwrotnego cyklu życia dla deweloperów aplikacji w celu wykrycia zamknięcia środowiska wykonawczego SDK.
  • Jeśli środowisko wykonawcze SDK zakończy się w czasie wyświetlania reklam, reklamy mogą nie być działać zgodnie z oczekiwaniami. np. wyświetlenia mogą zostać zablokowane na ekranie i utracone i dłuższą interaktywność. Aplikacja może usunąć wyświetlenie reklamy, jeśli nie wpłynie to na użytkowników.
  • Aplikacja może ponowić próbę wczytania pakietów SDK i żądania reklam.
  • Jeśli w przypadku Androida 14 środowisko wykonawcze SDK zakończy działanie po załadowaniu pakietów SDK, a deweloper aplikacji nie zarejestrował tego cyklu. metody wywołania zwrotnego, aplikacja zostanie domyślnie zamknięta. Tylko aplikacja procesy, które wczytały pakiety SDK, kończą się i wychodzą normalnie.
  • obiekty powiązań zwracane przez pakiet SDK w celu komunikowania się z nim (np. SandboxedSdk) powoduje zgłoszenie DeadObjectException, jeśli jest używane przez aplikację.

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

  W przypadku trwałych usterek deweloper aplikacji powinien zaplanować łagodnej pogorszenia bez pakietu SDK lub powiadomić użytkownika, jeśli pakiet SDK jest kluczowe znaczenie dla głównej funkcjonalności aplikacji. Więcej informacji na ten temat interakcji między aplikacją a pakietem SDK znajdziesz w sekcji dotyczącej komunikacji na ten dokument.

Pakiety SDK inne niż RE mogą nadal używać standardowych podstawowych elementów systemu operacyjnego dostępnych umieszczone aplikacje – w tym usługi, działania i transmisje – natomiast pakiety SDK RE nie może.

Przypadki szczególne

Te przypadki nie są obsługiwane i mogą powodować nieoczekiwane działanie:

• Jeśli wiele aplikacji korzysta z tego samego identyfikatora UID, środowisko wykonawcze SDK może nie działać bez obaw. W przyszłości możemy dodać obsługę współdzielonych identyfikatorów UID.
• W przypadku aplikacji z wieloma procesami pakiet SDK należy wczytać w głównym proces tworzenia konta.

Renderowanie multimediów

Istnieją pakiety SDK, które renderują treści, takie jak tekst, obrazy i filmy, w widok określony przez aplikację. Aby to osiągnąć, proponujemy podejście zdalnego renderowania. gdzie SDK renderuje multimedia ze środowiska wykonawczego SDK, ale korzysta z metody Interfejs API SurfaceControlViewHost umożliwia wyrenderowanie multimediów w widoku określonym przez aplikację. Dzięki temu pakiet SDK wyświetlanie multimediów w sposób zapewniający prywatność użytkownika; a jednocześnie pomaga zapobiegać nieprawidłowym lub nieuczciwym interakcjom z renderowanych treści multimedialnych.

Reklamy natywne, czyli te, które nie są renderowane przez pakiet SDK, ale przez aplikację, będą muszą być obsługiwane przez pakiety SDK w środowisku wykonawczym SDK. Zbieranie sygnałów i tworzenie kreacji pobieranie danych będzie przebiegało tak samo jak w przypadku reklam innych niż natywne. To jest jest obecnie praktycznym obszarem badań.

Reklamy wideo In-Stream to reklamy In-Stream wraz z filmem wyświetlanym w odtwarzaczu. w obrębie aplikacji. Biorąc pod uwagę, że film odtwarza się w odtwarzaczu w aplikacji, a nie niż odtwarzacz lub widok w pakiecie SDK, model renderowania różni się od formatów reklam. Cały czas szukamy mechanizmów obsługi zarówno reklam po stronie serwera, za pomocą funkcji wstawiania reklam i wstawiania reklam za pomocą pakietu SDK.

Stan systemu

Staramy się zminimalizować wpływ środowiska wykonawczego SDK na użytkowników urządzeń i opracowujemy sposoby na to. Najprawdopodobniej jednak niektóre podstawowe Urządzenia z Androidem 13 z bardzo ograniczonymi zasobami systemowymi, takimi jak Android (wersja Go), nie będzie obsługiwać środowiska wykonawczego SDK ze względu na wpływ na stan systemu. Wkrótce muszą spełniać minimalne wymagania niezbędne do korzystania ze środowiska wykonawczego SDK.

Komunikacja

Aplikacje i pakiety SDK działają obecnie w ramach tego samego procesu, dlatego komunikacja między są swobodne i bezpośrednie. Android umożliwia również nawet wtedy, gdy komunikacja zaczyna się i kończy przy użyciu pakietów SDK. Ten Swobodny model komunikacji umożliwia różne przypadki użycia, a jednocześnie Wprowadzając możliwość nieujawnionego udostępniania danych między aplikacjami między pakietami SDK w aplikacjach i między nimi. Proponujemy następujące zmiany tego modelu komunikacji, której celem jest znalezienie równowagi między wartością takiego modelu komunikacji oraz realizacji wyznaczonych celów.

Łączenie aplikacji z pakietem SDK

Najpopularniejszą ścieżką komunikacji jest interfejs między aplikacją a pakietem SDK lub SDK. Z kolei interfejs API pakietu SDK i innowacyjnością. Zależy nam na tym, aby pakiety SDK były bezpieczne innowacyjności i innowacyjności te różnice. W związku z tym nasza propozycja umożliwia pakietom SDK udostępnianie interfejsów API aplikacji i umożliwiają wykorzystanie tych wszystkich innowacji.

Ze względu na strukturę granicy procesu środowiska wykonawczego SDK zalecamy i tworzy warstwę masową, dostępną w aplikacji, do przekazywania wywołań interfejsu API odpowiedzi lub wywołań zwrotnych po tej granicy między aplikacją a pakietem SDK. Jesteśmy zakładając, że interfejs tej warstwy zostanie zdefiniowany przez SDK i generowane przez oficjalne narzędzia open source, i tworzenia aplikacji.

Propozycja ta ma na celu usunięcie powtarzalnych ustaleń z programu i deweloperów pakietów SDK, a jednocześnie zapewniamy ich elastyczność i zapewnienie że kod SDK jest uruchamiany w środowisku wykonawczym SDK, aby realizować nasze cele w zakresie prywatności. Czy powinniśmy to narzędzie, język definicji interfejsu API które zaprojektowaliśmy na podstawie Twojej opinii.

Ogólny model interakcji będzie wyglądał tak:

• Aplikacja wywołuje pakiet SDK przez interfejs, przekazując wywołania zwrotne.
• Pakiet SDK asynchronicznie obsługuje żądania i odpowiada za pomocą wywołań zwrotnych.
• Można to uogólnić do dowolnego modelu subskrypcji wydawcy, co oznacza, że aplikacja może subskrybuj zdarzenia w pakiecie SDK z wywołaniami zwrotnymi. wywołania zwrotne.

Konsekwencją nowej struktury międzyprocesowej tego propozycji jest to, że To 2 cykle życia procesów, którymi należy zarządzać: jeden dla aplikacji, dla środowiska wykonawczego SDK, a drugiej do środowiska wykonawczego. Nasza propozycja ma na celu automatyzację jak najwięcej tych działań, minimalizując wpływ tych zmian na deweloperów aplikacji i pakietów SDK. Poniższy diagram przedstawia podejście, które rozważamy:

Platforma udostępni nowe interfejsy API dla aplikacji, aby dynamicznie ładować pakiety SDK proces środowiska wykonawczego SDK; otrzymuj powiadomienia o zmianach stanu procesu; i interakcji z pakietami SDK wczytanymi do środowiska wykonawczego SDK.

Wykres na poprzedniej ilustracji przedstawia komunikację między aplikacją a pakietem SDK na niższym poziomie, bez warstwy marslingu.

Aplikacja komunikuje się z pakietem SDK działającym w procesie środowiska wykonawczego SDK za pomocą następujące kroki:

1. Zanim aplikacja będzie mogła wchodzić w interakcję z pakietem SDK, wysyła żądanie, i wczytuje pakiet SDK przez platformę. Aby zapewnić integralność systemu, aplikacje muszą określać pakiety SDK, które zamierzają załadować w pliku manifestu. Są to pakiety SDK, można wczytać tylko te, które można wczytać.

   Następujący fragment kodu przedstawia 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 interfejs. Ten interfejs jest przeznaczony do użycia w procesie aplikacji. Udostępnianie interfejsu poza granicą procesu, musi być zwracany jako obiekt IBinder.

   W przewodniku po powiązanych usługach znajdziesz różne sposoby udostępniania IBinder. Niezależnie od wybranej opcji należy zadbać o spójność danych między pakietem SDK a kontem do aplikacji rozmówcy. Jako przykład na diagramach wykorzystano AIDL.

3. Interfejs SdkSandboxManager odbiera interfejs IBinder i zwraca go do aplikację.

4. Aplikacja pobiera IBinder i przesyła ją do interfejsu SDK, wywołując funkcje:

   IBinder binder = sandboxSdk.getInterface();
   ISdkInterface mySdkInterface = ISdkInterface.Stub.asInterface(binder);
   mySdkInterface.something();
   

Aplikacja może też renderować multimedia z pakietu SDK w ten sposób:

1. Jak wyjaśniliśmy w sekcji o renderowaniu multimediów w tym Google (dokumentu), aby aplikacja mogła uzyskać pakiet SDK do renderowania multimediów w widoku, aplikacja może nawiązać połączenie z requestSurfacePackage() i pobrać odpowiednie SurfaceControlViewHost.SurfacePackage

   Następujący fragment kodu przedstawia przykładowy interfejs API:

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

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

   Następujący fragment kodu przedstawia przykładowy interfejs API:

   SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
   

Zalecamy, aby interfejsy API IBinder i requestSurfacePackage() były ogólny i nie powinien być bezpośrednio wywoływany przez aplikacje. Zamiast tego te interfejsy API została wywołana przez wygenerowany opis interfejsu API omówiony powyżej w „podkładce” i zmniejsza obciążenie deweloperów aplikacji.

Łączenie pakietów SDK z pakietami SDK

Często muszą się ze sobą komunikować 2 pakiety SDK w tej samej aplikacji. Może się tak zdarzyć, gdy określony Pakiet SDK został zaprojektowany tak, aby składał się z gotowych pakietów SDK i może wystąpić, gdy 2 z nich Pakiety SDK różnych firm muszą współpracować, aby odpowiedzieć na żądanie aplikację do rozmów.

Należy wziąć pod uwagę 2 kluczowe przypadki:

• Gdy oba pakiety SDK są włączone w czasie działania W tym przypadku oba pakiety SDK działają środowisko wykonawcze SDK ze wszystkimi jego zabezpieczeniami. Pakiety SDK nie mogą komunikować się jako co dzisiaj w aplikacjach. W związku z tym interfejs API Aplikacja SdkSandboxController została dodana, by umożliwić pobieranie SandboxedSdk obiektów dla wszystkich wczytanych pakietów SDK do ponownego ładowania. Dzięki temu RE-SDK komunikować się z innymi pakietami SDK wczytanymi w środowisku wykonawczym SDK.
• Gdy tylko 1 pakiet SDK obsługuje środowisko wykonawcze.
  • Jeśli pakiet SDK wywołujący działa w aplikacji, działa to tak samo jak aplikacja wywołuje drugi pakiet SDK w środowisku wykonawczym SDK.
  • Jeśli pakiet SDK wywołujący działa w środowisku wykonawczym SDK, ta oferta pakietowa zaleca ujawnienie metody za pomocą IBinder opisanego w sekcji App-to-SDK której kod w aplikacji nasłuchuje, przetwarza i odpowiada dostarczone wywołania zwrotne.
  • Pakiety SDK do wyświetlania reklam, które nie są włączone w czasie działania, mogą nie być w stanie zarejestrować się samodzielnie. proponujemy utworzenie pakietu SDK mediatora, który będzie zawierał partnerów lub aplikację, Pakiety SDK jako bezpośrednie zależności aplikacji i obsługują rejestrację. Ten Mediator SDK nawiązuje komunikację między niewłączonym środowiskiem wykonawczym Pakiety SDK lub inne zależności aplikacji oraz środowisko wykonawcze włączyły mediację działającą jako przejściówkę.

Zestaw funkcji do komunikacji SDK i SDK został podzielony na: kategorie:

• komunikacja SDK-SDK w środowisku wykonawczym SDK (dostępna w najnowszej wersji przedpremierowa wersja dla programistów).
• Komunikacja między pakietami SDK i aplikacją ze środowiskiem wykonawczym SDK (dostępna w najnowsza wersja przedpremierowa dla programistów)
• Jak widoki i renderowanie zdalne powinny działać w przypadku zapośredniczenia (propozycja w programowania)

Poniższe przypadki użycia są uwzględniane, ponieważ elementy podstawowe zaprojektowany:

1. Zapośredniczenie i określanie stawek. Wiele pakietów SDK do wyświetlania reklam umożliwia zapośredniczenie lub określanie stawek. Funkcja, w ramach której pakiet SDK wywołuje różne inne pakiety SDK w celu wyświetlenia reklamy (zapośredniczenie) lub zbieranie sygnałów na potrzeby przeprowadzania aukcji (określanie stawek). Zwykle koordynujący pakiet SDK wywołuje inne pakiety SDK za pomocą adaptera dostarczonego przez do koordynowania SDK. Biorąc pod uwagę powyższe elementy podstawowe, koordynujący pakiet SDK, RE lub nie, w celu normalnego działania powinien mieć dostęp do wszystkich pakietów SDK dla deweloperów zajmujących się przetwarzaniem i innych niż RE. Renderowanie w tym kontekście jest obecnie aktywnym obszarem badań.
2. Odkrywanie funkcji. Niektóre usługi SDK składają się z mniejszych pakietów SDK, poprzez wykrywanie treści wewnątrz pakietu SDK, ustalając ostateczny zestaw funkcji, która jest udostępniana deweloperowi aplikacji. Podstawowe elementy rejestracji i wykrywania które umożliwią ten przypadek użycia.
3. Modele subskrypcji wydawcy. Niektóre pakiety SDK są zaprojektowane tak, aby mieć wydawca zdarzeń, które mogą subskrybować inne pakiety SDK lub aplikacje powiadomienia za pomocą wywołań zwrotnych. Powyższe elementy podstawowe powinny obsługiwać to użycie tych kwestii.

Z aplikacji do aplikacji

Komunikacja między aplikacjami to proces, w którym co najmniej 1 z 2 procesów jest dostępny w środowisku wykonawczym i może być potencjalnym wektorem nieujawnionego udostępniania danych. Dlatego środowisko wykonawcze SDK nie może ustanowić kanał bezpośredniej komunikacji z dowolną aplikacją inną niż aplikacja kliencka lub z pakietami SDK w innym środowisku wykonawczym SDK utworzonym dla innej aplikacji. To jest następujące sposoby:

• Pakiet SDK nie może zdefiniować komponentów takich jak <service>, <contentprovider> lub <activity> w pliku manifestu.
• Pakiet SDK nie może opublikować elementu ContentProvider ani wysyłać transmisji.
• Pakiet SDK może uruchomić aktywność należącą do innej aplikacji, ale z ograniczeniami co może być przesyłane w intencji. Na przykład żadne dodatki ani działania niestandardowe nie mogą które można dodać do tej intencji.
• Pakiet SDK może tylko uruchamiać usługi z listy dozwolonych lub tworzyć z nią powiązania.
• Pakiet SDK ma dostęp tylko do podzbioru systemu ContentProvider (np. com.android.providers.settings.SettingsProvider), jeśli uzyskano dane nie mają identyfikatorów i nie można ich użyć do utworzenia odcisku cyfrowego użytkownika. Te weryfikacje dotyczą również dostępu do ContentProvider za pomocą ContentResolver
• Pakiet SDK ma dostęp tylko do podzbioru chronionych odbiorników (np. jako android.intent.action.AIRPLANE_MODE).

Tagi pliku manifestu

Po zainstalowaniu pakietu SDK PackageManager analizuje jego plik manifestu, co kończy się niepowodzeniem aby zainstalować pakiet SDK, jeśli istnieją zabronione tagi manifestu. Pakiet SDK może na przykład nie zdefiniuj komponentów, takich jak <service>, <activity>, <provider> lub <receiver> i nie może zadeklarować <permission> w pliku manifestu. Tagi z błędami jego instalacja nie jest obsługiwana w środowisku wykonawczym SDK. Tagi, które nie ulegają awarii aplikacji, ale są dyskretnie ignorowane, mogą być obsługiwane w przyszłości na Androidzie wersji.

Te kontrole mogą też być stosowane przez wszystkie narzędzia w czasie kompilacji, których pakiet SDK używa do podczas tworzenia pakietu SDK, jak i w chwili przesyłania go do sklepu z aplikacjami.

Wsparcie dla aktywności

Pakiety SDK w środowisku wykonawczym SDK nie mogą dodać tagu aktywności do pliku manifestu i nie mogą uruchamiać własnych działań za pomocą usługi Context.startActivity. Zamiast tego platforma tworzy aktywności dla pakietów SDK na żądanie udostępnia je pakietom SDK.

Aktywność na platformie jest typu android.app.Activity. Aktywność na platformie rozpoczyna się od jednej z aktywności w aplikacji i stanowi część zadania w aplikacji; FLAG_ACTIVITY_NEW_TASK nie jest obsługiwany.

Aby pakiet SDK mógł rozpocząć aktywność, powinien zarejestrować wystąpienie typu SdkSandboxActivityHandler, który jest używany do powiadamiania o utworzeniu aktywności, gdy: aplikacja wywołuje aplikację SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder), aby rozpocząć aktywność.

Przebieg wysyłania żądań działania widać na wykresie poniżej.

Programowanie

Kluczową zasadą tej propozycji jest zminimalizowanie wpływu na deweloperów ekosystem, w którym jest to możliwe. Ta oferta obejmuje dla programistów wszechstronnego zestawu narzędzi do pisania, tworzenia i debugowania RE aplikacje i pakiety SDK. Aby zapewnić integralność tej oferty, kilka zmian w sposobie konfiguracji, tworzenia i budowania aplikacji RE i pakietów SDK.

Tworzenie

Android Studio i powiązane narzędzia zostaną zaktualizowane tak, aby uwzględniać środowisko wykonawcze SDK w celu zadbania o poprawną konfigurację aplikacji RE oraz pakiety SDK oraz aktualizowanie starszych i nieobsługiwanych wywołań do nowszych wersji. w stosownych przypadkach. Na etapie tworzenia treści wymagałby od programistów.

Programiści aplikacji

Aplikacje muszą określić swój pakiet SDK RE i certyfikat 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. Dla danego użytkownika zalecamy uzyskanie i zarejestrowanie tej wartości przez programistę pakietu SDK za pomocą w danym sklepie z aplikacjami.

Dotyczy to tylko pakietów SDK rozpowszechnianych w sklepach z aplikacjami, niezależnie od tego, czy jest to pakiet RE, czy nie. Aplikacje, które statycznie łączą pakiety SDK, używają bieżących mechanizmów zależności.

Mając na uwadze minimalny wpływ na deweloperów, ważne jest, aby określono docelowy poziom interfejsu API obsługujący środowisko wykonawcze SDK; tylko deweloperzy aplikacji nie zawsze muszą mieć jedną kompilację, niezależnie od tego, czy działają one na urządzeniach, nie obsługują środowiska wykonawczego SDK.

Deweloperzy pakietów SDK

W naszym proponowanym projekcie deweloperzy pakietu SDK RE muszą wyraźnie zadeklarować w pliku manifestu nowy element reprezentujący pakiet SDK lub encję biblioteki. Dodatkowo powinien mieć podobny zbiór wartości, którego wymaga zależność podana oraz wersja podrzędna:

• Nazwa: nazwa pakietu SDK lub biblioteki.
• Wersja główna: kod wersji głównej pakietu SDK.
• Wersja podrzędna: kod wersji podrzędnej pakietu SDK.

Jeśli deweloperzy pakietu SDK RE mają w ramach zależności czasu kompilacji inne pakiety SDK RE, muszą prawdopodobnie będzie musiał je zadeklarować w taki sam sposób jak deweloper aplikacji zadeklaruje tę samą zależność. Pakiety SDK typu RE w zależności od pakietów SDK innych niż RE będą statycznie je łączyć. Może to spowodować problemy wykrywane na lub w trakcie testów, jeśli pakiety SDK inne niż RE wymagają funkcji Środowisko wykonawcze SDK nie obsługuje lub musi działać w procesie aplikacji.

Deweloperzy pakietu SDK RE prawdopodobnie będą chcieli nadal obsługiwać aplikacje, które nie mają włączonego ponownie takich jak Android 12 i starsze oraz wymienione w artykule Stan systemu urządzenia z Androidem 13 i standardowymi urządzeniami z Androidem ograniczonych zasobów systemowych. Pracujemy nad sposobami zapewnienia zgodności z zasadami pakietu SDK programiści mogą zachować 1 bazę kodu na potrzeby środowisk RE i innych niż RE.

Kompilacje

Programiści aplikacji

Przewidujemy, że deweloperzy aplikacji zauważą niewielkie zmiany i etap kompilacji. Zależności pakietów SDK (rozpowszechnianych lokalnie lub w aplikacji) rozpowszechniane w sklepach stacjonarnych (RE lub nie), muszą być dostępne na maszynie do lintowania. kompilację danych i kompilacje. Android Studio może wyodrębniać podane przez dewelopera aplikacji przy normalnym użytkowaniu i oznaczaj te informacje jako przezroczyste jak to tylko możliwe.

Spodziewamy się, że kompilacja DEBUG będzie musiała zawierać cały kod i symbole aby była obecna w kompilacji DEBUG w celu umożliwienia debugowania, kompilacje Release opcjonalnie usuń wszystkie pakiety SDK rozpowszechniane w sklepach z aplikacjami (RE lub nie) z efekt końcowy.

Jesteśmy na wczesnym etapie projektowania, więc będziemy udostępniać więcej informacji w miarę jego pojawiania się.

Deweloperzy pakietów SDK

Pracujemy nad tym, aby zapewnić, że wersje bez RE i RE pakietu SDK można zintegrować w pojedynczym artefaktie do dystrybucji. To spowoduje uniknieć konieczności obsługi przez deweloperów aplikacji osobnych kompilacji dla RE i inne niż RE.

Podobnie jak w przypadku aplikacji, każdy pakiet SDK zależności rozpowszechnianych w sklepie z aplikacjami musi na potrzeby lintowania, kompilacji i kompilacji. Spodziewamy się, Studio powinno to ułatwiać.

Testowanie

Programiści aplikacji

Zgodnie z naszą propozycją deweloperzy aplikacji mogliby przetestować na urządzeniach z Androidem 13. Gdy zbudują będzie można ją zainstalować na urządzeniu RE lub w emulatorze. Ten proces instalacji daje pewność, że odpowiednie pakiety SDK zostaną zainstalowane środowisko wykonawcze SDK dla urządzenia lub emulatora, niezależnie od tego, czy pakiety SDK zostały pobrane z zdalnego repozytorium pakietu SDK lub pamięci podręcznej z systemu kompilacji.

Deweloperzy pakietów SDK

Deweloperzy zwykle używają wewnętrznych aplikacji testowych na urządzeniach za pomocą emulatorów do testowania. Nasza propozycja tego nie zmienia i Weryfikacja w aplikacji będzie przebiegać tak samo jak w przypadku deweloperów aplikacji z 1 artefaktem kompilacji zarówno dla aplikacji dla deweloperów, jak i innych aplikacji. Pakiet SDK deweloperzy będą mogli przejść przez cały kod niezależnie od tego, czy znajduje się on w pakiecie SDK środowiska wykonawczego czy nie, chociaż mogą obowiązywać pewne ograniczenia dotyczące zaawansowanego debugowania i profilowania. To praktyczny obszar badań.

Dystrybucja

Nasza propozycja oddzielenia aplikacji od pakietów SDK tworzy dystrybucji pakietów SDK w sklepach z aplikacjami. Jest to ogólna możliwość, nie są unikalne dla żadnego sklepu z aplikacjami. Korzyści są jasne:

• Zadbać o jakość i spójność pakietów SDK.
• Usprawniona publikacja dla deweloperów pakietów SDK.
• Przyspiesz wdrażanie podrzędnych wersji pakietu SDK w zainstalowanych aplikacjach.

Aby możliwa była dystrybucja pakietu SDK, sklep z aplikacjami musi: te funkcje:

• Mechanizm, który umożliwia deweloperom przesyłanie pakietów SDK dostępnych w sklepie z aplikacjami do sklepu, zaktualizować je, wycofać lub w razie potrzeby usunąć.
• mechanizm zapewniający integralność pakietu SDK i jego pochodzenia oraz aplikacji; i jego pochodzenie i rozwiązywać ich zależności.
• Mechanizm wdrażania ich na urządzeniach w spójny i niezawodny wydajniejszy sposób.

Zmieniające się ograniczenia w czasie

Spodziewamy się, że ograniczenia związane z kodem w czasie działania pakietu SDK będą ewoluować w późniejszym czasie wersji Androida. Aby zapewnić zgodność aplikacji, nie zmienimy tych z aktualizacjami modułów mainline dla danego poziomu SDK. Sposób działania powiązana z danym targetSdkVersion jest zachowywana do momentu obsługi tego parametru pakiet targetSdkVersion został wycofany za pomocą zasad dotyczących sklepu z aplikacjami; Wycofanie aplikacji targetSdkVersion może odbywać się szybciej niż w przypadku aplikacji. Ograniczenia mogą się często zmieniać w poszczególnych wersjach pakietu Android SDK, zwłaszcza w kilku pierwszych wersjach.

Tworzymy też mechanizm do wczesnych testów, który umożliwia testerzy muszą dołączyć do grupy, która otrzyma proponowany zestaw ograniczeń wersji Androida. Dzięki temu będziemy mogli poznać Twoją opinię na temat proponowane zmiany w zestawie ograniczeń.

Najczęstsze pytania

1. Czym jest pakiet SDK do celów reklamowych?

   Pakiet SDK związany z reklamami to taki, który ułatwia kierowanie z wiadomościami w celach komercyjnych w aplikacjach, które nie należą do reklamodawcy. Obejmuje to m.in. pakiety SDK Analytics, w przypadku których użytkownicy można tworzyć grupy na potrzeby późniejszego kierowania, pakietów SDK do wyświetlania reklam, przeciwdziałania nadużyciom aby zapobiegać oszustwom w przypadku reklam, pakietów SDK do interakcji i pakietów SDK atrybucji.

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

   Chociaż początkowo firma Google skupia się na pakietach SDK związanych z reklamami, pakiety SDK niezwiązane z reklamami, postaw na postawę ochrony prywatności i wierzą, że mogą działać opisane powyżej warunki mogą przekazać opinię o swoich pakietach SDK który działa w środowisku wykonawczym SDK. Środowisko wykonawcze SDK nie zostało zaprojektowane jako zgodne wszystkich wersji SDK. Oprócz udokumentowanych ograniczeń pakiet SDK Środowisko wykonawcze prawdopodobnie nie jest odpowiednie w przypadku pakietów SDK wymagających wysokiej przepustowości w czasie rzeczywistym z aplikacją hostującą.

3. Dlaczego warto wybrać izolację procesów zamiast izolacji w ramach procesu Środowisko wykonawcze oparte na Javie?

   Obecnie środowisko wykonawcze oparte na Javie nie zapewnia łatwego granice niezbędne w celu zapewnienia ochrony prywatności wymaganych w przypadku Androida. użytkowników. Próba implementacji takiego rozwiązania prawdopodobnie wymagałaby wieloletnich wysiłków, ale bez gwarancji sukcesu. W związku z tym Piaskownica wykorzystuje granice procesów – przetestowany w czasie i dobrze zrozumiały technologii.

4. Czy przeniesienie pakietów SDK do procesu środowiska wykonawczego SDK zapewni rozmiar pobieranego pliku? czy oszczędność miejsca?

   Zintegrowanie wielu aplikacji z takimi samymi pakietami SDK dostępnymi w czasie działania aplikacji to może zmniejszyć rozmiar pobieranych plików i miejsce na dysku.

5. Jakie zdarzenia cyklu życia aplikacji, np. przejście aplikacji do Czy pakiety SDK będą miały dostęp w środowisku wykonawczym SDK?

   Jesteśmy aktywne prace nad obsługą projektowania w zakresie powiadamiania o czasie działania pakietu SDK na poziomie aplikacji; zdarzenia cyklu życia aplikacji klienckiej (np. uruchomienie aplikacji w tle, aplikacji działających na pierwszym planie). Projekt i przykładowy kod zostaną udostępnione w wersji przedpremierowej.

.

Polecane dla Ciebie

• Uwaga: tekst linku wyświetla się, gdy JavaScript jest wyłączony
• Przewodnik dla programistów środowiska wykonawczego SDK

.