Quiz sur les principes fondamentaux du SDK Runtime

L'environnement d'exécution du SDK vise à offrir plusieurs avantages clés à l'écosystème Android. Parmi les propositions suivantes, lesquelles sont des avantages principaux mis en avant pour les développeurs d'applications et de SDK, ainsi que pour les utilisateurs ?

Choisissez autant de réponses que vous jugez nécessaires.

Amélioration de la confidentialité des utilisateurs et de la sécurité des applications grâce à l'isolement du code et des ressources des SDK tiers dans un processus d'exécution distinct et restreint.

Amélioration de la stabilité de l'application et responsabilité plus précise des plantages en contenant les opérations du SDK dans leur propre processus dédié, distinct de l'application hôte.

Accorder aux SDK tiers un accès direct accru à l'ensemble des autorisations de l'application hôte pour maximiser leurs fonctionnalités.

Un modèle de distribution de SDK plus flexible, qui permet de mettre à jour les SDK indépendamment des versions d'applications via les canaux de distribution d'applications, ce qui peut accélérer la résolution des problèmes critiques.

Obligation pour tous les SDK tiers d'utiliser un seul environnement d'exécution partagé pour toutes les applications d'un appareil afin d'optimiser l'utilisation des ressources système.

Quelle affirmation décrit correctement un SDK compatible avec l'environnement d'exécution ?

Il s'exécute dans le processus de l'application et communique directement avec les autres SDK intégrés à l'application.

Il s'agit principalement d'une couche de traduction qui aide les applications à passer à l'utilisation de SDK dans le SDK Runtime.

Il s'exécute dans le processus SDK Runtime isolé.

Il n'est utilisé que pour déboguer les fonctionnalités du SDK dans Android Studio.

Compte tenu du nouveau paradigme de distribution des SDK compatibles avec l'environnement d'exécution, quelle affirmation décrit le mieux la façon dont les SDK compatibles avec l'environnement d'exécution sont mis à la disposition des applications et installés sur les appareils des utilisateurs ?

Les SDK compatibles avec l'environnement d'exécution sont toujours compilés directement dans l'APK de l'application hôte, comme les SDK traditionnels, mais ne sont activés que lorsque le SDK Runtime est présent.

Les SDK RE peuvent être publiés sur les plates-formes de téléchargement d'applications en tant qu'entités distinctes. La plate-forme de téléchargement d'applications gère ensuite leur installation sur l'appareil, et chaque application charge les SDK compatibles avec l'environnement d'exécution requis dans son propre processus SDK Runtime privé.

Tous les SDK RE nécessaires sont préinstallés dans le système d'exploitation Android, et les applications déclarent simplement ceux qu'elles prévoient d'utiliser.

Les applications téléchargent les SDK RE directement à partir des serveurs du fournisseur de SDK chaque fois qu'ils sont nécessaires, ce qui garantit que la dernière version est toujours utilisée sans l'intervention de la plate-forme de téléchargement d'applications.

SDK Runtime modifie fondamentalement l'intégration des SDK en exécutant les SDK tiers dans un processus distinct. En quoi cette isolation de processus répond-elle principalement à un défi clé du modèle de SDK traditionnel, étroitement couplé ?

Il garantit que les SDK RE consomment beaucoup moins d'énergie de la batterie en déchargeant toutes leurs tâches sur un thread système à faible priorité.

Il permet aux SDK RE de fonctionner avec des droits système élevés, en contournant le modèle d'autorisations de l'application pour effectuer des opérations avancées.

Il crée des limites claires, limitant l'accès direct d'un SDK aux données et ressources internes de l'application hôte, réduisant ainsi les risques associés à la collecte de données non divulguées et améliorant la sécurité globale.

Il standardise les composants d'interface utilisateur que tous les SDK RE doivent utiliser, ce qui garantit une apparence cohérente dans toutes les applications qui les utilisent.

Quel est l'objectif principal des outils de génération de "shim" dans le contexte du SDK Runtime ?

Pour empaqueter les SDK compatibles avec l'environnement d'exécution dans des Android SDK Bundle (ASB).

Pour appliquer des restrictions d'autorisation aux SDK compatibles avec l'environnement d'exécution lors de la compilation.

Pour éliminer la complexité de la communication inter-processus (IPC) de bas niveau entre l'application/le SDK RA (Runtime Aware) et le SDK RE.

Fournir des composants d'interface utilisateur prédéfinis pour que les SDK RE puissent diffuser des annonces.

Lors de la création d'un SDK RE, que doit implémenter le développeur du SDK pour définir le point d'entrée du SDK, qui étend généralement une classe générée par un shim ?

Activité qui lance les principales fonctionnalités du SDK.

Classe étendant SandboxedSdkProviderCompat (ou un dérivé généré par un shim basé sur@PrivacySandboxService) et remplaçant sa méthode create*.

BroadcastReceiver qui écoute les requêtes de chargement du SDK à partir de l'application.

Un ContentProvider pour partager les données de configuration initiales avec l'application.

Lorsque vous déboguez un SDK RE sur un appareil ou dans un émulateur où SDK Runtime est actif, à quel processus le débogueur doit-il être associé pour inspecter le code du SDK RE ?

Processus principal de l'application cliente.

Processus "system_server".

Le processus _sdk_sandbox.

Processus de débogage interne d'Android Studio.

Selon les phases de migration recommandées pour un SDK existant vers le SDK Runtime, quelle est généralement la première étape ?

Exigez immédiatement que toutes les applications utilisent le SDK compatible avec l'environnement d'exécution directement, sans couche de traduction.

Créez un SDK Runtime compatible avec toute la logique métier existante qui reste dans un ancien SDK intégré à l'application.

Créez un SDK compatible avec l'environnement d'exécution pendant la période de transition, ainsi qu'un SDK compatible avec l'environnement d'exécution pour la migration incrémentielle et les tests A/B.

Abandonner le SDK existant et n'offrir que le nouveau SDK compatible avec l'environnement d'exécution dès le départ.