Przegląd środowiska wykonawczego SDK

Uwaga: ten dokument odzwierciedla obecne propozycje dotyczące Piaskownicy prywatności na Androida i może ulec zmianie. Zachęcamy do dzielenia się opiniami i komentarzami, które pomogą nam w realizacji tych działań.

Platforma Android korzysta z koncepcji piaskownicy aplikacji, aby zapewnić niezawodne wykonywanie i ochronę kodu aplikacji oraz granice procesów. W aplikacjach często występuje kod innych firm, często w formie pakietów SDK, np. pakietów SDK do reklam lub analityki. Dzięki temu deweloperzy aplikacji mogą skupić się na wyróżnieniu swojej aplikacji, korzystając jednocześnie z pracy ekspertów w danym temacie, aby zwiększyć skalę działania ponad to, co mogliby osiągnąć samodzielnie.

Podobnie jak w przypadku większości systemów operacyjnych, na Androidzie pakiety SDK są wykonywane w sandboksie aplikacji hosta i dziedziczą te same uprawnienia co aplikacja hosta, a także mają dostęp do pamięci i magazynu danych aplikacji hosta. Chociaż ta architektura umożliwia elastyczne integrowanie pakietów SDK i aplikacji, stwarza też możliwość nieujawnionego gromadzenia i udostępniania danych użytkowników. Ponadto deweloperzy aplikacji mogą nie zdawać sobie w pełni sprawy z funkcjonalności pakietu SDK innej firmy i danych, do których ma on dostęp, przez co trudno jest im uwzględnić w swoich aplikacjach gromadzenie i udostępnianie danych.

W Androidzie 14 dodaliśmy nową funkcję platformy, która umożliwia uruchamianie pakietów SDK innych firm w dedykowanym środowisku wykonawczym o nazwie środowisko wykonawcze SDK. Środowisko wykonawcze SDK zapewnia te mocniejsze zabezpieczenia i gwarancje dotyczące gromadzenia i udostępniania danych użytkowników:

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

Uwaga: w pierwszej wersji środowiska wykonawczego SDK skupiamy się na obsłudze pakietów SDK związanych z reklamami, w tym pakietów SDK umożliwiających wyświetlanie reklam, pomiar reklam, wykrywanie oszustw związanych z reklamami i wykrywanie 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. Zachęcamy też do przesyłania opinii z szerszej społeczności deweloperów, abyśmy mogli kształtować przyszłe wersje środowiska wykonawczego pakietu SDK, w tym obsługę dodatkowych przypadków użycia.

Cele

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

• Ogranicz nieujawniony dostęp i udostępnianie danych aplikacji użytkownika przez zewnętrzne interfejsy SDK za pomocą izolacji procesów i dobrze zdefiniowanych ustawień dostępu do interfejsu API oraz danych. Więcej informacji o izolacji procesów znajdziesz w osobnej sekcji tego dokumentu.
• Ogranicz niejawne śledzenie sposobu korzystania z aplikacji przez zewnętrzne pakiety SDK, ograniczając dostęp do unikalnych, stałych identyfikatorów.
• przyspieszyć bezpieczną dystrybucję aktualizacji pakietu SDK w aplikacjach, zmniejszając obciążenie deweloperów aplikacji i użytkowników; Więcej informacji o zaproponowanym modelu zaufanej dystrybucji pakietów SDK znajdziesz w innej sekcji tego dokumentu.
• Pomagać deweloperom aplikacji w lepszym uwzględnianiu w swoich aplikacjach sposobów dostępu do danych i ich udostępniania.
• Pomagaj deweloperom pakietów SDK zapobiegać modyfikowaniu ich przez inne pakiety SDK poprzez ograniczanie pewnych niebezpiecznych konstrukcji językowych, takich jak kod JNI.
• Pomaga pakietom SDK do wyświetlania reklam w wykrywaniu nieprawidłowego ruchu i oszustw reklamowych oraz zapobieganiu im poprzez pełną kontrolę nad wyświetlaniem multimediów w widokach zdalnych.
• jak najbardziej ograniczyć niepotrzebny wpływ na deweloperów aplikacji i pakietów SDK;

Pakiety SDK są wykonywane w oddzielnym procesie.

Proponowane środowisko wykonawcze pakietu SDK umożliwia kompatybilnym pakietom SDK (w dalszej części tego dokumentu nazywanym pakietami SDK używanymi w czasie działania) działanie w oddzielnym procesie aplikacji. Platforma umożliwia dwukierunkową komunikację między procesem aplikacji a środowiskiem wykonawczym pakietu SDK. Szczegółowe informacje znajdziesz w sekcji dotyczącej komunikacji w tym dokumencie. Pakiety SDK innych niż RE pozostaną w aplikacji tak jak dotąd. Te zmiany ilustrują poniższe diagramy:

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

Proponowane oddzielenie pakietu SDK od aplikacji motywuje do zastosowania innej koncepcji oddzielenia, która dotyczy pakietu SDK i rozpowszechniania aplikacji. Nasz projekt wymaga zaufanego mechanizmu dystrybucji i 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ć statycznie powiązane i spakowane z aplikacjami przed przesłaniem do sklepu z aplikacjami w celu dystrybucji. Zamiast tego zastosowano następującą procedurę:

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 pobiera aplikację, proces instalacji może użyć określonych przez nią zależności pakietu SDK, aby pobrać je ze sklepu z aplikacjami.

Ten nowy mechanizm dystrybucji umożliwiłby deweloperom pakietów SDK wprowadzanie nieprzerwanych zmian (czyli bez zmian w interfejsach API lub ich semantyce) w pakietach SDK i ich dystrybucję na urządzenia bez udziału deweloperów aplikacji. Te zmiany w pakiecie SDK, które nie powodują przerw w działaniu aplikacji, można wdrożyć lub wycofać bez konieczności czekania, aż deweloperzy aplikacji ponownie utworzyli aplikacje z nowymi pakietami SDK, lub aż użytkownicy zaktualizują aplikacje. Zmiany powodujące przerwanie nadal będą wymagać aktualizacji przez deweloperów aplikacji, ale deweloperzy pakietów SDK będą mogli szybciej i w bardziej ujednolicony sposób udostępniać najnowsze zmiany i poprawki, które nie powodują przerwania, większej liczbie 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 pakietu SDK deweloperzy pakietów SDK mogliby publikować je w sklepie z aplikacjami, korzystając z interfejsu przesyłania pakietów SDK. Sklep z aplikacjami rozpowszechniałby aplikacje wraz z zależnymi od nich pakietami SDK na urządzenia 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 następnych sekcjach proponujemy szereg zmian w tych ogólnych kategoriach:

• Dostęp: uprawnienia, pamięć, miejsce na dane
• Wykonanie: języki, zmiany w czasie wykonywania, cykl życia, renderowanie multimediów
• Komunikacja: komunikacja między aplikacją a pakietem SDK oraz między pakietami SDK
• Tworzenie: jak kompilować, debugować i testować ten model
• Rozpowszechnianie: jak rozpowszechniać, aktualizować i przywracać wersje Androida, aplikacje i pakiety SDK

Dokument zawiera też najczęstsze pytania.

To wstępna propozycja projektu, która może być ważną zmianą dla niektórych członków ekosystemu. Dlatego prosimy o Twoją opinię, którą możesz przekazać za pomocą problemu.

Dostęp

Zarządzanie prywatnością w systemie oznacza zarządzanie tym, w jaki sposób różne strony mogą uzyskiwać 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 umożliwić komunikację z usługą internetową.
• ACCESS_NETWORK_STATE: informacje o sieciach.
• READ_BASIC_PHONE_STATE: dostęp do informacji o stanie telefonu, np. o typie sieci komórkowej.
• Uprawnienia dostępu do interfejsów API chroniących prywatność, które zapewniają podstawowe funkcje reklamowe bez konieczności uzyskiwania dostępu do identyfikatorów międzyaplikacyjnym.
• AD_ID: możliwość żądania identyfikatora wyświetlania reklam. Dostęp do tego uprawnienia byłby również ograniczony przez aplikację.

Obecnie sprawdzamy, czy i jak autoryzować dodatkowe uprawnienia, aby ograniczyć wpływ na użytkowników pod względem prywatności i używalności. Prosimy o opinię na temat przypadków użycia, które nie są obsługiwane przez ten zestaw uprawnień.

Pamięć

Środowisko wykonawcze pakietu SDK będzie mieć własną odizolowaną przestrzeń pamięci, ponieważ będzie mieć własny proces. Ta struktura domyślnie odmawia dostępu pakietowi SDK do przestrzeni pamięci aplikacji, a aplikacja nie ma dostępu do przestrzeni pamięci pakietu SDK. Proponujemy zachowanie tego domyślnego zachowania, aby zachować zgodność z zasadą minimalnych uprawnień.

Miejsce na dane

Celem tej propozycji jest zrównoważenie potrzeby dostępu pakietów SDK do pamięci w ramach normalnego działania oraz zminimalizowanie śledzenia w wielu aplikacjach i procesach za pomocą trwałej pamięci. Proponujemy następującą zmianę sposobu dostępu do miejsca na dane:

• Aplikacja nie będzie mieć bezpośredniego dostępu do pamięci pakietu SDK i odwrotnie.
• Zewnętrzna pamięć urządzenia nie będzie dostępna dla pakietów SDK.
• W ramach każdego środowiska wykonawczego SDK dostępne będzie zarówno miejsce na dane dostępne dla wszystkich pakietów SDK, jak i miejsce na dane prywatne dla danego pakietu SDK.

Podobnie jak w przypadku obecnego modelu, rozmiar miejsca na dane nie będzie podlegał dowolnym ograniczeniom. Pakiety SDK mogą używać pamięci do przechowywania w buforze zasobów. To miejsce na dane jest okresowo czyszczone, gdy zestaw SDK nie jest aktywny.

Wykonanie

Aby zapewnić prywatność w systemie obejmującym aplikacje, pakiety SDK i użytkowników, kontekst wykonywania (formaty kodu, konstrukcje językowe, dostępne interfejsy API i dane systemowe) musi wzmacniać te granice prywatności lub przynajmniej nie umożliwiać ich obchodzenia. Jednocześnie chcemy zachować dostęp do bogatej platformy i większości funkcji dostępnych w pakietach SDK. Proponujemy zestaw aktualizacji środowiska wykonawczego, które pozwolą osiągnąć ten balans.

Kod

Kod Androida (aplikacje i pakiety SDK) jest interpretowany głównie przez środowisko wykonawcze Androida (ART), niezależnie od tego, czy został napisany w języku Kotlin czy Java. Bogactwo ART i oferowane przez niego konstrukcje językowe w połączeniu z możliwością weryfikacji, którą zapewnia w porównaniu z alternatywami, zwłaszcza z kodem natywnym, wydaje się zapewniać odpowiednią równowagę między funkcjonalnością a prywatnością. Proponujemy, aby kod pakietu SDK używanego w czasie działania składał się wyłącznie z kodu bajtowego Dex, a nie obsługiwał dostępu JNI.

Zdajemy sobie sprawę, że w pewnych przypadkach, np. przy korzystaniu z niestandardowego pakietu SQLite, który ze względu na używanie kodu natywnego, należy zastąpić alternatywą, np. wbudowaną wersją SQLite w pakiecie Android SDK.

SELinux

W Androidzie każdy proces (w tym procesy działające jako root) jest uruchamiany w określonym kontekście SELinux, co pozwala jądrowi zarządzać kontrolą dostępu do usług systemowych, plików, urządzeń i innych procesów. Aby zachować większość zastosowań pakietu SDK, a jednocześnie zminimalizować możliwość obejścia zabezpieczeń prywatności, proponujemy następujące zmiany w kontekście SELinux aplikacji niesystemowej dla środowiska wykonawczego pakietu SDK:

• Dostępny byłby ograniczony zestaw usług systemowych. (w trakcie opracowywania)
• Pakiety SDK 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 opracowywania)

Interfejsy API

W czasie działania pakietu SDK można używać mechanizmu odbicia lustrzanego 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 Androida dostęp do trwałych identyfikatorów jest coraz bardziej ograniczany, aby zwiększyć ochronę prywatności. W przypadku pakietu SDK proponujemy dalsze ograniczenie dostępu do identyfikatorów, które mogą być używane do śledzenia między aplikacjami.

Interfejsy API środowiska wykonawczego pakietu SDK są dostępne tylko z aplikacji działających na pierwszym planie. Próba uzyskania dostępu do interfejsów API SdkSandboxManager z aplikacji w tle powoduje wygenerowanie wyjątku SecurityException.

Ponadto RE-SDK nie może używać interfejsów API powiadomień do wysyłania powiadomień do użytkowników w dowolnym momencie.

Lifecycle

Pakiety SDK aplikacji obecnie podążają za cyklem życia aplikacji hosta, co oznacza, że gdy aplikacja przechodzi na pierwszy lub drugi plan, zamyka się lub jest wymuszająco zatrzymana przez system operacyjny z powodu braku pamięci, pakiety SDK aplikacji również to robią. Nasza propozycja oddzielenia pakietów SDK aplikacji do innego procesu oznacza te zmiany w cyklu życia:

• Aplikację może zamknąć użytkownik lub system operacyjny. Środowisko wykonawcze SDK zostanie automatycznie zamknięte natychmiast po tym.

• Środowisko wykonawcze pakietu SDK może zostać zakończone przez system operacyjny z powodu braku pamięci lub nieobsługiwanej obsługi wyjątku w pakiecie SDK.

  W przypadku Androida 14, gdy aplikacja jest na pierwszym planie, środowisko wykonawcze SDK działa z wysokim priorytetem i nie jest w większości przypadków zamykane. Gdy aplikacja przejdzie na drugi plan, priorytet procesu środowiska uruchomieniowego pakietu SDK spadnie i można go zakończyć. Priorytet procesu środowiska uruchomieniowego pakietu SDK pozostaje niski, nawet 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 przetwarzania ActivityManager.RunningAppProcessInfo.importance aplikacji i czasu wykonywania pakietu SDK powinny być mniej więcej takie same.

  Jeśli środowisko wykonawcze pakietu SDK zostanie zamknięte, gdy aplikacja jest aktywna (np. gdy w pakiecie SDK wystąpi nieobsługiwany wyjątek), stan środowiska wykonawczego pakietu SDK, w tym wszystkie wcześniej załadowane pakiety SDK i widoki zdalne, zostaną utracone. Deweloperzy aplikacji mogą rozwiązać problem z zakończeniem działania środowiska wykonawczego pakietu SDK za pomocą jednej z tych metod:

  • Proponowana metoda oferuje deweloperom aplikacji powiązane metody wywołania cyklu życia, które umożliwiają wykrywanie momentu zakończenia działania środowiska wykonawczego pakietu SDK.
  • Jeśli środowisko uruchomieniowe SDK zostanie zamknięte podczas wyświetlania reklam, reklamy mogą nie działać zgodnie z oczekiwaniami. Na przykład widok może być zamrożony na ekranie i nie będzie już interaktywny. Aplikacja może usunąć widok reklamy, jeśli nie wpływa na komfort użytkownika.
  • Aplikacja może podjąć kolejną próbę załadowania pakietów SDK i poprosić o reklamy.
  • W Androidzie 14, jeśli środowisko wykonawcze SDK zostanie zamknięte, gdy są w nim załadowane pakiety SDK, a deweloper aplikacji nie zarejestrował wspomnianych wcześniej metod wywołania cyklu życia, aplikacja zostanie zamknięta domyślnie. Tylko procesy aplikacji, które wczytały pakiety SDK, są zamykane i zamykają się normalnie.
  • Obiekty bindera zwracane przez pakiet SDK do komunikacji z nim (takie jak SandboxedSdk) rzucają DeadObjectException, jeśli są używane przez aplikację.

  Ten model cyklu życia może ulec zmianie w kolejnych 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 głównej funkcji 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 dostępnych dla ich wbudowanych aplikacji, w tym usług, działań i transmisji, podczas gdy pakiety SDK RE nie mogą tego robić.

Przypadki szczególne

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

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

Renderowanie multimediów

Niektóre zestawy SDK renderują treści takie jak tekst, obrazy i filmy w określonym przez aplikację widoku. Aby to osiągnąć, proponujemy zrenderowanie zdalne, w którym pakiet SDK będzie renderować treści multimedialne w środowisku wykonawczym pakietu SDK, ale użyje interfejsu API SurfaceControlViewHost, aby umożliwić renderowanie treści w widoku określonym przez aplikację. Umożliwia to pakietowi SDK renderowanie multimediów w sposób prywatny dla użytkownika, a także zapobieganie nieprawidłowym lub oszukańczym interakcjom użytkownika z renderowanymi multimediami oraz ich wykrywanie.

Reklamy natywne, które nie są renderowane przez pakiet SDK, ale przez aplikację, będą obsługiwane przez pakiety SDK w środowisku wykonawczym SDK. Proces zbierania sygnałów i pobierania kreacji będzie przebiegał w sposób spójny z reklamami innymi niż natywne. To jest aktywny obszar badań.

Reklamy wideo typu In-Stream to reklamy wyświetlane w odtwarzaczu w aplikacji. Ponieważ film jest odtwarzany w odtwarzaczu w aplikacji, a nie w odtwarzaczu lub widoku w pakiecie SDK, model renderowania różni się od innych formatów reklam. Aktywnie badamy mechanizmy, które obsługują zarówno wstawianie reklam po stronie serwera, jak i wstawianie reklam za pomocą pakietu SDK.

Stan systemu

Staramy się zminimalizować wpływ środowiska wykonawczego pakietu SDK na działanie systemu na urządzeniach użytkowników. W tym celu opracowujemy różne rozwiązania. Prawdopodobnie jednak niektóre podstawowe urządzenia z Androidem 14 o bardzo ograniczonych zasobach systemowych, takie jak Android (edycja Go), nie będą obsługiwać środowiska wykonawczego pakietu SDK ze względu na wpływ na działanie systemu. Wkrótce udostępnimy wymagania minimalne niezbędne do prawidłowego korzystania z czasu wykonywania pakietu SDK.

Komunikacja

Aplikacje i pakiety SDK działają obecnie w ramach tego samego procesu, więc komunikacja między nimi jest nieograniczona i bezpośrednia. Ponadto Android umożliwia komunikację między aplikacjami, nawet jeśli komunikacja rozpoczyna się i kończy w pakietach SDK. Ten model swobodnej komunikacji umożliwia różne przypadki użycia, a zarazem stwarza możliwość niejawnego udostępniania danych między aplikacjami i pakietami SDK w ich obrębie oraz między aplikacjami. Proponujemy w tym modelu komunikacji wprowadzić następujące zmiany, aby osiągnąć równowagę między wartością takiej komunikacji a realizacją naszych celów.

Aplikacja – pakiet SDK

Interfejs między aplikacją a pakietem SDK to najczęstsza ścieżka komunikacji z pakietem SDK, a interfejs API pakietu SDK to miejsce, w którym tkwi większość różnic i innowacji skierowanych do użytkowników. Chcemy zachować możliwość wprowadzania innowacji i różnicowania się w przypadku pakietów SDK. Dzięki naszej propozycji pakiety SDK mogą udostępniać interfejsy API aplikacjom i zapewniać im dostęp do wszystkich tych innowacji.

Ze względu na strukturę granicy procesu w czasie działania pakietu SDK proponujemy stworzenie warstwy porządkowania dostępnej w aplikacji, która będzie przenosić wywołania interfejsu API i odpowiedzi lub wywołania zwrotne przez tę granicę między aplikacją a pakietem SDK. Proponujemy, aby interfejs tej warstwy porządkowania danych był definiowany przez programistów pakietów SDK i generowany przez oficjalne narzędzia do kompilacji typu open source, które opracujemy.

Ta propozycja ma na celu odciążenie deweloperów aplikacji i pakietów SDK od rutynowych zadań związanych z zarządzaniem typami danych, a zarazem zapewnienie deweloperom pakietów SDK większej elastyczności i sprawdzanie, czy kod pakietu SDK działa w czasie działania pakietu SDK, aby realizować nasze cele związane z prywatnością. Jeśli zdecydujemy się na tę drogę, język definiowania interfejsu API i narzędzie do tego celu będą musiały być opracowane z uwzględnieniem Twoich opinii.

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

• Aplikacja wywołuje pakiet SDK przez interfejs, przekazując wywołania zwrotne.
• Pakiet SDK asynchronicznie spełnia żądania i reaguje za pomocą funkcji wywołania zwrotnego.
• Można to zastosować do dowolnego modelu wydawca–subskrybent, co oznacza, że aplikacja może subskrybować zdarzenia w pakiecie SDK za pomocą wywołań zwrotnych, a gdy wystąpią te zdarzenia, zostaną wywołane wywołania zwrotne.

W ramach nowej struktury międzyprocesowej w propozycji występują 2 cykle życia procesu, którymi trzeba zarządzać: jeden dla samej aplikacji, a drugi dla środowiska uruchomieniowego pakietu SDK. 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 rozważane przez nas podejście:

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

Platforma udostępniałaby nowe interfejsy API, aby aplikacje mogły dynamicznie wczytywać pakiety SDK do procesu środowiska uruchomieniowego pakietu SDK, otrzymywać powiadomienia o zmianach stanu tego procesu oraz wchodzić w interakcje z pakietami SDK wczytanymi do środowiska uruchomieniowego pakietu SDK.

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

Aplikacja komunikuje się z pakietem SDK działającym w ramach procesu środowiska uruchomieniowego pakietu SDK za pomocą tych kroków:

1. Zanim aplikacja mogła wchodzić w interakcję z pakietem SDK, musiała poprosić platformę o załadowanie tego pakietu. Aby zapewnić integralność systemu, aplikacje musiałyby określać pakiety SDK, które zamierzają wczytać w pliku manifestu. Te pakiety SDK byłyby jedynymi, które można by wczytać.

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

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

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

   Przewodnik po usługach przesyłania danych zawiera różne sposoby udostępniania IBinder. Niezależnie od tego, który sposób wybierzesz, musisz zachować spójność między pakietem SDK a aplikacją wywołującą. Na diagramach jako przykład użyto interfejsu AIDL.

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

4. Aplikacja pobiera IBinder i przekształca go w interfejs pakietu SDK, wywołując jego funkcje:

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

Aplikacja może też renderować multimedia z pakietu SDK, wykonując te czynności:

1. Jak wyjaśniono w sekcji dotyczącej renderowania multimediów w tym dokumencie, aby aplikacja mogła uzyskać pakiet SDK do renderowania multimediów w widoku, może ona wywołać funkcję requestSurfacePackage() i pobrać odpowiednią funkcję SurfaceControlViewHost.SurfacePackage.

   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)
   

Proponujemy, aby interfejsy API IBinder i requestSurfacePackage() były ogólne i nie były wywoływane bezpośrednio przez aplikacje. Zamiast tego te interfejsy API byłyby wywoływane przez wygenerowane odwołanie do interfejsu API, o którym mowa powyżej, w warstwie „shim”, aby zmniejszyć obciążenie programistów aplikacji.

Pakiet SDK do pakietu SDK

Dwa pakiety SDK w tej samej aplikacji często muszą ze sobą współpracować. Może się to zdarzyć, gdy dany pakiet SDK jest zbudowany z podstawowych pakietów SDK, a także gdy 2 pakiety SDK od różnych stron muszą współpracować, aby spełnić żądanie aplikacji wywołującej.

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

• Gdy oba pakiety SDK są używane w czasie działania aplikacji. W tym przypadku oba pakiety SDK są uruchamiane w środowisku wykonawczym SDK ze wszystkimi zabezpieczeniami. Pakiety SDK nie mogą się komunikować tak, jak obecnie w aplikacji. W związku z tym dodaliśmy interfejs API SdkSandboxController, który umożliwia pobieranie obiektów SandboxedSdk dla wszystkich załadowanych pakietów SDK RE. Umożliwia to pakietowi RE-SDK komunikowanie się z innymi pakietami SDK załadowanymi w czasie działania pakietu SDK.
• Gdy tylko 1 pakiet SDK jest używany w czasie działania.
  • Jeśli wywołujący pakiet SDK jest uruchamiany w aplikacji, działa tak samo jak sama aplikacja wywołująca drugi pakiet SDK w środowisku wykonawczym SDK.
  • Jeśli wywołujący pakiet SDK działa w środowisku wykonawczym pakietu SDK, zalecamy ujawnienie metody za pomocą funkcji IBinder opisanej w sekcji „Komunikacja aplikacji z pakietem SDK”, która w aplikacji będzie nasłuchiwać, przetwarzać i wywoływać metody wywołania z dostarczonymi wywołaniami zwrotnymi.
  • 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 pakiety SDK partnerów lub aplikacji jako bezpośrednie zależności aplikacji i zajmuje się rejestracją. Ten pakiet SDK mediatora nawiązuje komunikację między pakietami SDK bez środowiska wykonawczego lub innymi zależnościami aplikacji a pakietem mediatora z włączonym środowiskiem wykonawczym, który działa jako adapter.

Zestaw funkcji do komunikacji między pakietami SDK został podzielony na te kategorie:

• Komunikacja między pakietami SDK w środowisku wykonawczym SDK (dostępna w najnowszej wersji podglądu dla deweloperów)
• Komunikacja między pakietami SDK w aplikacji a środowiskiem wykonawczym SDK (dostępna w najnowszej wersji w ramach wersji dla deweloperów)
• Jak powinny działać wyświetlenia i renderowanie zdalne w przypadku zapośredniczenia (propozycja w trakcie opracowywania)

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

1. Mediacja i określanie stawek. Wiele pakietów SDK do reklamy oferuje 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). Zazwyczaj pakiet SDK koordynujący wywołuje inne pakiety SDK za pomocą adaptera udostępnionego przez ten pakiet. Z powodu powyższych funkcji podstawowych pakiet SDK koordynujący (czyli RE lub nie) powinien mieć dostęp do wszystkich pakietów SDK RE i niebędących RE, aby zapewnić prawidłowe działanie. W tym kontekście renderowanie jest przedmiotem naszych badań.
2. Odkrywanie funkcji. Niektóre produkty SDK składają się z mniejszych pakietów SDK, które w ramach procesu wykrywania między pakietami SDK określają ostateczny zestaw funkcji udostępnianych deweloperowi aplikacji. W tym przypadku powinny być używane prymitywne funkcje rejestracji i wykrywania.
3. Modele subskrypcji wydawców. Niektóre pakiety SDK są zaprojektowane tak, aby miały centralnego wydawcę zdarzeń, do którego inne pakiety SDK lub aplikacje mogą się subskrybować w celu otrzymywania powiadomień za pomocą wywołań zwrotnych. Powyższe prymitywy powinny obsługiwać ten przypadek użycia.

Aplikacja do aplikacji

Komunikacja między aplikacjami występuje, gdy co najmniej 1 z 2 procesów jest obsługiwany przez pakiet SDK w czasie wykonywania i jest potencjalnym wektorem nieujawnionego udostępniania danych. W konsekwencji środowisko wykonawcze SDK nie może nawiązać bezpośredniego kanału komunikacji z żadną aplikacją inną niż aplikacja kliencka ani z pakietami SDK w innym środowisku wykonawczym SDK utworzonym dla innej aplikacji. Osiąga się to w następujący sposób:

• Pakiet SDK nie może definiować w pliku manifestu komponentów takich jak <service>, <contentprovider> czy <activity>.
• Pakiet SDK nie może opublikować ContentProvider ani wysłać transmisji.
• Pakiet SDK może uruchamiać aktywność należącą do innej aplikacji, ale z ograniczeniami dotyczącymi tego, co można wysłać w intencji. Nie można na przykład dodawać do tego zamiaru żadnych dodatkowych elementów ani działań niestandardowych.
• Pakiet SDK może tylko uruchamiać lub wiązać się z listą dozwolonych usług.
• Pakiet SDK ma dostęp tylko do podzbioru systemu ContentProvider (np. com.android.providers.settings.SettingsProvider), w którym uzyskane dane nie zawierają identyfikatorów i nie można ich użyć do utworzenia odcisku palca użytkownika. Te kontrole dotyczą również uzyskiwania dostępu do ContentProvider za pomocą ContentResolver.
• Pakiet SDK ma dostęp tylko do podzbioru chronionych odbiorników transmisji (takich jak android.intent.action.AIRPLANE_MODE).

Tagi pliku manifestu

Po zainstalowaniu pakietu SDK PackageManager analizuje jego plik manifestu i nie instaluje go, jeśli zawiera zabronione tagi. Pakiet SDK może na przykład nie definiować komponentów takich jak <service>, <activity>, <provider> czy <receiver>, a także nie deklarować w pliku manifestu elementu <permission>. Tagi, które nie zostały zainstalowane, nie są obsługiwane w środowisku wykonawczym pakietu SDK. Tagi, które nie powodują niepowodzenia instalacji, ale są po cichu ignorowane, mogą być obsługiwane w przyszłych wersjach Androida.

Te kontrole mogą być też stosowane przez dowolne narzędzia do kompilacji używane przez pakiet SDK do tworzenia pakietu SDK oraz w momencie przesyłania do sklepu z aplikacjami.

Pomoc dotycząca 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 i udostępnia je tym pakietom.

Aktywność na platformie jest typu android.app.Activity. Aktywność platformy rozpoczyna się od jednej z aktywności aplikacji i jest częścią zadania aplikacji. FLAG_ACTIVITY_NEW_TASK nie jest obsługiwane.

Uwaga: obiekt Activity przekazany przez platformę jest typu android.app.Activity, który nie jest zgodny z elementami androidx, takimi jak appcompat lub Compose.

Uwaga: pakiet SDK nie może używać obiektu Context obiektu Activity. Zamiast tego powinien używać obiektu SandboxedSdkProvider#getContext() do pobierania odpowiedniego obiektu Context.

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

Proces żądania aktywności przedstawiono na wykresie poniżej.

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 propozycja oferuje deweloperom kompleksowy zestaw narzędzi programistycznych do tworzenia, kompilowania i debugowania aplikacji i pakietów SDK na potrzeby funkcji RE. Aby zapewnić integralność tej propozycji, wprowadziliśmy pewne zmiany w sposobie konfigurowania, tworzenia i kompilowania aplikacji i pakietów SDK do gier.

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. W trakcie fazy tworzenia nasza propozycja wymaga od deweloperów wykonania kilku czynności.

Programiści aplikacji

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

• Nazwa: nazwa pakietu pakietu SDK lub biblioteki.
• Wersja główna: kod wersji głównej pakietu SDK.
• Podsumowanie certyfikatu: podsumowanie certyfikatu kompilacji pakietu SDK. W przypadku danej kompilacji zalecamy deweloperowi pakietu SDK uzyskanie i zarejestrowanie tej wartości w odpowiednim sklepie z aplikacjami.

Dotyczy to tylko pakietów SDK rozpowszechnianych w sklepach z aplikacjami, niezależnie od tego, czy są to pakiety RE. Aplikacje, które statycznie łączą pakiety SDK, będą używać obecnych mechanizmów zależności.

Aby ograniczyć wpływ na programistów, ważne jest, aby po określeniu docelowego poziomu interfejsu API obsługującego środowisko wykonawcze pakietu SDK deweloperzy aplikacji mieli tylko jedną wersję, która działa na urządzeniach obsługujących środowisko wykonawcze pakietu SDK lub nie.

Deweloperzy pakietów SDK

W proponowanym przez nas rozwiązaniu deweloperzy pakietów SDK RE muszą w manifeście wyraźnie zadeklarować nowy element reprezentujący pakiet SDK lub element biblioteki. Dodatkowo należy podać podobny zestaw wartości, jak w przypadku zależności, a także wersję podrzędną:

• Nazwa: nazwa pakietu pakietu SDK lub biblioteki.
• Wersja główna: kod wersji głównej pakietu SDK.
• Wersja pomocnicza: kod wersji pomocniczej pakietu SDK.

Jeśli deweloperzy pakietów SDK RE mają inne pakiety SDK RE jako zależności na etapie kompilacji, prawdopodobnie będą musieli zadeklarować je w taki sam sposób, w jaki deweloper aplikacji deklaruje te same zależności. Pakiety SDK RE zależne od innych pakietów SDK niebędących RE byłyby powiązane ze sobą statycznie. Może to spowodować problemy, które zostaną wykryte w momencie kompilacji lub podczas testów, jeśli pakiety SDK innych niż RE wymagają funkcji, których środowisko wykonawcze SDK nie obsługuje, lub jeśli muszą działać w ramach procesu aplikacji.

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

Kompilacje

Programiści aplikacji

Spodziewamy się, że deweloperzy aplikacji nie zauważą dużych zmian w kroku kompilacji. Zależności pakietu SDK, niezależnie od tego, czy są rozpowszechniane lokalnie, czy w sklepie z aplikacjami (z uwzględnieniem lub bez uwzględnienia RE), muszą być dostępne na komputerze, aby można było przeprowadzić linting, kompilację i tworzenie wersji. Proponujemy, aby Android Studio ukrywało te informacje przed deweloperem aplikacji podczas normalnego korzystania z aplikacji i aby było to jak najbardziej przejrzyste.

Chociaż oczekujemy, że kompilacja DEBUG powinna zawierać cały kod i symbole, aby umożliwić debugowanie, kompilacje RELEASE mogą opcjonalnie zawierać wszystkie pakiety SDK rozpowszechniane w sklepie z aplikacjami (z opcją RE lub bez niej), które zostały usunięte z pliku końcowego.

Jesteśmy na wczesnym etapie projektowania i udostępnimy więcej informacji, gdy tylko będziemy mogli.

Deweloperzy pakietów SDK

Pracujemy nad rozwiązaniem, które umożliwi tworzenie wersji niestandardowych i standardowych pakietu SDK w jednym pliku do dystrybucji. Dzięki temu deweloperzy aplikacji nie musieliby obsługiwać osobnych wersji pakietu SDK dla wersji z uwzględnieniem RE i bez uwzględnienia RE.

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

Testowanie

Programiści aplikacji

Zgodnie z naszą propozycją deweloperzy aplikacji mogliby testować swoje aplikacje na urządzeniach z Androidem 14 w zwykły sposób. Po skompilowaniu aplikacji można ją zainstalować na urządzeniu RE lub w emulatorze. Dzięki temu procesowi instalacji odpowiednie pakiety SDK zostaną zainstalowane w pakiecie SDK Runtime na urządzeniu lub w emulatorze, niezależnie od tego, czy zostały one pobrane z zdalnego repozytorium pakietu SDK, czy z pamięci podręcznej systemu kompilacji.

Deweloperzy pakietów SDK

Deweloperzy pakietów SDK zwykle testują swoje rozwiązania za pomocą własnych aplikacji testowych na urządzeniach i emulatorach. Nasza propozycja nie zmienia tego stanu rzeczy. Weryfikacja w aplikacji będzie przebiegać w taki sam sposób jak opisana powyżej dla deweloperów aplikacji. W przypadku zarówno aplikacji z usługami w tle, jak i bez nich będzie używany jeden artefakt kompilacji. Deweloperzy pakietów SDK będą mogli debugować swój kod niezależnie od tego, czy jest on w czasie wykonywania pakietu SDK, choć mogą wystąpić pewne ograniczenia w przypadku zaawansowanych narzędzi debugowania i profilowania. To jest aktywny 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ą oczywiste:

• Zadbaj 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 umożliwić dystrybucję pakietu SDK, sklep z aplikacjami musi zapewniać większość z tych funkcji:

• Mechanizm umożliwiający deweloperom pakietów SDK przesyłanie do sklepu pakietów SDK przeznaczonych do dystrybucji w sklepie, aktualizowanie ich, przywracanie do poprzedniej wersji i usuwanie.
• Mechanizm zapewniający integralność pakietu SDK i jego pochodzenia oraz aplikacji i jej pochodzenia oraz rozwiązujący ich zależności.
• mechanizm ich wdrażania na urządzenia w sposób niezawodny i wydajny;

Zmiany ograniczeń na przestrzeni czasu

Spodziewamy się, że ograniczenia dotyczące kodu w środowisku wykonawczym pakietu SDK będą się zmieniać wraz z nowszymi wersjami Androida. Aby zapewnić zgodność aplikacji, nie zmienimy tych ograniczeń w ramach aktualizacji głównego modułu dla danego poziomu pakietu SDK. Zachowanie związane z danym targetSdkVersion jest zachowane do czasu, gdy wsparcie dla tego targetSdkVersion zostanie wycofane zgodnie z zasadami sklepu z aplikacjami. Wycofanie targetSdkVersion może nastąpić w szybszym tempie 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.

Dodatkowo tworzymy mechanizm kanarków, który pozwoli testerom zewnętrznym i wewnętrznym dołączyć do grupy, w której obowiązuje proponowany zestaw ograniczeń dla następnej wersji Androida. Pomoże nam to uzyskać opinie i potwierdzić zaproponowane zmiany w zestawie ograniczeń.

Najczęstsze pytania

1. Co to jest pakiet SDK 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 do analizy, za pomocą których można tworzyć grupy użytkowników do dalszego kierowania, pakiety SDK do wyświetlania reklam, pakiety SDK do zapobiegania nadużyciom i do zwalczania oszustw w reklamach, pakiety SDK do zwiększania zaangażowania użytkowników oraz pakiety SDK do przypisywania.

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

   Chociaż początkowo skupiamy się na pakietach SDK związanych z reklamami, deweloperzy pakietów SDK niezwiązanych z reklamami, którzy chcą chronić prywatność użytkowników i wierzą, że ich pakiety mogą działać zgodnie z wymienionymi wyżej warunkami, mogą przesyłać opinie na temat swoich pakietów SDK działających w środowisku wykonawczym SDK. Środowisko wykonawcze SDK nie jest jednak zgodne ze wszystkimi wersjami pakietu SDK. Poza udokumentowanymi ograniczeniami środowisko wykonawcze SDK prawdopodobnie nie nadaje się do 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 Java?

   Obecnie środowisko uruchomieniowe oparte na Javie nie zapewnia łatwego dostępu do zabezpieczeń, które są niezbędne do zapewnienia użytkownikom Androida prywatności. Wdrożenie takiego rozwiązania wymagałoby prawdopodobnie wieloletniego wysiłku, a efekt nie byłby gwarantowany. Dlatego Piaskownica prywatności wykorzystuje granice procesu, czyli sprawdzoną i dobrze zrozumiałą technologię.

4. Czy przeniesienie pakietów SDK do procesu SDK Runtime pozwoli zaoszczędzić miejsce na pobranie lub na urządzeniu?

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

5. Do jakich zdarzeń z cyklu życia aplikacji, np. do zdarzeń związanych z przejściem aplikacji w tło, będą mieć dostęp pakiety SDK w środowisku wykonawczym SDK?

   Pracujemy nad zapewnieniem możliwości powiadamiania środowiska uruchomienia pakietu SDK o zdarzeniach cyklu życia aplikacji klienta na poziomie aplikacji (np. o przechodzeniu aplikacji na pierwszy plan lub tło). Projekt i przykładowy kod zostaną udostępnione w nadchodzącej wersji przedpremierowej dla programistów.