Przegląd środowiska wykonawczego SDK

Uwaga: ten dokument odzwierciedla działanie Piaskownicy prywatności na urządzeniach z Androidem w obecnej wersji. i może podlegać dalszym zmianom. Zachęcamy do dzielenia się opiniami i komentarzami, które pomogą nam w realizacji tych działań.

Na platformie Android stosowana jest koncepcja piaskownica aplikacji, solidne granice w zakresie wykonywania i zabezpieczeń 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. 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 uruchamianie pakietów SDK innych firm w dedykowanym środowisku wykonawczym o nazwie środowisko wykonawcze 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;

.

Uwaga: w pierwszej wersji środowiska wykonawczego SDK skupiamy się na obsłudze pakiety SDK związane z reklamami, w tym pakiety SDK umożliwiające wyświetlanie reklam, pomiarów skuteczności, wykrywania oszustw reklamowych i nadużyć. Pakiety SDK związane z reklamami są opisane w dalszej części tego dokumentu.

Chcemy uzyskać opinie społeczności reklamodawców aplikacji mobilnych na temat tego projektu. 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

Ta propozycja ma na celu osiągnięcie następujących celów:

• Ogranicz niejawny 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 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.
• 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.
• Pomóż deweloperom aplikacji lepiej uwzględniać zasady dostępu do danych i ich udostępniania do aplikacji.
• Pomagać deweloperom pakietów SDK w zapobieganiu modyfikowaniu ich przez inne pakiety SDK poprzez ograniczanie pewnych niebezpiecznych konstrukcji językowych, takich jak kod JNI.
• Pomaga pakietom SDK do wyświetlania reklam w wykrywaniu nieprawidłowego ruchu i oszustw reklamowych oraz zapobieganiu im poprzez pełną kontrolę nad wyświetlaniem multimediów w widokach zdalnych.
• 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. Szczegółowe informacje znajdziesz w sekcji dotyczącej komunikacji w tym dokumencie. Pakiety SDK inne niż RE pozostają w procesie. Na poniższych diagramach następujące zmiany:

Zanim kod wywołujący pakiet SDK zostanie dodany do środowiska wykonawczego pakietu SDK, kod ten wraz z pakietami SDK, które otrzymują wywołania z tego kodu, znajdują się w procesie aplikacji

.

---

Po dodaniu kodu wywołującego pakiet SDK do środowiska wykonawczego pakietu SDK kod ten w procesie z przodu aplikacji komunikuje się z interfejsami pakietu SDK. Interfejsy te przekraczają granicę procesu i przechodzą do procesu środowiska wykonawczego pakietu SDK, aby wywołać same pakiety SDK.

Nowy zaufany model dystrybucji pakietów SDK

To zaproponowane odłączenie pakietu SDK od aplikacji stanowi motywację do kolejnego podejścia: a druga do pakietu SDK i dystrybucji aplikacji. Nasz projekt wymaga zaufanej dystrybucji i mechanizmu instalacji, aby zapewnić, że prawidłowe pakiety SDK są instalowane w czasie działania pakietu SDK aplikacji. Pomaga to chronić użytkowników i deweloperów aplikacji przed wczytywaniem nieprawidłowych pakietów SDK, a jednocześnie umożliwia sklepom z aplikacjami znaczne zmniejszenie obciążenia deweloperów związanego z dystrybucją pakietów SDK.

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

1. Deweloperzy pakietów SDK mogą przesyłać do sklepów z aplikacjami wersje pakietów SDK oddzielnie od samych aplikacji.
2. Deweloperzy aplikacji mogą określić zależności pakietu SDK według wersji i kompilacji, a następnie przesłać wersję aplikacji, która nie zawiera rzeczywistych zależności pakietu SDK.
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 nie powodując zmian (tj. w interfejsach API ani w ich semantyce) pakiety SDK i rozpowszechnianie ich na urządzeniach bez udziału deweloperów aplikacji; Te nienaruszające zmiany 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.

Proponowane zmiany w rozprowadzaniu pakietu SDK ilustrują diagramy poniżej:

Przed wprowadzeniem środowiska wykonawczego SDK deweloperzy wysyłali pakiety SDK bezpośrednio do aplikacji.

.

---

Po wprowadzeniu środowiska wykonawczego SDK pakiet SDK używają interfejsu przesyłania pakietów SDK do publikowania w sklepie z aplikacjami. Sklep z aplikacjami zajmie się dystrybucją aplikacji i wszelkimi pakietami SDK na urządzeniach użytkowników.

zmiany w sposobie tworzenia, uruchamiania i rozpowszechniania pakietów SDK i aplikacji;

To wstępna propozycja elastycznej technologii dystrybucji i czasu działania pakietu SDK. W 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ż najczęstsze pytania.

To wstępna propozycja projektu, która może być ważną zmianą 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 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: umożliwia dostęp do informacji 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 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. Dostęp do tego uprawnienia byłby również ograniczony przez aplikację.

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. 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. Zalecamy aktualizację dotyczącą miejsca na dane dostęp dzisiaj:

• 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 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 rozmiarowego rozmiaru. Pakiety SDK mogą używać miejsca na dane do buforowania 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 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 zabezpieczenia, 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 wczytywać i wykonywać tylko kod w swoim pliku APK.
• Dostępny byłby ograniczony zestaw właściwości systemu. (w trakcie projektowania)

Interfejsy API

W czasie działania pakietu SDK można używać mechanizmu odbicia i wywoływać interfejsy API. Pakiet SDK nie może jednak używać odbicia lustrzanego ani wywoływać interfejsów API w innym pakiecie SDK z włączoną obsługą czasu wykonywania. Pełną listę zakazanych interfejsów API opublikujemy w przyszłej aktualizacji.

Dodatkowo w ostatnich wersjach platformy 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óba uzyskania dostępu do interfejsów API SdkSandboxManager z aplikacji w tle powoduje wygenerowanie wyjątku 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ą. Nasza propozycja oddzielenia pakietów SDK aplikacji do innego procesu zakłada te zmiany w cyklu życia:

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

• Ś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 13, gdy aplikacja jest na pierwszym planie, środowisko wykonawcze SDK działa z wysokim priorytetem i nie jest zamykane. Gdy aplikacja przechodzi na drugi plan, priorytet procesu środowiska uruchomieniowego pakietu SDK maleje i może zostać zakończony. Priorytet procesu środowiska uruchomieniowego pakietu SDK pozostaje niski, nawet jeśli aplikacja wraca na pierwszy plan. W konsekwencji istnieje duże prawdopodobieństwo, że zostanie ono zamknięte z powodu obciążenia pamięci w porównaniu z aplikacją.

  W Androidzie 14 i nowszych wersjach priorytety procesów aplikacji i czasu wykonywania pakietu SDK są dopasowane. Priorytety 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 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:

  • Propozycja oferuje powiązane metody cyklu życia wywołań zwrotnych 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.
  • 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 aplikacja procesy, które wczytały pakiety SDK, kończą się i wychodzą normalnie.
  • Obiekty Binder 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 używać standardowych elementów systemu operacyjnego dostępnych dla wbudowanej aplikacji, w tym usług, działań i transmisji, podczas gdy pakiety SDK RE nie mogą tego robić.

Przypadki szczególne

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

• Jeśli wiele aplikacji 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 ładowanie pakietu SDK powinno odbywać się w głównym procesie.

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. Proces zbierania sygnałów i pobierania kreacji będzie przebiegał w taki sam sposób 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. 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 13 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 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. Ponadto Android umożliwia komunikację między aplikacjami, nawet jeśli komunikacja rozpoczyna się i kończy w pakietach 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 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.

Łą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. Dzięki temu nasza propozycja umożliwia pakietom SDK udostępnianie interfejsów API aplikacjom i zapewnia, że aplikacje mogą korzystać z wszystkich tych innowacji.

Ze względu na strukturę granicy procesu środowiska wykonawczego SDK zalecamy i tworzy warstwę masową, dostępną w aplikacji, do przenoszenia wywołań interfejsu API odpowiedzi lub wywołań zwrotnych po tej granicy między aplikacją a pakietem SDK. Proponujemy, aby interfejs tej warstwy przekazywania danych był definiowany przez programistów pakietu SDK i generowany przez oficjalne narzędzia do kompilacji typu open source, które opracujemy.

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 zautomatyzowanie jak największej liczby tych procesów, aby zminimalizować wpływ na deweloperów aplikacji i pakietów SDK. Poniższy diagram przedstawia podejście, które rozważamy:

Diagram sekwencji pokazujący interakcje aplikacji z pakietem SDK podczas uruchamiania aplikacji i pakietu SDK.

Platforma udostępniałaby nowe interfejsy API, które umożliwiłyby aplikacjom dynamiczne wczytywanie pakietów SDK do procesu środowiska wykonawczego pakietu SDK, otrzymywanie powiadomień o zmianach stanu tego procesu oraz interakcję z pakietami SDK wczytanymi do środowiska wykonawczego pakietu SDK.

Wykres na poprzednim rysunku pokazuje komunikację aplikacji z pakietem SDK na niższym poziomie bez warstwy porządkowania.

Aplikacja komunikuje się z pakietem SDK działającym w procesie środowiska uruchomieniowego pakietu SDK w następujący sposób:

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

   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.

   W przewodniku po powiązanych usługach znajdziesz różne sposoby udostępniania IBinder. Niezależnie od tego, którą metodę wybierzesz, musisz zachować spójność między pakietem SDK a aplikacją wywołującą. Na diagramach jako przykład użyto interfejsu 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, wykonując te czynności:

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

   Poniższy fragment kodu przedstawia przykład 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.

   Poniższy fragment kodu przedstawia przykład interfejsu 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 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

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 wywołujący pakiet SDK działa w aplikacji, działa to tak samo jak w przypadku wywołania drugiego pakietu SDK przez samą aplikację w środowisku wykonawczym SDK.
  • Jeśli 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ę same. 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 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 między pakietami SDK został podzielony na te 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. Mediacja i określanie stawek. Wiele pakietów SDK do reklamy oferuje funkcję zapośredniczenia lub określania stawek, w ramach której pakiet SDK wywołuje różne inne pakiety SDK w celu wyświetlenia reklamy (zapośredniczenie) lub zebrania sygnałów w celu przeprowadzenia aukcji (określanie stawek). 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. 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 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.

Aplikacja 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. 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 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 kontrole dotyczą również uzyskiwania 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 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 kompilacji używane przez pakiet SDK do tworzenia pakietu SDK oraz w momencie przesyłania do sklepu z aplikacjami.

Wsparcie dla aktywności

Pakiety SDK w środowisku środowiska wykonawczego 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 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.

Uwaga: obiekt Activity przekazywany przez platformę jest typu. android.app.Activity, który jest niezgodny z zasadami na ten temat: androidx elementów appcompat lub Compose.

Uwaga: pakiety SDK Context nie mogą używać podanych tam elementów typu Activity. Pakiet SDK powinien używać SandboxedSdkProvider#getContext() do pobierania prawidłowego Context

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.

Diagram sekwencji pokazujący przepływ inicjowania aktywności.

Programowanie

Kluczową zasadą w tej propozycji jest w jak największym stopniu ograniczenie wpływu na ekosystem deweloperów. 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.

Uwaga: ta sekcja jest na bardzo wczesnym etapie projektowania, więc nie znamy jeszcze wielu szczegółów i wiele może się zmienić. Celem jest podzielenie się z Tobą naszymi planami, które są zgodne z naszą obecną wiedzą, abyśmy mogli uzyskać od Ciebie opinię na wczesnym etapie.

Tworzenie

Android Studio i powiązane narzędzia zostaną zaktualizowane, aby uwzględniały środowisko wykonawcze SDK. Dzięki temu deweloperzy będą mogli prawidłowo skonfigurować aplikacje i pakiety SDK RE oraz w odpowiednich przypadkach zaktualizować przestarzałe lub nieobsługiwane wywołania na nowsze odpowiedniki. 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 pakietu SDK lub biblioteki.
• Wersja główna: kod wersji głównej pakietu SDK.
• Podsumowanie certyfikatu: podsumowanie certyfikatu kompilacji pakietu SDK. W przypadku danej kompilacji zalecamy deweloperowi pakietu SDK uzyskanie i zarejestrowanie tej wartości w odpowiednim sklepie z aplikacjami.

Dotyczy to tylko pakietów SDK rozpowszechnianych w sklepach z aplikacjami, niezależnie od tego, czy są one zgodne z zasadami. Aplikacje, które statycznie łączą pakiety SDK, używają bieżących 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 naszym proponowanym projekcie deweloperzy pakietu SDK RE muszą wyraźnie zadeklarować w pliku manifestu nowy element reprezentujący pakiet SDK lub encję biblioteki. Dodatkowo należy podać podobny zestaw wartości, jak w przypadku zależności, oraz wersję podrzędną:

• 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 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, które zostaną wykryte w momencie kompilacji lub podczas testów, jeśli pakiety SDK innych niż RE wymagają funkcji, których środowisko wykonawcze SDK nie obsługuje, lub jeśli muszą działać w ramach procesu aplikacji.

Deweloperzy RE SDK prawdopodobnie będą nadal obsługiwać urządzenia bez RE, takie jak Android 12 lub starszy oraz, jak wspomniano w sekcji dotyczącej stanu systemu w tym dokumencie, podstawowe urządzenia z Androidem 13 z bardzo ograniczonymi zasobami systemowymi. 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

Przewidujemy, że deweloperzy aplikacji zauważą niewielkie zmiany i etap 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.

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. Dzięki temu deweloperzy aplikacji nie będą musieli obsługiwać osobnych wersji pakietu SDK dla wersji z reklamą i bez reklamy.

Podobnie jak w przypadku aplikacji, wszystkie pakiety SDK z zależnościami rozpowszechniane w sklepach z aplikacjami muszą znajdować się na komputerze, aby umożliwić sprawdzanie kodu, kompilację i tworzenie wersji. Oczekujemy, że Android Studio będzie to robić bezproblemowo.

Testowanie

Programiści aplikacji

Zgodnie z naszą propozycją deweloperzy aplikacji mogliby 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 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, choć mogą wystąpić pewne ograniczenia w przypadku zaawansowanych narzędzi debugowania i profilowania. To praktyczny obszar badań.

Dystrybucja

Nasza propozycja dotycząca rozdzielenia aplikacji od pakietów SDK umożliwiła dystrybucję pakietów SDK w sklepach z aplikacjami. Jest to ogólna możliwość, która nie jest charakterystyczna dla żadnego konkretnego sklepu z aplikacjami. Korzyści są jasne:

• Zadbać o jakość i spójność pakietów SDK.
• uproszczenie publikowania dla deweloperów pakietów SDK;
• przyspieszenie wdrażania aktualizacji wersji pomocniczych pakietu SDK w zainstalowanych aplikacjach;

Aby 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 ich wdrażania na urządzenia w sposób niezawodny i wydajny;

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 ograniczeń w ramach aktualizacji głównego modułu dla danego poziomu pakietu 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. 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.

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. Co to jest pakiet SDK do obsługi reklam?

   Pakiet SDK związany z reklamami to taki, który umożliwia kierowanie na użytkowników z wiadomościami o charakterze komercyjnym w aplikacjach, które nie należą do reklamodawcy. Obejmuje to m.in. pakiety SDK 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 jest jednak zgodne 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 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 używa granic procesów – sprawdzonych i dobrze zrozumiałych 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. Do jakich zdarzeń z cyklu życia aplikacji, np. do zdarzeń związanych z przejściem aplikacji w tło, będą mieć dostęp pakiety SDK w środowisku wykonawczym SDK?

   Aktywnie pracujemy nad zapewnieniem możliwości powiadamiania pakietu SDK o zdarzeniach cyklu życia aplikacji klienta na poziomie aplikacji (np. o przechodzeniu aplikacji na drugi plan i powrocie na pierwszy plan). Projekt i przykładowy kod zostaną udostępnione w wersji przedpremierowej.