La traduction de l'article a été préparée spécialement pour les étudiants du cours "développeur Android". Cours de base . " Nous vous rappelons également que nous continuons de nous inscrire au cours avancé "Spécialisation Android-développeur"
Nous sommes dans la 10e année de développement Android (Android Q doit être la version 10.0). Selon Beta 4, Android Q a officiellement une
API de niveau 29 . Bien que la
Bêta 5 existe déjà et que la Bêta 6 soit attendue, l'API a été marquée comme finale, et il est maintenant temps de voir comment Android Q affectera les applications et quels changements doivent être apportés pour prendre pleinement en charge Android Q.
Les changements importants (pas tous) présentés dans Android Q peuvent être divisés en deux catégories: a)
confidentialité et sécurité , b)
expérience utilisateur .
Du traducteur: «Nous avons divisé la traduction en deux parties correspondant à ces catégories. En conséquence, dans la première partie, nous parlerons de confidentialité et de sécurité. "1) Confidentialité et sécurité
a) Démarrage des activités de base
Vous ne pouvez plus démarrer une activité lorsque votre application est en arrière-plan.
- Ce qui affecte: toutes les applications exécutées sur Q (quel que soit le SDK cible). Une exception est levée si Android Q est la version cible de l'application; et l'activité ne démarre tout simplement pas si Android Q n'est pas le SDK cible pour l'application, mais il fonctionne sur un appareil avec Android Q.
- Exceptions: services liés, tels que l'accessibilité, la saisie semi-automatique, etc. Si l'application reçoit un
PendingIntent du système, nous pouvons l'utiliser pour démarrer l'activité. Si l'application dispose de l'autorisation SYSTEM_ALERT_WINDOW (supprimée dans Android GO) ou de l'application récemment appelée finish() pour Activity (il n'est pas recommandé de s'y fier. «Récemment» peut être très ambigu), alors votre application est exempte de cette restriction. - Approche recommandée: activité de déclenchement de notification
val fullScreenIntent = Intent(this, CallActivity::class.java) val fullScreenPendingIntent = PendingIntent.getActivity(this, 0, fullScreenIntent, PendingIntent.FLAG_UPDATE_CURRENT) val notificationBuilder = NotificationCompat.Builder(this, CHANNEL_ID) .... .setPriority(NotificationCompat.PRIORITY_HIGH) .setCategory(NotificationCompat.CATEGORY_CALL) .setFullScreenIntent(fullScreenPendingIntent, true)
Ajoutez le
Fullscreen PendingIntent à la notification. Maintenant que la notification a fonctionné, le système lancera une intention plein écran.
Par conséquent, si nous voulons démarrer Activity à l'arrière-plan, créez d'abord une notification qui sera affichée à l'utilisateur. Dans cette notification, ajoutez
Fullscreen PendingIntent . Ajoutez également l'autorisation
USE_FULL_SCREEN_INTENT à votre manifeste. Maintenant que la notification a fonctionné, le système lancera une intention plein écran.
- Pièges: le système décide quand afficher une notification et quand afficher une activité. Si l'utilisateur utilise activement l'appareil, une notification contextuelle s'affiche. Si l'appareil est au repos ou lorsque l'utilisateur interagit avec la notification, l'activité en plein écran démarre. Par exemple, comme lors de la réception d'un appel téléphonique (notifications contextuelles lors de l'utilisation du téléphone, sinon activité plein écran).
b) Identifiants matériels
L'accès aux identifiants d'appareil non réinitialisables a été révoqué dans Android Q.
- Ce qui affecte: toutes les applications exécutées sur Q (quel que soit le SDK cible). Une exception est levée si Q est le SDK cible; et renvoie
null si le SDK cible est inférieur à Q - À éviter: l' adresse Mac est désormais aléatoire et l'IMEI (
TelephonyManager.getDeviceId() ) et le numéro de série ne sont plus disponibles. Ce sont désormais des «autorisations privilégiées» et ne sont disponibles que pour les applications opérateur. - Approche recommandée: utilisez des identifiants réinitialisables tels que Advertising ID, Instance ID ou Globally-unique ID (GUID). Voir Meilleures pratiques pour les identifiants uniques pour plus d'informations sur l'identifiant à utiliser dans quel cas.
c) Définition d'arrière-plan de l'emplacement
À partir d'Android Q, le système fera la distinction entre les demandes de localisation effectuées au premier plan et en arrière-plan.
La demande d'autorisation d'accès à l'emplacement aura désormais 3 options: Autoriser tout le temps, Autoriser uniquement lors de l'utilisation de l'application (accès uniquement au premier plan) et Refuser (pas d'accès).
- Effets: cela dépend du SDK cible. Si Q est le SDK cible de l'application, vous devez demander une nouvelle autorisation d'emplacement en arrière-plan. Si l'application a un SDK cible différent, elle recevra automatiquement cette autorisation si elle avait déjà des droits d'accès à l'emplacement.
Image prise à partir de la documentation du développeur Android- Approche recommandée: si l'application nécessite un accès unique à l'emplacement de l'utilisateur pour effectuer certaines tâches, utilisez le service de premier plan avec le paramètre foregroundServiceType spécifié comme
location dans le fichier manifeste de l'application.
<service android:name="MyNavigationService" android:foregroundServiceType="location" ... />
Si l'application a besoin d'un accès constant à l'emplacement de l'appareil, par exemple pour la clôture géographique, elle peut configurer une demande pour autoriser l'accès à l'emplacement en arrière-plan. Il n'est pas nécessaire de modifier d'autres aspects de l'application (par exemple, la façon dont l'emplacement est extrait et utilisé). Pour demander l'accès à un emplacement en arrière-plan, ajoutez l'autorisation
ACCESS_BACKGROUND_LOCATION au manifeste:
<manifest> <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" /> </manifest>
Demander l'accès à l'emplacement en arrière-plan
Rappel affiché par le système sur l'accès à un emplacement en arrière-planQuelques points importants à garder à l'esprit: l'utilisateur peut être rappelé après avoir donné à l'application l'accès à l'emplacement de l'appareil en arrière-plan, et, comme toute autre autorisation, l'utilisateur peut révoquer l'autorisation pour cela. Cela est particulièrement important pour les applications où Q n'est pas un SDK cible, mais qui s'exécute sur des appareils avec Android Q, car il obtiendrait la résolution d'arrière-plan par défaut s'il avait l'autorisation de localisation. Assurez-vous que votre application gère ces scripts avec élégance. Pour cette raison, chaque fois qu'une application démarre un service ou demande un emplacement, vérifiez si l'utilisateur autorise toujours l'application à accéder aux informations de localisation.
À ce sujet, la première partie de l'article s'est terminée et, comme promis, nous parlerons des expériences utilisateur dans la
deuxième partie .