Les clients FCM nécessitent des appareils équipés d'Android 5.0 ou version ultérieure sur lesquels l'application Google Play Store est également installée, ou un émulateur exécutant Android 5.0 avec les API Google. Notez que vous n'êtes pas limité au déploiement de vos applications Android via le Google Play Store.
Configurez le SDK
Cette section décrit les tâches que vous avez peut-être effectuées si vous avez déjà activé d'autres fonctionnalités Firebase pour votre application. Si ce n'est pas encore fait, ajoutez Firebase à votre projet Android.
Modifier le fichier manifeste de votre application
Ajoutez les éléments suivants au fichier manifeste de votre application:
- Un service qui étend
FirebaseMessagingService
. Cela est nécessaire si vous souhaitez gérer les messages au-delà de la réception de notifications sur les applications en arrière-plan. Pour recevoir des notifications dans les applications de premier plan, pour recevoir la charge utile de données, pour envoyer des messages en amont, etc., vous devez étendre ce service. - (Facultatif) Dans le composant de l'application, éléments de métadonnées permettant de définir une icône et une couleur de notification par défaut. Android utilise ces valeurs chaque fois que l'icône ou la couleur des messages entrants ne sont pas définies explicitement.
- (Facultatif) À partir d'Android 8.0 (niveau d'API 26) ou version ultérieure, les
canaux de notification sont compatibles et recommandés. FCM fournit un canal de notification par défaut avec des paramètres de base. Si vous préférez créer et utiliser votre propre canal par défaut, définissez
default_notification_channel_id
sur l'ID de votre objet de canal de notification, comme illustré. FCM utilisera cette valeur chaque fois que les messages entrants ne définiront pas explicitement de canal de notification. Pour en savoir plus, consultez la section Gérer les canaux de notification.
<service android:name=".java.MyFirebaseMessagingService" android:exported="false"> <intent-filter> <action android:name="com.google.firebase.MESSAGING_EVENT" /> </intent-filter> </service>
<!-- Set custom default icon. This is used when no icon is set for incoming notification messages. See README(https://goo.gl/l4GJaQ) for more. --> <meta-data android:name="com.google.firebase.messaging.default_notification_icon" android:resource="@drawable/ic_stat_ic_notification" /> <!-- Set color used with incoming notification messages. This is used when no color is set for the incoming notification message. See README(https://goo.gl/6BKBk7) for more. --> <meta-data android:name="com.google.firebase.messaging.default_notification_color" android:resource="@color/colorAccent" />
<meta-data android:name="com.google.firebase.messaging.default_notification_channel_id" android:value="@string/default_notification_channel_id" />
Demander une autorisation de notification d'exécution sur Android 13 ou version ultérieure
Android 13 introduit une nouvelle autorisation d'exécution pour afficher les notifications. Cela affecte toutes les applications exécutées sur Android 13 ou version ultérieure qui utilisent des notifications FCM.
Par défaut, le SDK FCM (version 23.0.6 ou ultérieure) inclut l'autorisation POST_NOTIFICATIONS
définie dans le fichier manifeste.
Toutefois, votre application doit également demander la version d'exécution de cette autorisation via la constante android.permission.POST_NOTIFICATIONS
.
Votre application ne pourra pas afficher de notifications tant que l'utilisateur n'aura pas accordé cette autorisation.
Pour demander la nouvelle autorisation d'exécution:
Kotlin+KTX
// Declare the launcher at the top of your Activity/Fragment: private val requestPermissionLauncher = registerForActivityResult( ActivityResultContracts.RequestPermission(), ) { isGranted: Boolean -> if (isGranted) { // FCM SDK (and your app) can post notifications. } else { // TODO: Inform user that that your app will not show notifications. } } private fun askNotificationPermission() { // This is only necessary for API level >= 33 (TIRAMISU) if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) { if (ContextCompat.checkSelfPermission(this, Manifest.permission.POST_NOTIFICATIONS) == PackageManager.PERMISSION_GRANTED ) { // FCM SDK (and your app) can post notifications. } else if (shouldShowRequestPermissionRationale(Manifest.permission.POST_NOTIFICATIONS)) { // TODO: display an educational UI explaining to the user the features that will be enabled // by them granting the POST_NOTIFICATION permission. This UI should provide the user // "OK" and "No thanks" buttons. If the user selects "OK," directly request the permission. // If the user selects "No thanks," allow the user to continue without notifications. } else { // Directly ask for the permission requestPermissionLauncher.launch(Manifest.permission.POST_NOTIFICATIONS) } } }
Java
// Declare the launcher at the top of your Activity/Fragment: private final ActivityResultLauncher<String> requestPermissionLauncher = registerForActivityResult(new ActivityResultContracts.RequestPermission(), isGranted -> { if (isGranted) { // FCM SDK (and your app) can post notifications. } else { // TODO: Inform user that that your app will not show notifications. } }); private void askNotificationPermission() { // This is only necessary for API level >= 33 (TIRAMISU) if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) { if (ContextCompat.checkSelfPermission(this, Manifest.permission.POST_NOTIFICATIONS) == PackageManager.PERMISSION_GRANTED) { // FCM SDK (and your app) can post notifications. } else if (shouldShowRequestPermissionRationale(Manifest.permission.POST_NOTIFICATIONS)) { // TODO: display an educational UI explaining to the user the features that will be enabled // by them granting the POST_NOTIFICATION permission. This UI should provide the user // "OK" and "No thanks" buttons. If the user selects "OK," directly request the permission. // If the user selects "No thanks," allow the user to continue without notifications. } else { // Directly ask for the permission requestPermissionLauncher.launch(Manifest.permission.POST_NOTIFICATIONS); } } }
En règle générale, vous devez afficher une UI expliquant à l'utilisateur les fonctionnalités qui seront activées s'il accorde des autorisations à l'application pour qu'elle publie des notifications. Cette interface utilisateur doit proposer à l'utilisateur les options d'acceptation ou de refus, telles que les boutons OK et Non, merci. Si l'utilisateur sélectionne OK, demandez directement l'autorisation. Si l'utilisateur sélectionne Non, merci, autorisez-le à continuer sans notifications.
Consultez la section Autorisation d'exécution des notifications pour découvrir d'autres bonnes pratiques sur le moment où votre application doit demander l'autorisation POST_NOTIFICATIONS
à l'utilisateur.
Autorisations de notification pour les applications ciblant Android 12L (niveau d'API 32) ou version antérieure
Android demande automatiquement l'autorisation à l'utilisateur la première fois que votre application crée un canal de notification, à condition qu'elle soit au premier plan. Cependant, il existe des mises en garde importantes concernant le moment où les chaînes créent un canal et les demandes d'autorisation:
- Si votre application crée son premier canal de notification lorsqu'elle s'exécute en arrière-plan (ce que fait le SDK FCM lorsqu'il reçoit une notification FCM), Android n'autorise pas l'affichage de la notification et n'invite pas l'utilisateur à autoriser les notifications avant la prochaine ouverture de votre application. Cela signifie que toutes les notifications reçues avant l'ouverture de votre application et l'acceptation de l'utilisateur seront perdues.
- Nous vous recommandons vivement de mettre à jour votre application afin qu'elle cible Android 13 ou version ultérieure afin de bénéficier des API de la plate-forme pour demander des autorisations. Si ce n'est pas possible, votre application doit créer des canaux de notification avant d'envoyer des notifications à l'application afin de déclencher la boîte de dialogue d'autorisation de notification et de s'assurer qu'aucune notification n'est perdue. Pour en savoir plus, consultez les bonnes pratiques concernant les autorisations de notification.
Facultatif : supprimer l'autorisation POST_NOTIFICATIONS
Par défaut, le SDK FCM inclut l'autorisation POST_NOTIFICATIONS
.
Si votre application n'utilise pas de messages de notification (que ce soit via des notifications FCM, via un autre SDK ou directement publiés par votre application) et que vous ne souhaitez pas qu'elle inclue l'autorisation, vous pouvez la supprimer à l'aide du repère remove
de la fusion de fichiers manifestes. N'oubliez pas que la suppression de cette autorisation empêche l'affichage de toutes les notifications, et pas seulement des notifications FCM. Ajoutez ce qui suit au fichier manifeste de votre application:
<uses-permission android:name="android.permission.POST_NOTIFICATIONS" tools:node="remove"/>
Accéder au jeton d'enregistrement de l'appareil
Au démarrage initial de votre application, le SDK FCM génère un jeton d'enregistrement pour l'instance de l'application cliente. Si vous souhaitez cibler des appareils uniques ou créer des groupes d'appareils, vous devez accéder à ce jeton en étendant
FirebaseMessagingService
et en remplaçant onNewToken
.
Cette section explique comment récupérer le jeton et comment surveiller les modifications apportées au jeton. Étant donné que le jeton peut être alterné après le démarrage initial, il est vivement recommandé de récupérer le dernier jeton d'enregistrement mis à jour.
Le jeton d'enregistrement peut changer dans les cas suivants:
- L'appli est restaurée sur un nouvel appareil
- L'utilisateur désinstalle/réinstalle l'application.
- L'utilisateur efface les données de l'application.
Récupérer le jeton d'enregistrement actuel
Lorsque vous devez récupérer le jeton actuel, appelez
FirebaseMessaging.getInstance().getToken()
:
Kotlin+KTX
FirebaseMessaging.getInstance().token.addOnCompleteListener(OnCompleteListener { task -> if (!task.isSuccessful) { Log.w(TAG, "Fetching FCM registration token failed", task.exception) return@OnCompleteListener } // Get new FCM registration token val token = task.result // Log and toast val msg = getString(R.string.msg_token_fmt, token) Log.d(TAG, msg) Toast.makeText(baseContext, msg, Toast.LENGTH_SHORT).show() })
Java
FirebaseMessaging.getInstance().getToken() .addOnCompleteListener(new OnCompleteListener<String>() { @Override public void onComplete(@NonNull Task<String> task) { if (!task.isSuccessful()) { Log.w(TAG, "Fetching FCM registration token failed", task.getException()); return; } // Get new FCM registration token String token = task.getResult(); // Log and toast String msg = getString(R.string.msg_token_fmt, token); Log.d(TAG, msg); Toast.makeText(MainActivity.this, msg, Toast.LENGTH_SHORT).show(); } });
Surveiller la génération de jetons
Le rappel onNewToken
se déclenche chaque fois qu'un nouveau jeton est généré.
Kotlin+KTX
/** * Called if the FCM registration token is updated. This may occur if the security of * the previous token had been compromised. Note that this is called when the * FCM registration token is initially generated so this is where you would retrieve the token. */ override fun onNewToken(token: String) { Log.d(TAG, "Refreshed token: $token") // If you want to send messages to this application instance or // manage this apps subscriptions on the server side, send the // FCM registration token to your app server. sendRegistrationToServer(token) }
Java
/** * There are two scenarios when onNewToken is called: * 1) When a new token is generated on initial app startup * 2) Whenever an existing token is changed * Under #2, there are three scenarios when the existing token is changed: * A) App is restored to a new device * B) User uninstalls/reinstalls the app * C) User clears app data */ @Override public void onNewToken(@NonNull String token) { Log.d(TAG, "Refreshed token: " + token); // If you want to send messages to this application instance or // manage this apps subscriptions on the server side, send the // FCM registration token to your app server. sendRegistrationToServer(token); }
Une fois le jeton obtenu, vous pouvez l'envoyer à votre serveur d'applications et le stocker à l'aide de votre méthode préférée.
Vérifier la présence des services Google Play
Les applications qui reposent sur le SDK Play Services doivent toujours vérifier la présence d'un APK des services Google Play compatible sur l'appareil avant d'accéder aux fonctionnalités des services Google Play. Nous vous recommandons de le faire à deux endroits: dans la méthode onCreate()
de l'activité principale et dans sa méthode onResume()
. La vérification dans onCreate()
garantit que l'application ne peut pas être utilisée sans une vérification réussie. La vérification dans onResume()
garantit que si l'utilisateur revient à l'application en cours d'exécution par un autre moyen, par exemple via le bouton "Retour", la vérification est toujours effectuée.
Si l'appareil ne dispose pas d'une version compatible des services Google Play, votre application peut appeler GoogleApiAvailability.makeGooglePlayServicesAvailable()
pour permettre aux utilisateurs de télécharger les services Google Play depuis le Play Store.
Empêcher l'initialisation automatique
Lorsqu'un jeton d'enregistrement FCM est généré, la bibliothèque importe l'identifiant et les données de configuration dans Firebase. Si vous préférez empêcher la génération automatique de jetons, désactivez la collecte Analytics et l'initialisation automatique de FCM (vous devez désactiver les deux) en ajoutant ces valeurs de métadonnées à votre AndroidManifest.xml
:
<meta-data android:name="firebase_messaging_auto_init_enabled" android:value="false" /> <meta-data android:name="firebase_analytics_collection_enabled" android:value="false" />
Pour réactiver l'initialisation automatique de FCM, effectuez un appel d'exécution :
Kotlin+KTX
Firebase.messaging.isAutoInitEnabled = true
Java
FirebaseMessaging.getInstance().setAutoInitEnabled(true);
Pour réactiver la collecte Analytics, appelez la méthode setAnalyticsCollectionEnabled()
de la classe FirebaseAnalytics
. Exemple :
setAnalyticsCollectionEnabled(true);
Une fois définies, ces valeurs sont conservées lors des redémarrages de l'application.
Étapes suivantes
Une fois l'application cliente configurée, vous pouvez commencer à envoyer des messages en aval avec l' outil de création de notifications. Cette fonctionnalité est illustrée dans l'exemple de démarrage rapide, que vous pouvez télécharger, exécuter et consulter.
Pour ajouter un autre comportement plus avancé à votre application, vous pouvez déclarer un filtre d'intent et implémenter une activité pour répondre aux messages entrants. Pour en savoir plus, consultez les guides sur l'envoi de messages depuis un serveur d'application:
N'oubliez pas que pour profiter de ces fonctionnalités, vous avez besoin d'une implémentation de serveur et des protocoles de serveur (HTTP ou XMPP), ou d'une implémentation du SDK administrateur.