Przegląd środowiska wykonawczego SDK

Przesłać opinię

W przypadku platformy Android stosowana jest koncepcja piaskownicy aplikacji, która pozwala zachować niezawodne granice wykonywania i zabezpieczeń kodu aplikacji oraz procesów. Często w aplikacjach wykorzystywany jest kod innej firmy, często w postaci pakietów SDK (np. pakietów SDK do wyświetlania reklam lub pakietów SDK Analytics). Ponowne wykorzystanie pozwala im skupić się na wyróżnieniu ich aplikacji, jednocześnie wykorzystując pracę ekspertów z danej dziedziny, aby zwiększać ich realizację ponad to, co mogliby zrobić samodzielnie.

Podobnie jak w przypadku większości systemów operacyjnych pakiety SDK na Androida są uruchamiane w piaskownicy hosta aplikacji i dziedziczą te same uprawnienia co aplikacja hosta oraz dostęp do pamięci i pamięci aplikacji hosta. Chociaż ta architektura umożliwia elastyczną integrację pakietów SDK i aplikacji, stwarza też ryzyko nieujawnionego zbierania i udostępniania danych użytkowników. Poza tym deweloperzy aplikacji mogą nie być w pełni świadomi zakresu funkcji tego pakietu SDK i danych, do których uzyskuje on dostęp, co utrudnia uwzględnienie sposobów gromadzenia i udostępniania danych przez aplikacje.

W Androidzie 13 dodaliśmy nową funkcję platformy, która umożliwia działanie pakietów SDK innych firm w specjalnym środowisku wykonawczym nazywanym środowiskiem wykonawczym SDK. Środowisko wykonawcze SDK zapewnia następujące mocniejsze zabezpieczenia i gwarancje dotyczące gromadzenia i udostępniania danych użytkowników:

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

Czekamy na opinie społeczności reklamujących aplikacje mobilne na temat tego projektu. Chętnie poznamy też opinie szerszej społeczności deweloperów, które pomogą nam w kształtowaniu kolejnych iteracji środowiska wykonawczego SDK. Obejmuje to m.in. obsługę dodatkowych przypadków użycia.

Cele

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

• Ogranicz nieujawniony dostęp do danych aplikacji użytkownika i ich udostępnianie przez zewnętrzne pakiety SDK dzięki izolacji procesów oraz dobrze zdefiniowanemu interfejsowi API i kontroli dostępu do danych. Więcej informacji o izolacji procesów znajdziesz w osobnej sekcji tego dokumentu.
• ograniczyć nieujawnione śledzenie korzystania przez użytkowników z aplikacji przez zewnętrzne pakiety SDK przez ograniczenie dostępu za pomocą pakietów SDK unikalnych, trwałych identyfikatorów;
• Bezpiecznie przyspieszaj rozpowszechnianie aktualizacji pakietów SDK w aplikacjach, zmniejszając obciążenie deweloperów aplikacji i użytkowników. Więcej informacji o proponowanym modelu dystrybucji zaufanego pakietu SDK znajdziesz w innej sekcji tego dokumentu.
• pomagać deweloperom aplikacji w lepszym uwzględnianiu zasad dostępu do danych i ich udostępniania.
• Pomóż deweloperom pakietów SDK zapobiegać manipulacjom przez inne pakiety SDK przez ograniczenie niektórych niebezpiecznych konstrukcji językowych, takich jak kod JNI.
• Pomóż pakietom SDK do wyświetlania reklam wykrywać nieprawidłowy ruch i oszustwa reklamowe oraz im zapobiegać dzięki pełnej kontroli nad zdalnymi widokami, w których wyświetlają się multimedia.
• Postaraj się zminimalizować wpływ tych działań na deweloperów aplikacji i pakietów SDK.

Pakiety SDK działają w izolowanym procesie

Proponowane środowisko wykonawcze SDK umożliwia zgodnym pakietom SDK (nazywanym w dalszej części tego dokumentu pakietami SDK działające w czasie działania) działanie w osobnym procesie dla aplikacji. Platforma umożliwia dwukierunkową komunikację między procesem aplikacji a środowiskiem wykonawczym SDK. Szczegółowe informacje znajdziesz w sekcji dotyczącej komunikacji w tym dokumencie. Inne niż RE SDK występują w procesie aplikacji tak jak do tej pory. Zmiany te ilustrują te diagramy:

---

Nowy zaufany model dystrybucji pakietów SDK

Takie oddzielenie SDK od aplikacji zachęca do dalszej koncepcji separacji: SDK i dystrybucji aplikacji. Nasza oferta wymaga zaufanego mechanizmu dystrybucji i instalacji, aby zapewnić zainstalowanie odpowiednich pakietów SDK w środowisku wykonawczym SDK aplikacji. Pomaga to chronić użytkowników i deweloperów przed ładowaniem nieprawidłowych pakietów SDK, a jednocześnie umożliwia sklepom z aplikacjami znaczne zmniejszenie obciążenia deweloperów aplikacji.

Pakiety SDK nie muszą już być statycznie połączone i pakowane ze swoimi aplikacjami przed przesłaniem ich do sklepu z aplikacjami w celu dystrybucji. Zamiast tego przebiegałby taki proces:

1. Deweloperzy używający pakietów SDK mogą przesyłać do sklepów z aplikacjami pakiety SDK w różnych wersjach niezależnie od samych aplikacji.
2. Deweloperzy aplikacji mogą określać zależności dotyczące pakietów SDK według wersji, kompilacji i przesłania wersji, która nie zawiera rzeczywistych zależności SDK.
3. Gdy użytkownik pobierze tę aplikację, proces instalacji może użyć określonych w niej zależności pakietu SDK, a potem pobrać je ze sklepu z aplikacjami.

Ten nowatorski mechanizm dystrybucji pozwoliłby deweloperom SDK wprowadzać nienaruszające zmiany (czyli bez zmian w interfejsach API i ich semantyce) oraz rozpowszechniać je na urządzenia bez udziału deweloperów. Te nienaruszające zmiany w pakietach SDK można wdrożyć lub wycofać bez konieczności czekania, aż deweloperzy ponownie skompilują aplikacje, używając nowych pakietów SDK, lub konieczności aktualizacji aplikacji przez użytkowników. Zmiany powodujące niezgodność nadal musiałyby być aktualizowane przez deweloperów aplikacji, ale deweloperzy używający pakietów SDK mogliby otrzymywać najnowsze nienaruszające zmiany i poprawki szybciej i bardziej spójnie u większej liczby osób, co pozwoliłoby ograniczyć obsługę wersji do minimum.

Na tych diagramach widać proponowane zmiany w dystrybucji pakietów SDK:

---

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

To wstępna oferta elastycznego środowiska wykonawczego i technologii dystrybucji pakietu SDK. W sekcjach poniżej przedstawiamy serię zmian dotyczących następujących ogólnych kategorii:

• Dostęp: uprawnienia, pamięć, miejsce na dane.
• Realizacja: języki, zmiany w czasie działania, cykl życia, renderowanie multimediów
• Komunikacja: App-to-SDK i SDK-to-SDK.
• Programowanie: jak kompilować, debugować i testować w tym modelu.
• Dystrybucja: jak rozpowszechniać, aktualizować i wycofywać różne wersje Androida, aplikacji i pakietów SDK.

W tym dokumencie znajdziesz też odpowiedzi na najczęstsze pytania.

To wstępna propozycja projektu i zdajemy sobie sprawę, że może to być istotna zmiana dla niektórych członków ekosystemu. Dlatego prosimy o Twoją opinię i przesyłamy ją za pomocą narzędzia do śledzenia problemów.

Dostęp

Zarządzanie prywatnością w systemie wymaga zarządzania sposobem, w jaki różne podmioty mogą korzystać z różnych zasobów. Aby spełnić naszą propozycję wartości związanych z prywatnością, zalecamy zaktualizowanie modelu dostępu do aplikacji, pakietów SDK i danych użytkowników, tak aby przestrzegał zasady jak najmniejszych uprawnień, co pozwala zapobiegać nieujawnionemu dostępowi do potencjalnie wrażliwych danych.

Uprawnienia pakietu SDK

Jako osobny proces środowisko wykonawcze SDK będzie mieć własny, ściśle zdefiniowany zestaw uprawnień, zamiast je dziedziczyć. Na podstawie wstępnych badań nad uprawnieniami używanymi przez pakiety SDK związane z reklamami sugerujemy, aby domyślnie miały one dostęp do tych uprawnień:

• INTERNET: dostęp do internetu, który umożliwia komunikowanie się z usługą internetową.
• ACCESS_NETWORK_STATE: dostęp do informacji o sieciach.
• Dostęp do interfejsów API chroniących prywatność, które zapewniają podstawowe funkcje reklamowe bez konieczności dostępu do identyfikatorów w różnych aplikacjach.
• AD_ID: możesz poprosić o identyfikator wyświetlania reklam. Dotyczy to również dostępu aplikacji do tych uprawnień.
• BIND_GET_INSTALL_REFERRER_SERVICE: możliwość używania interfejsu Google Play Update Referrer API do przypisywania źródła instalacji aplikacji.

Obecnie badamy, czy i jak autoryzować dodatkowe uprawnienia, ograniczając wpływ tej zmiany na użytkowników z perspektywy prywatności i użyteczności. Prosimy o opinię na temat przypadków użycia, których ten zestaw uprawnień może nie spełniać.

Pamięć

Dzięki własnemu procesowi środowisko wykonawcze SDK ma własną, wyizolowaną przestrzeń pamięci. Ta struktura domyślnie uniemożliwi pakietowi SDK dostęp do miejsca w pamięci aplikacji, a aplikacja również nie będzie mogła z niego korzystać. Zalecamy zachowanie tego domyślnego działania z myślą o zachowaniu jak najmniejszych uprawnień.

Miejsce na dane

Celem tej oferty jest zrównoważenie potrzeby dostępu pakietów SDK do pamięci masowej podczas normalnego działania oraz zminimalizowanie śledzenia w różnych aplikacjach i procesach przy użyciu pamięci trwałej. Planujemy obecnie wprowadzenie tych zmian w sposobie uzyskiwania dostępu do miejsca na dane:

• Aplikacja nie będzie miała bezpośredniego dostępu do pamięci pakietów SDK i odwrotnie.
• Pamięć zewnętrzna urządzenia nie będzie dostępna dla pakietów SDK.
• W każdym środowisku wykonawczym SDK będzie znajdować się pamięć dostępna dla wszystkich pakietów SDK i miejsce prywatne dla każdego pakietu SDK.

Podobnie jak obecny model pamięci masowej, sama pamięć masowa nie ma żadnych dowolnych limitów. Pakiety SDK mogą wykorzystywać pamięć podręczną do buforowania zasobów. Ta pamięć jest okresowo czyszczona, gdy pakiet SDK nie działa.

Realizacja

Aby zapewnić prywatność systemu między aplikacjami, pakietami SDK i użytkownikami, sam kontekst wykonywania (formaty kodu, konstrukcje językowe, dostępne interfejsy API i dane systemowe) musi utrwalać te granice prywatności lub w szczególności nie wprowadzać możliwości ich obchodzenia. Jednocześnie chcemy zachować dostęp do rozbudowanej platformy i większości środowiska wykonawczego, które mają obecnie pakiety SDK. Proponujemy zestaw aktualizacji środowiska wykonawczego, by zrównoważyć tę równowagę.

Kod

Kod na 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 w Javie. Bogactwo treści i jej struktur językowych w połączeniu z możliwością weryfikacji w porównaniu z alternatywnymi rozwiązaniami, w szczególności kodem natywnym, wydaje się odpowiednio równoważyć funkcjonalność i prywatność. Zalecamy, aby kod pakietu SDK działający w czasie działania aplikacji zawierał wyłącznie kod bajtowy Dex i nie obsługiwał dostępu JNI.

Zdajemy sobie sprawę, że istnieją przypadki użycia, takie jak wykorzystanie niestandardowego pakietu SQLite, które ze względu na wykorzystanie kodu natywnego będzie musiało zostać zastąpione innym rozwiązaniem, takim jak SQLite wbudowanej w Android SDK.

SELinux

Na Androidzie każdy proces (także ten uruchamiany jako root) działa w określonym kontekście SELinux, co pozwala jądnikowi zarządzać dostępem do usług systemowych, plików, urządzeń i innych procesów. Aby zachować większość przypadków użycia pakietów SDK i zminimalizować ryzyko obchodzenia zabezpieczeń prywatności, które staramy się rozwijać, oferujemy te aktualizacje środowiska wykonawczego SELinux z aplikacji niesystemowej:

• byłby dostępny ograniczony zestaw usług systemowych. (w ramach aktywnego projektu)
• Pakiety SDK będą mogły wczytywać i wykonywać kod tylko w pliku APK.
• Dostępny byłby ograniczony zestaw właściwości systemowych. (w ramach aktywnego projektu)

Interfejsy API

Dozwolone jest używanie interfejsów API do refleksji i wywoływania w środowisku wykonawczym SDK. Pakiet SDK nie będzie jednak mógł korzystać z odczuć ani wywoływać interfejsów API z innego pakietu SDK działającego w czasie działania. Pełną ofertę zabronionych interfejsów API przedstawimy w kolejnej aktualizacji.

Ponadto ostatnie wersje platformy Androida coraz bardziej ograniczają dostęp do trwałych identyfikatorów w celu poprawy ochrony prywatności. W przypadku środowiska wykonawczego SDK proponujemy dalsze ograniczenie dostępu do identyfikatorów, które mogą być używane do śledzenia w różnych aplikacjach.

Interfejsy API środowiska wykonawczego 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 zgłoszenie SecurityException.

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

Lifecycle

Obecnie pakiety SDK aplikacji przestrzegają cyklu życia aplikacji hosta. Oznacza to, że gdy aplikacja pojawia się na pierwszym planie lub z niej zniknie, wyłącza się albo zostaje wymuszona przez system operacyjny z powodu obciążenia pamięci, odpowiednie pakiety SDK również robią to. Nasza propozycja rozdzielenia pakietów SDK aplikacji na inny proces oznacza następujące zmiany w cyklu życia:

• Aplikację może zamknąć użytkownik lub system operacyjny. Środowisko wykonawcze SDK kończy się automatycznie natychmiast po tym.

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

  W przypadku Androida 13, gdy aplikacja działa na pierwszym planie, środowisko wykonawcze SDK działa z wysokim priorytetem i mało prawdopodobne, że zostanie zamknięte. Gdy aplikacja działa w tle, priorytet procesu środowiska wykonawczego SDK obniża się i kwalifikuje się do zamknięcia. Priorytet procesu środowiska wykonawczego SDK pozostaje niski nawet wtedy, gdy aplikacja pracuje z powrotem na pierwszym planie. W związku z tym jest bardzo prawdopodobne, że zostanie ona zakończona z powodu obciążenia pamięcią w porównaniu z aplikacjami.

  W przypadku Androida 14 i nowszych priorytety procesu aplikacji i środowiska wykonawczego pakietu SDK są takie same. Priorytety procesu ActivityManager.RunningAppProcessInfo.importance dla aplikacji i środowiska wykonawczego SDK powinny być mniej więcej takie same.

  Jeśli środowisko wykonawcze SDK kończy się, gdy aplikacja jest aktywna (np. jeśli w pakiecie jest nieobsługiwany wyjątek), utracisz stan środowiska wykonawczego SDK, w tym wszystkie wcześniej wczytane pakiety SDK i widoki zdalne. Deweloper aplikacji może rozwiązać problem zamknięcia środowiska wykonawczego SDK za pomocą dowolnej z tych metod:

  • Oferta oferuje deweloperom aplikacji powiązane metody wywołania zwrotnego w cyklu życia, które pozwalają wykryć, kiedy wystąpiło zakończenie działania środowiska wykonawczego SDK.
  • Jeśli środowisko wykonawcze SDK zostanie zamknięte podczas wyświetlania reklam, reklamy mogą nie działać zgodnie z oczekiwaniami. Na przykład liczba wyświetleń na ekranie może zostać zablokowana i nie będzie już interaktywna. Aplikacja może usunąć wyświetlenie reklamy, jeśli nie wpłynie to na wrażenia użytkownika.
  • Aplikacja może podjąć kolejną próbę wczytania pakietów SDK i żądania reklam.
  • W przypadku Androida 14: jeśli środowisko wykonawcze SDK zostanie zamknięte po załadowaniu pakietów SDK, a deweloper aplikacji nie zarejestruje wspomnianych metod wywołania zwrotnego cyklu życia, aplikacja zostanie domyślnie zamknięta. Tylko procesy aplikacji, które załadowały pakiety SDK, są zamykane i wychodzą normalnie.
  • Obiekty Binder zwrócone przez pakiet SDK w celu komunikowania się z nim (np. SandboxedSdk) zgłaszają metodę DeadObjectException, jeśli jest ona używana przez aplikację.

  Ten model cyklu życia może się zmienić w przyszłych aktualizacjach.

  W przypadku powtarzających się awarii deweloper aplikacji powinien zaplanować stopniowe pogorszenie działania bez pakietu SDK lub powiadomić użytkownika, czy pakiet SDK jest kluczowy dla działania głównej funkcji aplikacji. Więcej informacji o interakcji między aplikacją a pakietem SDK znajdziesz w sekcji dotyczącej komunikacji w tym dokumencie.

Pakiety SDK inne niż RE mogą nadal używać standardowych podstawowych elementów systemu operacyjnego dostępnych w ich umieszczonej aplikacji – w tym usług, działań i transmisji, podczas gdy pakiety SDK RE nie mają takiej możliwości.

Przypadki szczególne

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

• Jeśli wiele aplikacji ma ten sam identyfikator UID, środowisko wykonawcze SDK może nie działać prawidłowo. W przyszłości możemy dodać obsługę udostępnianych identyfikatorów UID.
• W przypadku aplikacji z wieloma procesami wczytywanie pakietu SDK powinno się odbywać w procesie głównym.

Renderowanie multimediów

Istnieją pakiety SDK, które renderują treści (np. tekst, obrazy i filmy) w widoku określonym przez aplikację. W tym celu proponujemy metodę zdalnego renderowania, w ramach której SDK renderuje multimedia w środowisku wykonawczym SDK, ale za pomocą interfejsu API SurfaceControlViewHost umożliwi wyrenderowanie multimediów w widoku określonym przez aplikację. Dzięki temu pakiet SDK może renderować te multimedia w sposób prywatny dla użytkownika, a jednocześnie wykrywać nieprawidłowe i fałszywe interakcje użytkowników z renderowanymi multimediami oraz zapobiegać im.

Reklamy natywne, które nie są renderowane przez pakiet SDK, ale przez aplikację, będą obsługiwane przez pakiety SDK w środowisku wykonawczym SDK. Zbieranie sygnałów i pobieranie kreacji odbywa się spójnie w przypadku reklam innych niż natywne. To jest aktywny obszar badań.

Reklamy wideo typu In-Stream wyświetlają się w odtwarzaczu w aplikacji, a nie w odtwarzaczu czy widoku w pakiecie SDK, więc model renderowania różni się od innych formatów reklam. Aktywnie badamy mechanizmy wstawiania reklam po stronie serwera i za pomocą pakietu SDK.

Stan systemu

Staramy się zminimalizować wpływ środowiska wykonawczego SDK na urządzenia użytkowników i pracujemy nad tym. Najprawdopodobniej jednak niektóre podstawowe urządzenia z Androidem 13 z bardzo ograniczonymi zasobami systemowymi, takie jak Android (wersja Go), nie będą obsługiwać środowiska wykonawczego SDK ze względu na wpływ na stan systemu. Wkrótce podamy minimalne wymagania niezbędne do skutecznego korzystania ze środowiska wykonawczego SDK.

Komunikacja

Ponieważ aplikacje i pakiety SDK działają obecnie w ramach tego samego procesu, komunikacja między nimi jest niezablokowana i bezpośrednia. Dodatkowo Android umożliwia komunikację między aplikacjami, nawet jeśli komunikacja zaczyna się i kończy z użyciem pakietów SDK. Ten swobodny model komunikacji umożliwia różne przypadki użycia, a jednocześnie umożliwia nieujawnione udostępnianie danych między aplikacjami i pakietami SDK w aplikacjach i między nimi. Proponujemy poniższe zmiany w tym modelu komunikacji, aby znaleźć równowagę między wartością takiej komunikacji a realizacją wyznaczonych przez nas celów.

Z aplikacji do pakietu SDK

Interfejs między aplikacją a pakietem SDK stanowi najczęstszą ścieżkę komunikacji z pakietem SDK, a interfejs API pakietu to interfejs API, który w znacznym stopniu dotyczy różnic i innowacyjności. Staramy się utrzymać zdolność pakietów SDK do wprowadzania innowacji i wyróżniania się na tle konkurencji. Dlatego umożliwiamy pakietom SDK udostępnianie interfejsów API aplikacjom i zapewnianie im możliwości korzystania z tych innowacji.

Biorąc pod uwagę strukturę granic procesu środowiska wykonawczego SDK, chcemy utworzyć dostępną w aplikacji warstwę organizacyjną, 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, by interfejs do tej warstwy organizacji był zdefiniowany przez programistów korzystających z pakietów SDK i generowany przez opracowane przez nas oficjalne narzędzia do tworzenia kodu typu open source.

W ramach tej oferty pragniemy wyeliminować z użytkowania aplikacje i pakiety SDK sztuczną inteligencję, jednocześnie zapewniając deweloperom SDK elastyczność i zapewniając tym, że kod SDK uruchamia się w środowisku wykonawczym SDK, aby realizować nasze cele związane z ochroną prywatności. Jeśli wybierzemy tę ścieżkę, trzeba będzie zaprojektować język i narzędzia definicji interfejsów API z uwzględnieniem Twoich danych.

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

• Aplikacja wywołuje pakiet SDK przez interfejs, przekazując wywołania zwrotne.
• Pakiet SDK asynchronicznie spełnia żądania i odpowiada za pomocą wywołań zwrotnych.
• Można to uogólnić do dowolnego modelu subskrybenta-wydawcy. Oznacza to, że aplikacja może subskrybować zdarzenia w pakiecie SDK za pomocą wywołań zwrotnych, a gdy takie zdarzenia wystąpią, będą wywoływane wywołania zwrotne.

W konsekwencji tej oferty pakietowej można uwzględnić 2 cykle życia procesów: jeden dla samej aplikacji i drugi dla środowiska wykonawczego SDK. W ramach naszej oferty chcemy jak najwięcej zautomatyzować i zminimalizować wpływ tych procesów na deweloperów aplikacji i pakietów SDK. Poniższy diagram przedstawia rozważane podejście:

Platforma udostępnia nowe interfejsy API dla aplikacji, aby dynamicznie ładować pakiety SDK w procesie środowiska wykonawczego SDK, otrzymywać powiadomienia o zmianach stanu procesu i wchodzić w interakcje z pakietami SDK wczytywanymi do środowiska wykonawczego SDK.

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

Aplikacja komunikuje się z pakietem SDK działającym w środowisku wykonawczym SDK w ten sposób:

1. Zanim aplikacja będzie mogła wchodzić w interakcję z pakietem SDK, prosi o jego wczytanie przez platformę. Aby zapewnić integralność systemu, aplikacje określały w pliku manifestu pakiety SDK, które powinny być wczytywane. Takie pakiety będą jedynymi, które będą mogły się ładować.

   Ten fragment kodu zawiera ilustracyjny przykład interfejsu API:

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

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

   W przewodniku po usługach powiązanych znajdziesz różne sposoby udostępniania usług IBinder. Niezależnie od wybranego sposobu musisz zachować spójność między pakietem SDK a aplikacją wywołującą. Diagramy używają AIDL jako przykładu.

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

4. Aplikacja pobiera IBinder i przesyła go do interfejsu pakietu SDK, wywołując swoje 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 dotyczącej renderowania multimediów w tym dokumencie, aby aplikacja mogła uzyskać pakiet SDK do renderowania multimediów w widoku danych, może wywołać metodę requestSurfacePackage() i pobrać odpowiednią SurfaceControlViewHost.SurfacePackage.

   Ten fragment kodu zawiera ilustracyjny przykład interfejsu API:

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

2. Aplikacja mogła następnie umieścić zwrócony SurfacePackage w obiekcie SurfaceView za pomocą setChildSurfacePackage API w SurfaceView.

   Ten fragment kodu zawiera ilustracyjny przykład interfejsu API:

   SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
   

Proponujemy, by interfejsy API IBinder i requestSurfacePackage() miały charakter ogólny i nie powinny być wywoływane bezpośrednio przez aplikacje. Te interfejsy API byłyby wywoływane przez omówione powyżej wygenerowane informacje o interfejsie API w warstwie „podkładki”, aby zmniejszyć obciążenie deweloperów aplikacji.

Z pakietu SDK na pakiet SDK

2 pakiety SDK w tej samej aplikacji często muszą się ze sobą komunikować. Może się tak zdarzyć, gdy architektura danego pakietu SDK składa się ze składowych pakietów SDK. Może się tak również zdarzyć, gdy 2 pakiety SDK z różnych stron muszą ze sobą współpracować, aby zrealizować żądanie z aplikacji wywołującej.

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

• Kiedy oba pakiety SDK są dostępne w czasie działania. W tym przypadku oba pakiety SDK działają w środowisku wykonawczym SDK ze wszystkimi zabezpieczeniami. Pakiety SDK nie mogą komunikować się tak jak w aplikacji w aplikacji. Dlatego w SdkSandboxController dodaliśmy interfejs API, który umożliwia pobieranie obiektów SandboxedSdk ze wszystkich załadowanych pakietów RE-SDK. Dzięki temu pakiet RE-SDK może komunikować się z innymi pakietami SDK wczytywanymi w środowisku wykonawczym SDK.
• Gdy tylko 1 pakiet SDK jest dostępny w czasie działania.
  • Jeśli wywołujący pakiet SDK działa w aplikacji, nie różni się to od wywoływania drugiego pakietu SDK przez samą aplikację w środowisku wykonawczym SDK.
  • Jeśli wywołujący pakiet SDK działa w środowisku wykonawczym SDK, w ramach tej oferty zaleca się udostępnienie metody za pomocą funkcji IBinder opisanej w sekcji „app-to-SDK”, w której kod w aplikacji nasłuchuje, przetwarza i odpowiada za pomocą udostępnionych wywołań zwrotnych.
  • Pakiet SDK do wyświetlania reklam, który nie działa w czasie działania, może nie być w stanie zarejestrować się samodzielnie. Proponujemy utworzenie pakietu SDK zapośredniczenia, który obejmuje dowolnych partnerów lub pakiety SDK aplikacji jako bezpośrednie zależności od aplikacji i obsługuje rejestrację. Umożliwia on komunikację między pakietami SDK, które nie działają w czasie działania lub innymi zależnościami, a mediatorem działającym w czasie działania, który działa jako adapter.

Zestaw funkcji do komunikacji SDK-SDK został podzielony na następujące kategorie:

• Komunikacja między pakietem SDK a pakietem SDK w środowisku wykonawczym SDK (dostępna w najnowszej wersji przedpremierowej dla programistów)
• Komunikacja między aplikacją a pakietem SDK w pakiecie SDK (w najnowszej wersji przedpremierowej dla programistów)
• Jak widoki i renderowanie zdalne powinny działać w przypadku zapośredniczenia (propozycja w fazie opracowywania)

Podczas projektowania elementów podstawowych bierzemy pod uwagę te przypadki użycia:

1. Zapośredniczenie i określanie stawek. Wiele pakietów SDK do wyświetlania reklam oferuje funkcję zapośredniczenia lub określania stawek, dzięki której wywołuje różne inne pakiety SDK na potrzeby wyświetlenia reklamy (zapośredniczenia) lub zbierania sygnałów potrzebnych do przeprowadzenia aukcji (określanie stawek). Zwykle koordynacyjny pakiet SDK wywołuje inne pakiety SDK za pomocą adaptera dostarczonego przez koordynacyjny pakiet SDK. Biorąc pod uwagę powyższe podstawowe elementy, koordynujący pakiet SDK (czy pakiet RE lub nie) powinien mieć dostęp do wszystkich pakietów SDK RE i innych niż RE podczas normalnego działania. Renderowanie w tym kontekście to aktywny obszar badań.
2. Odkrywanie funkcji. Niektóre usługi SDK składają się z mniejszych pakietów SDK, które w ramach procesu wykrywania w ramach różnych pakietów SDK określają podstawowy zestaw funkcji dostępnych dla dewelopera aplikacji. Podstawowe zasady rejestracji i odkrywania powinny umożliwiać to działanie.
3. Modele subskrypcji wydawców. Niektóre pakiety SDK mają zapewniać centralnego wydawcę zdarzeń, które inne pakiety SDK i aplikacje mogą subskrybować w celu otrzymywania powiadomień za pomocą wywołań zwrotnych. Powyższe elementy podstawowe powinny obsługiwać ten przypadek użycia.

Z aplikacji do aplikacji

Komunikacja między aplikacją a aplikacją polega na tym, że co najmniej 1 z 2 procesów komunikacyjnych to pakiet SDK działający w czasie działania i potencjalny wektor nieujawnionego udostępniania danych. W związku z tym pakiet SDK nie może ustanowić kanału komunikacji bezpośredniej z aplikacją inną niż aplikacja kliencka lub z pakietami SDK w innym środowisku wykonawczym SDK utworzonym dla innej aplikacji. Można to osiągnąć w następujący sposób:

• Pakiet SDK nie może definiować w swoim pliku manifestu komponentów takich jak <service>, <contentprovider> ani <activity>.
• Pakiet SDK nie może opublikować ContentProvider ani wysłać komunikatu.
• Pakiet SDK może uruchamiać aktywność należącą do innej aplikacji, ale z ograniczeniami dotyczącymi tego, co można wysyłać w intencji. Na przykład nie można do niej dodać żadnych dodatkowych elementów ani działań niestandardowych.
• Pakiet SDK może uruchamiać się tylko z listy dozwolonych lub tworzyć z nimi powiązania.
• Pakiet SDK ma dostęp tylko do podzbioru systemu ContentProvider (np. com.android.providers.settings.SettingsProvider), w których uzyskane dane nie zawierają identyfikatorów i nie można ich użyć do utworzenia odcisku cyfrowego użytkownika. Ta weryfikacja dotyczy również dostępu do ContentProvider za pomocą ContentResolver.
• Pakiet SDK ma dostęp tylko do podzbioru chronionych odbiorników (np. android.intent.action.AIRPLANE_MODE).

Tagi pliku manifestu

Po zainstalowaniu pakietu SDK PackageManager analizuje jego plik manifestu i nie instaluje go, jeśli występują zablokowane tagi pliku manifestu. Na przykład pakiet SDK nie może definiować komponentów takich jak <service>, <activity>, <provider> czy <receiver> ani zadeklarować <permission> w pliku manifestu. Tagi, których instalacja się nie udała, nie są obsługiwane w środowisku wykonawczym pakietu SDK. Tagi, które nie przejdą instalacji, ale będą dyskretnie ignorowane, mogą być obsługiwane w przyszłych wersjach Androida.

Testy te mogą też być wykonywane przez wszystkie narzędzia dostępne podczas kompilacji, których SDK używa do tworzenia tego pakietu, oraz podczas przesyłania go do sklepu z aplikacjami.

Pomoc w aktywności

Pakiety SDK w środowisku wykonawczym SDK nie mogą dodawać tagu aktywności do pliku manifestu ani uruchamiać własnych działań przy użyciu polecenia Context.startActivity. Zamiast tego na żądanie tworzy działania dla pakietów SDK i udostępnia je pakietom SDK.

Aktywność na platformie jest typu android.app.Activity. Działanie na platformie rozpoczyna się od jednej z działań w aplikacji i jest częścią zadania aplikacji. FLAG_ACTIVITY_NEW_TASK nie jest obsługiwany.

Aby pakiet SDK mógł rozpocząć działanie, powinien zarejestrować instancję typu SdkSandboxActivityHandler, która służy do powiadamiania o tworzeniu aktywności, gdy aplikacja wywołuje metodę SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) w celu rozpoczęcia działania.

Przepływ żądań związanych z aktywnością możesz zobaczyć na wykresie poniżej.

Programowanie

Kluczową zasadą zawartą w tej ofercie jest minimalizowanie wpływu na ekosystem deweloperów w zakresie, w jakim jest to możliwe. Ta oferta obejmuje kompleksowy zestaw narzędzi dla programistów do pisania, tworzenia i debugowania aplikacji RE i pakietów SDK. Aby zapewnić integralność tej oferty, wprowadziliśmy pewne zmiany w konfigurowaniu, tworzeniu i tworzeniu aplikacji i pakietów SDK RE.

Tworzenie

Android Studio i powiązane z nim narzędzia zostaną zaktualizowane tak, aby obsługiwały środowisko wykonawcze z pakietem SDK. Dzięki temu deweloperzy będą prawidłowo skonfigurowali aplikacje i pakiety SDK RE. W razie potrzeby również dopilnują, aby w starszych lub nieobsługiwanych wywołaniach stosowane były nowsze rozwiązania alternatywne. Na etapie tworzenia musisz wykonać pewne działania, które należałoby wykonać w ramach naszej propozycji.

Programiści aplikacji

Deweloperzy aplikacji muszą określić zależność od certyfikatów pakietu SDK RE i SDK w pliku manifestu. W ramach tej oferty twórcy aplikacji traktują te dane jako źródło wiarygodnych danych. Na przykład:

• Nazwa:nazwa pakietu SDK lub biblioteki.
• Wersja główna:kod głównej wersji pakietu SDK.
• Skrót certyfikatu: skrót certyfikatu kompilacji pakietu SDK. W przypadku danej kompilacji proponujemy 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 jest to wersja RE czy nie. Aplikacje, które statycznie łączą pakiety SDK, będą korzystać z bieżących mechanizmów zależności.

Ze względu na nasz cel przy minimalnym wpływie na deweloperów ważne jest, aby po określeniu docelowego poziomu interfejsu API obsługującego środowisko wykonawcze SDK deweloperzy aplikacji musieli mieć tylko 1 kompilację niezależnie od tego, czy działają na urządzeniach, które obsługują środowisko wykonawcze SDK, czy nie.

Deweloperzy pakietów SDK

W proponowanym projekcie deweloperzy używający pakietu SDK RE muszą wyraźnie zadeklarować w pliku manifestu nowy element reprezentujący pakiet SDK lub bibliotekę. Poza tym należy podać zestaw wartości podobny jak w przypadku zależności oraz wersję podrzędną:

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

Jeśli deweloperzy korzystający z RE SDK mają jako zależności w czasie kompilacji inne pakiety SDK RE, prawdopodobnie będą musieli zadeklarować je w sposób identyczny z deklaracją tej zależności. Pakiety SDK RE, które korzystają z tych pakietów, były statyczne łączenie ich. Może to spowodować problemy, które zostaną wykryte podczas tworzenia lub podczas testów, jeśli pakiety SDK inne niż RE wymagają funkcji, których środowisko wykonawcze SDK nie obsługuje, lub jeśli musi ono działać w ramach procesu aplikacji.

Deweloperzy korzystający z pakietu SDK RE prawdopodobnie będą chcieli nadal obsługiwać urządzenia z Androidem 13 i bardzo ograniczonymi zasobami systemowymi, np. na urządzeniach z Androidem w wersji 12 lub starszej oraz w sekcji Stan systemu w tym dokumencie. Pracujemy nad sposobami, dzięki którym deweloperzy pakietów SDK będą mogli przechowywać 1 bazę kodu do obsługi środowisk RE i innych niż RE.

Kompilacje

Programiści aplikacji

Spodziewamy się, że deweloperzy aplikacji nie będą odczuć niewielkich zmian na etapie kompilacji. Na potrzeby lintowania, kompilacji i kompilacji na komputerze muszą istnieć zależności od pakietów SDK: zarówno lokalnie, jak i w sklepie z aplikacjami. Proponujemy, aby Android Studio wyodrębnił te informacje od dewelopera aplikacji przy normalnym użytkowaniu, aby informacje te były jak najbardziej przejrzyste.

Spodziewamy się, że kompilacja DEBUG będzie musiała zawierać cały kod i symbole, aby ułatwić debugowanie. W przypadku kompilacji VERSION z końcowego artefaktu zostanie opcjonalnie usunięte wszystkie pakiety SDK rozpowszechniane w sklepach z aplikacjami (RE lub nie).

Jesteśmy na etapie projektowania. W miarę pojawiania się kolejnych materiałów przekażemy więcej informacji.

Deweloperzy pakietów SDK

Pracujemy nad możliwością wbudowania wersji pakietu SDK innych niż RE i RE w jeden artefakt na potrzeby dystrybucji. Dzięki temu deweloperzy aplikacji nie będą musieli obsługiwać osobnych kompilacji pakietu SDK RE i innych niż RE.

Podobnie jak w przypadku aplikacji, wszelkie pakiety SDK zależności rozmieszczone w sklepach z aplikacjami muszą istnieć na komputerze do lintowania, kompilacji i kompilacji. Oczekujemy, że Android Studio to bezproblemowo.

Testowanie

Programiści aplikacji

Zgodnie z naszą ofertą deweloperzy aplikacji będą mogli testować swoje aplikacje na urządzeniach z Androidem 13 w zwykły sposób. Po stworzeniu aplikacji można ją zainstalować na urządzeniu RE lub emulatorze. Proces instalacji zapewni instalację odpowiednich pakietów SDK na urządzeniu lub emulatorze, niezależnie od tego, czy zostały pobrane ze zdalnego repozytorium pakietów SDK czy z pamięci podręcznej z systemu kompilacji.

Deweloperzy pakietów SDK

Deweloperzy zwykle używają własnych aplikacji testowych na urządzeniach i emulatorów do testowania swoich rozwiązań. Nasza propozycja tego nie zmienia. Weryfikacja w aplikacji odbywałaby się zgodnie z opisanymi powyżej dla deweloperów aplikacji, przy czym 1 artefakt kompilacji byłby przeznaczony zarówno dla aplikacji RE, jak i innych niż RE. Programiści pakietów SDK mogą przeglądać kod niezależnie od tego, czy znajduje się on w środowisku wykonawczym SDK czy nie. Obowiązują jednak pewne ograniczenia w zakresie zaawansowanych narzędzi do debugowania i profilowania. To jest aktywny obszar badań.

Rozkład

Nasza propozycja projektu polegająca na oddzieleniu aplikacji od jej pakietów SDK umożliwiła rozpowszechnianie pakietów SDK w sklepach z aplikacjami. To ogólna możliwość i nie dotyczy konkretnego sklepu z aplikacjami. Korzyści są jasne:

• Zadbaj o jakość i spójność pakietów SDK.
• Uprość publikowanie dla deweloperów pakietów SDK.
• Przyspieszenie wdrażania drobnych aktualizacji wersji pakietu SDK w zainstalowanych aplikacjach.

Aby rozpowszechnianie pakietów SDK można było używać, sklep z aplikacjami musi zapewniać większość z tych funkcji:

• Mechanizm, za pomocą którego deweloperzy mogą przesyłać do sklepu pakiety SDK udostępniane w sklepie z aplikacjami, aktualizować je, wycofywać i ewentualnie usuwać.
• Mechanizm zapewniający integralność pakietu SDK i jego pochodzenie, a także aplikację i jej pochodzenie oraz rozwiązywanie związanych z nimi zależności.
• mechanizm wdrażania ich na urządzeniach w spójny i niezawodny sposób.

Zmieniające się ograniczenia w czasie

Spodziewamy się, że ograniczenia związane z kodem w środowisku wykonawczym SDK zmienią się w późniejszych wersjach Androida. Aby zapewnić zgodność aplikacji, nie zmienimy tych ograniczeń poprzez aktualizacje modułu głównego na danym poziomie pakietu SDK. Zachowanie powiązane z danym targetSdkVersion zostaje zachowane do czasutargetSdkVersionwycofania jego obsługi przez zasady dotyczące sklepu z aplikacjami.targetSdkVersionWycofywanie może odbywać się szybciej niż w przypadku aplikacji. Ograniczenia będą często się zmieniać w przypadku różnych wersji pakietu Android SDK, zwłaszcza w pierwszych wersjach.

Dodatkowo tworzymy mechanizm wczesnych testów, który umożliwia testerom zewnętrznym i wewnętrznym dołączenie do grupy, która otrzyma zestaw ograniczeń zaproponowany dla następnej wersji Androida. Pomoże nam to uzyskać opinie i zrozumieć proponowane zmiany w zestawie ograniczeń.

Najczęstsze pytania

1. Co to jest pakiet SDK do wyświetlania reklam?

   Pakiet SDK związany z reklamami ułatwia kierowanie reklam na użytkowników z komunikatami komercyjnymi w aplikacjach, które nie należą do reklamodawcy. Dotyczy to m.in. pakietów SDK Analytics, w których można tworzyć grupy użytkowników na potrzeby późniejszego kierowania, pakietów SDK do wyświetlania reklam, pakietów SDK do zapobiegania nadużyciom i oszustwom oraz pakietów SDK do zaangażowania i pakietów SDK atrybucji.

2. Czy w środowisku wykonawczym SDK można uruchomić dowolny pakiet SDK?

   Początkowo skupiamy się na pakietach SDK związanych z reklamami, ale deweloperzy niepowiązanych z nimi pakietów, którzy dbają o ochronę prywatności i uważają, że mogą działać zgodnie z powyższymi warunkami, mogą podzielić się opinią na temat swoich pakietów SDK działających w środowisku wykonawczym SDK. Środowisko wykonawcze SDK nie zostało jednak zaprojektowane pod kątem zgodności ze wszystkimi projektami SDK. Poza udokumentowanymi ograniczeniami środowisko wykonawcze SDK prawdopodobnie nie jest odpowiednie dla pakietów SDK, które wymagają komunikacji w czasie rzeczywistym lub wysokiej przepustowości z aplikacją hostującą.

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

   Obecnie środowisko wykonawcze oparte na Javie nie pozwala w łatwy sposób wyznaczyć granic bezpieczeństwa niezbędnych do zapewnienia prywatności użytkowników, które są wymagane dla użytkowników Androida. Próba wdrożenia takiego rozwiązania prawdopodobnie wymagałaby wieloletnich nakładów pracy i nie daje gwarancji powodzenia. Dlatego w Piaskownicy prywatności stosowane są granice procesów – sprawdzone i dobrze znane technologie.

4. Czy przeniesienie pakietów SDK do środowiska wykonawczego SDK zwiększy rozmiar pobieranego pliku lub zaoszczędzi miejsce?

   Jeśli wiele aplikacji jest zintegrowanych z pakietami SDK tej samej wersji, uruchamianymi w środowisku wykonawczym, może to zmniejszyć rozmiar pobierania i miejsce na dysku.

5. Do jakich zdarzeń cyklu życia aplikacji (np. działania aplikacji w tle) będą miały dostęp pakiety SDK w środowisku wykonawczym SDK?

   Aktywnie pracujemy nad wprowadzeniem obsługi funkcji powiadamiania środowiska wykonawczego SDK o zdarzeniach cyklu życia aplikacji klienckiej na poziomie aplikacji (np. aplikacji uruchamiającej się w tle lub na pierwszym planie). 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 JavaScript jest wyłączony
• Przewodnik po środowisku wykonawczym SDK dla programistów