Quiz: podstawy środowiska wykonawczego SDK

Środowisko wykonawcze SDK ma zapewnić kilka kluczowych korzyści dla ekosystemu Androida. Które z tych korzyści są najbardziej istotne dla deweloperów aplikacji i pakietów SDK oraz użytkowników?

Wybierz tyle odpowiedzi, ile uważasz za stosowne.

Zwiększona prywatność użytkowników i bezpieczeństwo aplikacji dzięki oddzieleniu kodu i zasobów pakietu SDK firmy zewnętrznej w ramach oddzielnego, ograniczonego procesu uruchomienia.

Zwiększona stabilność aplikacji i dokładniejsze określanie przyczyn awarii dzięki ograniczeniu operacji pakietu SDK do własnego procesu, oddzielnego od aplikacji hosta.

Udostępnianie zewnętrznym pakietom SDK zwiększonego, bezpośredniego dostępu do pełnego zestawu uprawnień aplikacji hosta w celu zmaksymalizowania ich funkcjonalności.

bardziej elastyczny model dystrybucji pakietów SDK, który umożliwia aktualizowanie pakietów SDK niezależnie od wersji aplikacji za pomocą kanałów dystrybucji aplikacji, co może przyspieszyć wprowadzanie krytycznych poprawek;

Wymaganie, aby wszystkie zewnętrzne pakiety SDK korzystały z jednego, wspólnego środowiska uruchomieniowego we wszystkich aplikacjach na urządzeniu, co pozwala zoptymalizować wykorzystanie zasobów systemowych.

Które stwierdzenie prawidłowo opisuje pakiet SDK używany w czasie działania (RE SDK)?

Działa w ramach procesu aplikacji i komunikuje się bezpośrednio z innymi pakietami SDK w aplikacji.

Jest to przede wszystkim warstwa tłumaczenia, która pomaga aplikacjom przejść na korzystanie z pakietów SDK w środowisku wykonawczym SDK.

Działa on w odizolowanym procesie środowiska wykonawczego pakietu SDK.

Służy tylko do debugowania funkcji pakietu SDK w Android Studio.

Które z tych stwierdzeń najlepiej opisuje sposób udostępniania pakietów SDK z wbudowanym środowiskiem wykonawczym (RE SDK) aplikacjom i instalowania ich na urządzeniach użytkowników w ramach nowego paradygmatu dystrybucji?

Pakiety SDK RE są zawsze kompilowane bezpośrednio w pliku APK aplikacji hosta, podobnie jak tradycyjne pakiety SDK, ale są aktywowane tylko wtedy, gdy jest obecny środowisko uruchomieniowe SDK.

Pakiety SDK do gier na żądanie można publikować w sklepach z aplikacjami jako osobne elementy. Sklep z aplikacjami zarządza ich instalacją na urządzeniu, a każda aplikacja wczytuje wymagane pakiety SDK RE do własnego prywatnego procesu działania pakietu SDK.

Wszystkie niezbędne pakiety SDK do reklamowania w wyszukiwarce są wstępnie zainstalowane w ramach systemu operacyjnego Androida, a aplikacje deklarują, których z nich chcą używać.

Aplikacje pobierają pakiety SDK RE bezpośrednio z serwerów dostawcy pakietu SDK za każdym razem, gdy są potrzebne, dzięki czemu zawsze jest używana najnowsza wersja bez udziału sklepu z aplikacjami.

Środowisko wykonawcze SDK zasadniczo zmienia integrację pakietu SDK, ponieważ uruchamia zewnętrzne pakiety SDK w ramach osobnego procesu. W jaki sposób ta izolacja procesów rozwiązuje kluczowy problem związany z tradycyjnym, ściśle powiązanym modelem pakietu SDK?

Dzięki temu RE SDK zużywa znacznie mniej energii, ponieważ przekierowuje wszystkie zadania na wątek systemowy o niskim priorytecie.

Umożliwia to pakietom SDK RE korzystanie z podwyższonych uprawnień systemowych, co pozwala na wykonywanie zaawansowanych operacji bez korzystania z modelu uprawnień aplikacji.

Tworzy wyraźne granice, ograniczając bezpośredni dostęp pakietu SDK do wewnętrznych danych i zasobów aplikacji hosta, co zmniejsza ryzyko związane z nieujawnionym gromadzeniem danych i zwiększa ogólne bezpieczeństwo.

Standardyzuje komponenty interfejsu użytkownika, których muszą używać wszystkie pakiety SDK RE, zapewniając spójny wygląd i działanie we wszystkich aplikacjach, które je wykorzystują.

Jakie jest główne przeznaczenie narzędzi do generowania „przekładki” w kontekście środowiska uruchomieniowego SDK?

Pakowanie pakietów SDK używanych w czasie działania w pakiety Android SDK (ASB).

Aby podczas kompilacji stosować ograniczenia uprawnień w pakietach SDK z włączonym środowiskiem wykonawczym.

Aby uprościć złożoność komunikacji między procesami na niskim poziomie (IPC) między aplikacją/pakietem SDK z uwzględnieniem środowiska uruchomieniowego (RA SDK) a pakietem SDK z uwzględnieniem środowiska uruchomieniowego (RE SDK).

Aby udostępnić gotowe komponenty interfejsu dla pakietów SDK RE do wyświetlania reklam.

Podczas tworzenia pakietu SDK RE deweloper pakietu SDK musi zaimplementować co, aby zdefiniować punkt wejścia pakietu SDK, który zwykle rozszerza klasę wygenerowaną przez shim?

Aktywność uruchamiająca główne funkcje pakietu SDK.

Klasa rozszerzająca interfejs SandboxedSdkProviderCompat (lub pochodna generowana przez shim na podstawie interfejsu@PrivacySandboxService) i zastępująca metodę create*.

BroadcastReceiver, który nasłuchuje żądań wczytania pakietu SDK z aplikacji.

ContentProvider do udostępniania aplikacji początkowych danych konfiguracyjnych.

Podczas debugowania pakietu SDK RE na urządzeniu lub emulatorze, na którym aktywny jest środowisko uruchomieniowe SDK, do którego procesu należy dołączyć debuger, aby sprawdzić kod pakietu SDK RE?

Główny proces aplikacji klienckiej.

Proces „system_server”.

Proces „_sdk_sandbox”.

wewnętrzny proces debugowania w Android Studio;

Jaki jest zwykle pierwszy etap zalecanej migracji z obecnego pakietu SDK do środowiska wykonawczego pakietu SDK?

Wymagaj, aby wszystkie aplikacje od razu korzystały z pakietu SDK z uruchomieniem w czasie działania bezpośrednio, bez żadnej warstwy tłumaczenia.

Utwórz smukły pakiet SDK z obsługą w czasie wykonywania, zachowując całą dotychczasową logikę biznesową w starszym pakiecie SDK w aplikacji.

Utwórz pakiet SDK używanych w czasie działania w okresie przejściowym obok grubego pakietu SDK Aware Runtime do stopniowej migracji i testów A/B.

wycofać dotychczasowy pakiet SDK i od razu oferować nowy pakiet SDK z włączonym środowiskiem wykonawczym.