Créer une application de téléphone par défaut

Une application de téléphone par défaut permet au framework Android Telecom d'informer votre application de l'état d'appel à l'aide du gestionnaire de rôles et du service d'appel afin de créer un remplacement de l'application pour téléphone par défaut sur un appareil Android. Implémentez l'API InCallService. Votre implémentation doit répondre aux exigences suivantes:

Elle ne doit pas comporter de capacité d'appel et doit se composer uniquement de l'interface utilisateur permettant d'effectuer des appels. Il doit gérer tous les appels dont le framework de télécommunications a connaissance, et ne pas émettre de suppositions sur la nature de ces appels. Par exemple, il ne doit pas partir du principe que les appels sont des appels de téléphonie basés sur une carte SIM, ni implémenter des restrictions d'appel basées sur un service ConnectionService, comme l'application de restrictions en matière de téléphonie pour les appels vidéo.

Une application d'appel permet aux utilisateurs de recevoir ou de passer des appels audio ou vidéo sur leur appareil. Les applications d'appel utilisent leur propre interface utilisateur pour les appels au lieu de l'interface par défaut de l'application Téléphone, comme illustré dans la capture d'écran suivante.

Exemple d'application d'appel
Exemple d'application appelante utilisant sa propre interface utilisateur

Le framework Android inclut le package android.telecom, qui contient des classes qui vous aident à créer une application appelante en fonction du framework de télécommunications. Concevoir votre application conformément au framework pour les télécommunications offre les avantages suivants:

  • Votre application interagit correctement avec le sous-système de télécommunications natif de l'appareil.
  • Votre application interagit correctement avec d'autres applications appelantes qui respectent également le framework.
  • Le framework aide votre application à gérer le routage audio et vidéo.
  • Le framework aide votre application à déterminer si ses appels sont ciblés.

Déclarations et autorisations relatives au fichier manifeste

Dans le fichier manifeste de votre application, déclarez que celle-ci utilise l'autorisation MANAGE_OWN_CALLS, comme indiqué dans l'exemple suivant:

<manifest … >
    <uses-permission android:name="android.permission.MANAGE_OWN_CALLS"/>
</manifest>

Pour en savoir plus sur la déclaration d'autorisations d'application, consultez la section Autorisations.

Vous devez déclarer un service qui spécifie la classe qui implémente la classe ConnectionService dans votre application. Le sous-système de télécommunications exige que le service déclare l'autorisation BIND_TELECOM_CONNECTION_SERVICE pour pouvoir s'y associer. L'exemple suivant montre comment déclarer le service dans le fichier manifeste de votre application:

<service android:name="com.example.MyConnectionService"
    android:permission="android.permission.BIND_TELECOM_CONNECTION_SERVICE">
    <intent-filter>
        <action android:name="android.telecom.ConnectionService" />
    </intent-filter>
</service>

Pour en savoir plus sur la déclaration de composants d'application, y compris les services, consultez la section Composants d'application.

Implémenter le service de connexion

Votre application appelante doit fournir une implémentation de la classe ConnectionService à laquelle le sous-système de télécommunications peut être lié. Votre implémentation de ConnectionService doit remplacer les méthodes suivantes:

onCreateOutgoingConnection(PhoneAccountHandle, ConnectionRequest)

Le sous-système de télécommunications appelle cette méthode en réponse à l'appel de placeCall(Uri, Bundle) par votre application pour créer un appel sortant. Votre application renvoie une nouvelle instance de l'implémentation de votre classe Connection (pour en savoir plus, consultez Implémenter la connexion) pour représenter le nouvel appel sortant. Vous pouvez personnaliser davantage la connexion sortante en effectuant les actions suivantes:

onCreateOutgoingConnectionFailed(PhoneAccountHandle, ConnectionRequest)

Le sous-système de télécommunications appelle cette méthode lorsque votre application appelle la méthode placeCall(Uri, Bundle) et que l'appel sortant ne peut pas être passé. Dans ce cas, votre application doit informer l'utilisateur (par exemple, à l'aide d'une zone d'alerte ou d'un toast) que l'appel sortant n'a pas pu être passé. Il est possible que votre application ne puisse pas passer d'appel si un appel d'urgence est en cours ou si un appel en cours dans une autre application ne peut pas être mis en attente avant de passer votre appel.

onCreateIncomingConnection(PhoneAccountHandle, ConnectionRequest)

Le sous-système de télécommunications appelle cette méthode lorsque votre application appelle la méthode addNewIncomingCall(PhoneAccountHandle, Bundle) pour informer le système d'un nouvel appel entrant dans votre application. Votre application renvoie une nouvelle instance de votre implémentation de Connection (pour en savoir plus, consultez Implémenter la connexion) pour représenter le nouvel appel entrant. Vous pouvez personnaliser davantage la connexion entrante en effectuant les actions suivantes:

onCreateIncomingConnectionFailed(PhoneAccountHandle, ConnectionRequest)

Le sous-système de télécommunications appelle cette méthode lorsque votre application appelle la méthode addNewIncomingCall(PhoneAccountHandle, Bundle) pour informer Telecom d'un nouvel appel entrant, mais que cet appel n'est pas autorisé (pour en savoir plus, consultez la section Contraintes d'appel). Votre application doit rejeter l'appel entrant en silence, en publiant éventuellement une notification pour informer l'utilisateur de l'appel manqué.

Implémenter la connexion

Votre application doit créer une sous-classe de Connection pour représenter les appels. Vous devez remplacer les méthodes suivantes dans votre implémentation:

onShowIncomingCallUi()

Le sous-système de télécommunications appelle cette méthode lorsque vous ajoutez un appel entrant. Votre application doit afficher son UI d'appel entrant.

onCallAudioStateChanged(CallAudioState)

Le sous-système de télécommunications appelle cette méthode pour informer votre application que la route ou le mode audio actuel a changé. Cette méthode est appelée lorsque votre application modifie le mode audio à l'aide de la méthode setAudioRoute(int). Cette méthode peut également être appelée si le système modifie la route audio (par exemple, lorsqu'un casque Bluetooth se déconnecte).

onHold()

Le sous-système de télécommunications appelle cette méthode lorsqu'il souhaite mettre un appel en attente. En réponse à cette requête, votre application doit mettre l'appel en attente, puis appeler la méthode setOnHold() pour informer le système que l'appel est en attente. Le sous-système de télécommunications peut appeler cette méthode lorsqu'un service en cours d'appel, tel qu'Android Auto, qui montre que votre appel souhaite transmettre une requête utilisateur visant à mettre l'appel en attente. Le sous-système de télécommunications appelle également cette méthode si l'utilisateur effectue un appel actif dans une autre application. Pour en savoir plus sur les services en cours d'appel, consultez InCallService.

onUnhold()

Le sous-système de télécommunications appelle cette méthode lorsqu'il souhaite reprendre un appel mis en attente. Une fois que votre application a repris l'appel, elle doit appeler la méthode setActive() pour informer le système que l'appel n'est plus en attente. Le sous-système de télécommunications peut appeler cette méthode lorsqu'un service en cours d'appel, tel qu'Android Auto, qui montre que votre appel souhaite transmettre une requête pour reprendre l'appel. Pour en savoir plus sur les services en cours d'appel, consultez InCallService.

onAnswer()

Le sous-système de télécommunications appelle cette méthode pour informer votre application qu'un appel entrant doit être traité. Une fois que votre application a répondu à l'appel, elle doit appeler la méthode setActive() pour informer le système que la réponse a été obtenue. Le sous-système de télécommunications peut appeler cette méthode lorsque votre application ajoute un nouvel appel entrant et qu'un appel en cours dans une autre application ne peut pas être mis en attente. Dans ce cas, le sous-système de télécommunications affiche l'UI des appels entrants pour le compte de votre application. Le framework fournit une méthode surchargée qui permet de spécifier l'état de la vidéo dans lequel répondre à l'appel. Pour en savoir plus, consultez onAnswer(int).

onReject()

Le sous-système de télécommunications appelle cette méthode lorsqu'il souhaite rejeter un appel entrant. Une fois que votre application a refusé l'appel, elle doit appeler setDisconnected(DisconnectCause) et spécifier REJECTED comme paramètre. Votre application doit ensuite appeler la méthode destroy() pour informer le système qu'elle a traité l'appel. Le sous-système de télécommunications appelle cette méthode lorsque l'utilisateur a rejeté un appel entrant de votre application.

onDisconnect()

Le sous-système de télécommunications appelle cette méthode lorsqu'il souhaite mettre fin à un appel. Une fois l'appel terminé, votre application doit appeler la méthode setDisconnected(DisconnectCause) et spécifier LOCAL comme paramètre pour indiquer qu'une requête utilisateur a entraîné la déconnexion de l'appel. Votre application doit ensuite appeler la méthode destroy() pour informer le sous-système de télécommunications que l'application a traité l'appel. Le système peut appeler cette méthode lorsque l'utilisateur a déconnecté un appel via un autre service en cours d'appel, tel qu'Android Auto. Le système appelle également cette méthode lorsque votre appel doit être déconnecté pour permettre un autre appel, par exemple si l'utilisateur souhaite passer un appel d'urgence. Pour en savoir plus sur les services en cours d'appel, consultez InCallService.

Gérer les scénarios d'appel courants

L'utilisation de l'API ConnectionService dans votre flux d'appel implique l'interaction avec les autres classes du package android.telecom. Les sections suivantes décrivent les scénarios d'appel courants et la manière dont votre application doit utiliser les API pour les gérer.

Répondre aux appels entrants

Le flux de gestion des appels entrants varie selon qu'il existe des appels dans d'autres applications ou non. La différence entre les flux s'explique par le fait que le framework de télécommunications doit établir certaines contraintes en cas d'appels actifs dans d'autres applications, afin de garantir un environnement stable pour toutes les applications appelantes sur l'appareil. Pour en savoir plus, consultez la section Contraintes d'appel.

Aucun appel en cours dans les autres applis

Pour répondre aux appels entrants lorsqu'il n'y a pas d'appels actifs dans d'autres applications, procédez comme suit:

  1. Votre application reçoit un nouvel appel entrant à l'aide de ses mécanismes habituels.
  2. Utilisez la méthode addNewIncomingCall(PhoneAccountHandle, Bundle) pour informer le sous-système de télécommunications du nouvel appel entrant.
  3. Le sous-système de télécommunications se lie à l'implémentation ConnectionService de votre application et demande une nouvelle instance de la classe Connection représentant le nouvel appel entrant à l'aide de la méthode onCreateIncomingConnection(PhoneAccountHandle, ConnectionRequest).
  4. Le sous-système de télécommunications informe votre application qu'elle doit afficher l'interface utilisateur des appels entrants à l'aide de la méthode onShowIncomingCallUi().
  5. Votre application affiche son UI entrante à l'aide d'une notification avec un intent plein écran associé. Pour en savoir plus, consultez onShowIncomingCallUi().
  6. Appelez la méthode setActive() si l'utilisateur accepte l'appel entrant, ou setDisconnected(DisconnectCause) spécifiant REJECTED comme paramètre suivi d'un appel à la méthode destroy() si l'utilisateur refuse l'appel entrant.

Appels actifs dans d'autres applications ne pouvant pas être mis en attente

Pour répondre aux appels entrants lorsque des appels actifs dans d'autres applications ne peuvent pas être mis en attente, procédez comme suit:

  1. Votre application reçoit un nouvel appel entrant à l'aide de ses mécanismes habituels.
  2. Utilisez la méthode addNewIncomingCall(PhoneAccountHandle, Bundle) pour informer le sous-système de télécommunications du nouvel appel entrant.
  3. Le sous-système de télécommunications se lie à l'implémentation ConnectionService de votre application et demande une nouvelle instance de l'objet Connection représentant le nouvel appel entrant à l'aide de la méthode onCreateIncomingConnection(PhoneAccountHandle, ConnectionRequest).
  4. Le sous-système de télécommunications affiche l'interface utilisateur de votre appel entrant.
  5. Si l'utilisateur accepte l'appel, le sous-système de télécommunications appelle la méthode onAnswer(). Vous devez appeler la méthode setActive() pour indiquer au sous-système de télécommunications que l'appel est maintenant connecté.
  6. Si l'utilisateur rejette l'appel, le sous-système de télécommunications appelle la méthode onReject(). Vous devez appeler la méthode setDisconnected(DisconnectCause) en spécifiant REJECTED comme paramètre, puis un appel à la méthode destroy().

Passer des appels sortants

Le flux de passage d'un appel sortant implique de gérer la possibilité que l'appel ne puisse pas être passé en raison des contraintes imposées par le framework de télécommunications. Pour en savoir plus, consultez la section Contraintes d'appel.

Pour passer un appel sortant, procédez comme suit:

  1. L'utilisateur passe un appel sortant dans votre application.
  2. Utilisez la méthode placeCall(Uri, Bundle) pour informer le sous-système de télécommunications du nouvel appel sortant. Tenez compte des points suivants concernant les paramètres de méthode :
    • Le paramètre Uri représente l'adresse à laquelle l'appel est passé. Pour les numéros de téléphone standards, utilisez le schéma d'URI tel:.
    • Le paramètre Bundle vous permet de fournir des informations sur votre application appelante en ajoutant l'objet PhoneAccountHandle de votre application à l'extra EXTRA_PHONE_ACCOUNT_HANDLE. Votre application doit fournir l'objet PhoneAccountHandle à chaque appel sortant.
    • Le paramètre Bundle vous permet également de spécifier si l'appel sortant inclut une vidéo en spécifiant la valeur STATE_BIDIRECTIONAL dans l'extra EXTRA_START_CALL_WITH_VIDEO_STATE. Notez que par défaut, le sous-système de télécommunications achemine les appels vidéo vers le haut-parleur.
  3. Le sous-système de télécommunications est lié à l'implémentation ConnectionService de votre application.
  4. Si votre application ne peut pas passer d'appel sortant, le sous-système de télécommunications appelle la méthode onCreateOutgoingConnectionFailed(PhoneAccountHandle, ConnectionRequest) pour indiquer à votre application que l'appel ne peut pas être passé pour l'heure actuelle. Votre application doit informer l'utilisateur que l'appel ne peut pas être passé.
  5. Si votre application peut passer l'appel sortant, le sous-système de télécommunications appelle la méthode onCreateOutgoingConnection(PhoneAccountHandle, ConnectionRequest). Votre application doit renvoyer une instance de votre classe Connection pour représenter le nouvel appel sortant. Pour en savoir plus sur les propriétés à définir dans la connexion, consultez la section Implémenter le service de connexion.
  6. Une fois l'appel sortant connecté, appelez la méthode setActive() pour informer le sous-système de télécommunications que l'appel est actif.

Mettre fin à un appel

Pour mettre fin à un appel, procédez comme suit:

  1. Appelez la méthode setDisconnected(DisconnectCause) en envoyant LOCAL comme paramètre si l'utilisateur a mis fin à l'appel, ou envoyez REMOTE en tant que paramètre si l'autre partie a mis fin à l'appel.
  2. Appelez la méthode destroy().

Contraintes liées aux appels

Pour garantir une expérience d'appel simple et cohérente à vos utilisateurs, le framework de télécommunications applique certaines contraintes pour la gestion des appels sur l'appareil. Par exemple, imaginons que l'utilisateur a installé deux applications appelantes qui implémentent l'API ConnectionService autogérée : FooTalk et BarTalk. Dans ce cas, les contraintes suivantes s'appliquent:

  • Sur les appareils équipés d'un niveau d'API 27 ou inférieur, une seule application peut maintenir un appel en cours à la fois. Cette contrainte signifie que lorsqu'un utilisateur passe un appel en cours à l'aide de l'application FooTalk, celle-ci ne peut pas initier ni recevoir de nouvel appel.

    Sur les appareils équipés d'un niveau d'API 28 ou supérieur, si FooTalk et BarTalk déclarent les autorisations CAPABILITY_SUPPORT_HOLD et CAPABILITY_HOLD, l'utilisateur peut maintenir plusieurs appels en cours en basculant entre les applications pour initier ou répondre à un autre appel.

  • S'il participe à des appels gérés standards (par exemple, à l'aide de l'application Téléphone ou Téléphone intégrée), il ne peut pas participer à des appels provenant d'applications appelantes. Cela signifie que si l'utilisateur participe à un appel standard via son opérateur mobile, il ne peut pas participer simultanément à un appel FooTalk ou BarTalk.

  • Le sous-système de télécommunications déconnecte les appels de votre application si l'utilisateur compose un appel d'urgence.

  • Votre application ne peut pas recevoir ni passer d'appels pendant un appel d'urgence de l'utilisateur.

  • Si un appel est en cours dans une autre application appelante lorsque votre application reçoit un appel entrant, la réponse à l'appel entrant met fin à tous les appels en cours dans l'autre application. Votre application ne doit pas afficher son interface utilisateur d'appel entrant habituelle. Le framework de télécommunications affiche l'interface utilisateur de l'appel entrant et informe l'utilisateur que le fait de répondre au nouvel appel mettra fin à son ou ses appels en cours. Cela signifie que si l'utilisateur participe à un appel FooTalk et que l'application BarTalk reçoit un appel entrant, le framework de télécommunication informe l'utilisateur qu'il a un nouvel appel BarTalk entrant et que la réponse à l'appel BarTalk mettra fin à son appel FooTalk.

Devenir l'application de téléphone par défaut

L'application de téléphonie/téléphone par défaut fournit l'interface utilisateur pendant l'appel lorsque l'appareil est en cours d'appel. Elle permet également à l'utilisateur de passer des appels et de consulter l'historique de ces appels sur son appareil. Un appareil est fourni avec une application de téléphonie/téléphone par défaut fournie par le système. L'utilisateur peut choisir une seule application pour reprendre ce rôle à partir de l'application système. Une application qui souhaite remplir ce rôle utilise RoleManager pour demander à remplir le rôle RoleManager.ROLE_DIALER.

L'application pour téléphone par défaut fournit une interface utilisateur lorsque l'appareil est en cours d'appel et que l'appareil n'est pas en mode voiture (par exemple, UiModeManager#getCurrentModeType() n'est pas Configuration.UI_MODE_TYPE_CAR).

Pour remplir le rôle RoleManager.ROLE_DIALER, une application doit répondre à un certain nombre d'exigences:

  • Il doit gérer l'intent Intent#ACTION_DIAL. Cela signifie que l'application doit fournir une UI de clavier permettant à l'utilisateur d'effectuer des appels sortants.
  • Il doit implémenter entièrement l'API InCallService et fournir à la fois une UI pour les appels entrants et une UI pour les appels en cours.

Remarque: Si l'application qui remplit le RoleManager.ROLE_DIALER renvoie une InCallService null lors de la liaison, le framework de télécommunications revient automatiquement à l'utilisation de l'application de téléphonie préchargée sur l'appareil. Le système affichera une notification indiquant à l'utilisateur que l'appel s'est continué à l'aide de l'application de téléphonie préchargée. Votre application ne doit jamais renvoyer de liaison null. Cela signifie qu'elle ne répond pas aux exigences de RoleManager.ROLE_DIALER.

Remarque: Si votre application remplit RoleManager.ROLE_DIALER et apporte des modifications au moment de l'exécution qui l'empêchent de remplir les conditions requises pour ce rôle, RoleManager supprime automatiquement votre application du rôle et la ferme. Par exemple, si vous utilisez PackageManager.setComponentEnabledSetting(ComponentName, int, int) pour désactiver de manière programmatique les InCallService que votre application déclare dans son fichier manifeste, elle ne remplira plus les conditions requises pour RoleManager.ROLE_DIALER.

Le clavier préchargé est TOUJOURS utilisé lorsque l'utilisateur passe un appel d'urgence, même si votre application remplit le rôle RoleManager.ROLE_DIALER. Pour garantir une expérience optimale lors d'un appel d'urgence, le clavier par défaut doit TOUJOURS utiliser TelecomManager.placeCall(Uri, Bundle) pour passer des appels (y compris des appels d'urgence). Cela garantit que la plate-forme est en mesure de vérifier que la requête provient du clavier par défaut. Si une application de téléphonie non préchargée utilise Intent#ACTION_CALL pour passer un appel d'urgence, elle sera transmise à l'application de téléphonie préchargée avec Intent#ACTION_DIAL pour confirmation. L'expérience utilisateur n'est pas optimale.

Vous trouverez ci-dessous un exemple d'enregistrement de fichier manifeste pour un InCallService. Les métadonnées TelecomManager#METADATA_IN_CALL_SERVICE_UI indiquent que cette implémentation InCallService particulière vise à remplacer l'UI intégrée d'appel. Les métadonnées TelecomManager#METADATA_IN_CALL_SERVICE_RINGING indiquent que InCallService va sonner la sonnerie des appels entrants. Consultez ci-dessous pour savoir comment afficher l'interface utilisateur des appels entrants et faire sonner la sonnerie dans votre application.

 <service android:name="your.package.YourInCallServiceImplementation"
          android:permission="android.permission.BIND_INCALL_SERVICE"
          android:exported="true">
      <meta-data android:name="android.telecom.IN_CALL_SERVICE_UI" android:value="true" />
      <meta-data android:name="android.telecom.IN_CALL_SERVICE_RINGING"
          android:value="true" />
      <intent-filter>
          <action android:name="android.telecom.InCallService"/>
      </intent-filter>
 </service>

Remarque: Vous ne devez PAS marquer votre InCallService avec l'attribut android:exported="false", car cela pourrait entraîner l'échec de la liaison à votre implémentation lors des appels.

En plus d'implémenter l'API InCallService, vous devez également déclarer dans votre fichier manifeste une activité qui gère l'intent Intent#ACTION_DIAL. L'exemple ci-dessous montre comment procéder:

 <activity android:name="your.package.YourDialerActivity"
           android:label="@string/yourDialerActivityLabel">
      <intent-filter>
           <action android:name="android.intent.action.DIAL" />
           <category android:name="android.intent.category.DEFAULT" />
      </intent-filter>
      <intent-filter>
           <action android:name="android.intent.action.DIAL" />
           <category android:name="android.intent.category.DEFAULT" />
           <data android:scheme="tel" />
      </intent-filter>
 </activity>

Lorsqu'un utilisateur installe votre application et l'exécute pour la première fois, vous devez utiliser RoleManager pour lui demander s'il souhaite que votre application devienne la nouvelle application pour téléphone par défaut.

Le code ci-dessous montre comment votre application peut demander à devenir l'application de téléphonie ou d'appel par défaut:

 private static final int REQUEST_ID = 1;

 public void requestRole() {
     RoleManager roleManager = (RoleManager) getSystemService(ROLE_SERVICE);
     Intent intent = roleManager.createRequestRoleIntent(RoleManager.ROLE_DIALER);
     startActivityForResult(intent, REQUEST_ID);
 }

 public void onActivityResult(int requestCode, int resultCode, Intent data) {
     if (requestCode == REQUEST_ID) {
         if (resultCode == android.app.Activity.RESULT_OK) {
             // Your app is now the default dialer app
         } else {
             // Your app is not the default dialer app
         }
     }
 }

Accès à InCallService pour les accessoires connectés

    Si votre application est une application associée tierce et souhaite accéder aux API InCallService, elle peut:

    1. Déclarer l'autorisation MANAGE_ONGOING_CALLS dans votre fichier manifeste
    2. Associez un accessoire connecté physique via l'API CompanionDeviceManager en tant qu'application associée. Consultez https://developer.android.com/guide/topics/connectivity/companion-device-pairing.
    3. Implémenter InCallService avec l'autorisation BIND_INCALL_SERVICE

Affichage de la notification d'appel entrant

Lorsque votre application reçoit un nouvel appel entrant via InCallService#onCallAdded(Call), elle se charge d'afficher une UI d'appel entrant pour l'appel entrant. Pour ce faire, elle doit utiliser les API NotificationManager pour publier une nouvelle notification d'appel entrant.

Lorsque votre application déclare les métadonnées TelecomManager#METADATA_IN_CALL_SERVICE_RINGING, elle se charge de faire sonner la sonnerie des appels entrants. Votre application doit créer un élément NotificationChannel qui spécifie la sonnerie souhaitée. Par exemple :

 NotificationChannel channel = new NotificationChannel(YOUR_CHANNEL_ID, "Incoming Calls",
          NotificationManager.IMPORTANCE_MAX);
 // other channel setup stuff goes here.

 // We'll use the default system ringtone for our incoming call notification channel.  You can
 // use your own audio resource here.
 Uri ringtoneUri = RingtoneManager.getDefaultUri(RingtoneManager.TYPE_RINGTONE);
 channel.setSound(ringtoneUri, new AudioAttributes.Builder()
          // Setting the AudioAttributes is important as it identifies the purpose of your
          // notification sound.
          .setUsage(AudioAttributes.USAGE_NOTIFICATION_RINGTONE)
          .setContentType(AudioAttributes.CONTENT_TYPE_SONIFICATION)
      .build());

 NotificationManager mgr = getSystemService(NotificationManager.class);
 mgr.createNotificationChannel(channel);

Lorsque votre application reçoit un nouvel appel entrant, elle crée un Notification pour cet appel et l'associe à votre canal de notification d'appel entrant. Vous pouvez spécifier un PendingIntent dans la notification pour lancer l'interface utilisateur des appels entrants en plein écran. Le framework du gestionnaire de notifications affiche votre notification sous la forme d'une notification prioritaire si l'utilisateur est en train d'utiliser le téléphone. Lorsque l'utilisateur n'utilise pas le téléphone, l'interface utilisateur des appels entrants en plein écran est utilisée à la place. Par exemple :

 // Create an intent which triggers your fullscreen incoming call user interface.
 Intent intent = new Intent(Intent.ACTION_MAIN, null);
 intent.setFlags(Intent.FLAG_ACTIVITY_NO_USER_ACTION | Intent.FLAG_ACTIVITY_NEW_TASK);
 intent.setClass(context, YourIncomingCallActivity.class);
 PendingIntent pendingIntent = PendingIntent.getActivity(context, 1, intent, PendingIntent.FLAG_MUTABLE_UNAUDITED);
 // Build the notification as an ongoing high priority item; this ensures it will show as
 // a heads up notification which slides down over top of the current content.
 final Notification.Builder builder = new Notification.Builder(context);
 builder.setOngoing(true);
 builder.setPriority(Notification.PRIORITY_HIGH);
 // Set notification content intent to take user to the fullscreen UI if user taps on the
 // notification body.
 builder.setContentIntent(pendingIntent);
 // Set full screen intent to trigger display of the fullscreen UI when the notification
 // manager deems it appropriate.
 builder.setFullScreenIntent(pendingIntent, true);
 // Setup notification content.
 builder.setSmallIcon( yourIconResourceId );
 builder.setContentTitle("Your notification title");
 builder.setContentText("Your notification content.");
 // Use builder.addAction(..) to add buttons to answer or reject the call.
 NotificationManager notificationManager = mContext.getSystemService(
     NotificationManager.class);
 notificationManager.notify(YOUR_CHANNEL_ID, YOUR_TAG, YOUR_ID, builder.build());
```