Comme beaucoup d'entre vous je me suis demandé à quoi sert et surtout comment fonctionne le RIL sous androïde?
Voici un résumé (un peut technique) de ce que j'ai pu en comprendre.
Android's Radio Interface Layer (RIL) ,fournit une couche d'abstraction entre les services de téléphonie d'Androïde (android.telephony) et le matériel radio.
Les mobiles Android, sont comme la plupart des smartphones d’aujourd’hui composés généralement d’au moins 2 cœurs, 1 pour l’Application (Linux et Android) et 1 pour le Modem (ou Baseband ou encore Radio).
Le RIL est indépendant de la radio et inclut la communication (relation) entre le Système Global Mobile (GSM) et la radios.
En résumé, nous avons d’une part, un Modem piloté par commandes AT et d’autre part, Android qui doit piloter ce Modem.
C’est a ce moment qu’intervient le RIL.
Le principe du RIL n’est pas nouveau, il existait déjà avec Windows Mobile.
Et son utilité reste assez simple, transformer les requêtes Android (appelées RIL_REQUEST) en commandes AT (c’est la couche en contact avec le monde extérieur, c’est par ici qu’arrivent les actions utilisateurs (passer un appel, lire un contact, etc.)).
Le RIL est un démon écrit en C, Android s’y connecte par le biais du RILJ (pour RIL java) au travers d’une socket où les objets sont (dé)sérialisés pour y être transportés.
Le RIL écrit ensuite les commandes AT sur un socket ou tout autre port (tty, …) et elles sont alors convoyées jusqu’au Modem, ce dernier renvoie alors le retour des commandes sur le port ouvert.
Voici un schéma permettant de mieux comprendre le principe général :
Le RIL est constitué de deux composantes principales:
RIL Démon: Le RIL Démon initialise le RIL vendeur, les processus de toutes les communications des services de téléphonie Android, et distribue les appels vers le RIL vendeur comme des commandes sollicitées.
Vendor RIL (RIL vendeur): La radio-spécifiques RIL vendeur (ril.h) traite toutes les communications avec le matériel de radio et les transfert vers le Démon RIL (rild) grâce à des commandes non sollicités.
Il ya deux formes de communication qui gère le RIL:
1.Solicited commands (commandes sollicitées): Les commandes sollicitées émis par lib RIL, telles que la numérotation et de déconnexion.
Il y a plus de soixante commandes sollicité regroupés de la façon suivantes:
PIN SIM, IO, et IMSI / IMEI
Appelez le statut et la manutention (numéroteur, répondre, muet ...)
Interrogation sur le statut du réseau
Mise en réseau (blocage, le transfert, la sélection ...)
SMS
connexion PDP
Power et Reset
services supplémentaires
Défini par le fournisseur et le support technique
2.Unsolicited responses (réponses spontanées): les réponses spontanées qui proviennent de la bande de base, tels que CALL_STATE_CHANGED et NEW_SMS.
Il y a plus de dix commandes non sollicités regroupés par familles suivantes:
L'état du réseau a changé
Notification d'un nouveau SMS
Notification d'un nouveau USSD
La puissance du signal ou l'heure a changé etc...
Prenons un exemple concret: l’appel sortant (ou MO Call).
Lorsque l’utilisateur presse le « bouton vert », la requête passe au travers du Framework pour arriver jusqu’au RILJ par la méthode dial qui va alors préparer une RIL_REQUEST_DIAL et fournir les paramètres nécessaires pour passer l’appel (numéro et présentation du numéro appelant).
Cette requête est ensuite reçue par le RIL , qui transforme cette requête en commande ATD.
Le RIL passe ensuite en mode lecture, en attente de réception de la réponse finale qui peut être OK, NO CARRIER si l’appel n’a pas été établie ou +CME ERROR: xx lorsqu’une erreur est survenue (xx code de l’erreur).
Une fois la réponse traitée, il (le RIL) envoie au Framework (RILJ) la RIL_RESPONSE avec les paramètres (si besoin).
Le RIL dépile ensuite les autres requêtes (envoie de SMS, activation des données, mesure du signal, etc.) et les exécute une à une.
L’information de l’appel remonte quant à elle jusqu’au Dialer par le biais des interfaces.
Note:
Le seul bémol de cette architecture, c’est que, par défaut, le RIL empile les requêtes à destination du Modem.
Alors qu’avec quelques modifications, on pourrait ouvrir plusieurs canaux AT (car les Modems le supportent) et exécuter des requêtes en parallèle pour gagner en efficacité.
Mais tout cela reste du ressort des constructeurs.
Certaines mise à jour de radio n'ont pas besoin de changer le RIL!
-Si vous rencontrez quelques problèmes, vous pourriez revenir à votre RIL origine facilement: il suffit de reflacher la ROM ou de faire une restauration nandroid!
-Les fichiers RIL sont stockés dans PARTIE ROM, donc si vous faite un WIPE & installer une autre ROM, rien ne reste sur votre téléphone!
Source: XDA et tutomobile
Dernière édition par yosscal le Jeu 30 Juin 2011 - 14:15, édité 1 fois
Voici un résumé (un peut technique) de ce que j'ai pu en comprendre.
Déscriptif:
Android's Radio Interface Layer (RIL) ,fournit une couche d'abstraction entre les services de téléphonie d'Androïde (android.telephony) et le matériel radio.
Les mobiles Android, sont comme la plupart des smartphones d’aujourd’hui composés généralement d’au moins 2 cœurs, 1 pour l’Application (Linux et Android) et 1 pour le Modem (ou Baseband ou encore Radio).
Le RIL est indépendant de la radio et inclut la communication (relation) entre le Système Global Mobile (GSM) et la radios.
En résumé, nous avons d’une part, un Modem piloté par commandes AT et d’autre part, Android qui doit piloter ce Modem.
C’est a ce moment qu’intervient le RIL.
Le principe du RIL n’est pas nouveau, il existait déjà avec Windows Mobile.
Et son utilité reste assez simple, transformer les requêtes Android (appelées RIL_REQUEST) en commandes AT (c’est la couche en contact avec le monde extérieur, c’est par ici qu’arrivent les actions utilisateurs (passer un appel, lire un contact, etc.)).
Le RIL est un démon écrit en C, Android s’y connecte par le biais du RILJ (pour RIL java) au travers d’une socket où les objets sont (dé)sérialisés pour y être transportés.
Le RIL écrit ensuite les commandes AT sur un socket ou tout autre port (tty, …) et elles sont alors convoyées jusqu’au Modem, ce dernier renvoie alors le retour des commandes sur le port ouvert.
Voici un schéma permettant de mieux comprendre le principe général :
Le RIL est constitué de deux composantes principales:
RIL Démon: Le RIL Démon initialise le RIL vendeur, les processus de toutes les communications des services de téléphonie Android, et distribue les appels vers le RIL vendeur comme des commandes sollicitées.
Vendor RIL (RIL vendeur): La radio-spécifiques RIL vendeur (ril.h) traite toutes les communications avec le matériel de radio et les transfert vers le Démon RIL (rild) grâce à des commandes non sollicités.
Il ya deux formes de communication qui gère le RIL:
1.Solicited commands (commandes sollicitées): Les commandes sollicitées émis par lib RIL, telles que la numérotation et de déconnexion.
Il y a plus de soixante commandes sollicité regroupés de la façon suivantes:
PIN SIM, IO, et IMSI / IMEI
Appelez le statut et la manutention (numéroteur, répondre, muet ...)
Interrogation sur le statut du réseau
Mise en réseau (blocage, le transfert, la sélection ...)
SMS
connexion PDP
Power et Reset
services supplémentaires
Défini par le fournisseur et le support technique
2.Unsolicited responses (réponses spontanées): les réponses spontanées qui proviennent de la bande de base, tels que CALL_STATE_CHANGED et NEW_SMS.
Il y a plus de dix commandes non sollicités regroupés par familles suivantes:
L'état du réseau a changé
Notification d'un nouveau SMS
Notification d'un nouveau USSD
La puissance du signal ou l'heure a changé etc...
Prenons un exemple concret: l’appel sortant (ou MO Call).
Lorsque l’utilisateur presse le « bouton vert », la requête passe au travers du Framework pour arriver jusqu’au RILJ par la méthode dial qui va alors préparer une RIL_REQUEST_DIAL et fournir les paramètres nécessaires pour passer l’appel (numéro et présentation du numéro appelant).
Cette requête est ensuite reçue par le RIL , qui transforme cette requête en commande ATD.
Le RIL passe ensuite en mode lecture, en attente de réception de la réponse finale qui peut être OK, NO CARRIER si l’appel n’a pas été établie ou +CME ERROR: xx lorsqu’une erreur est survenue (xx code de l’erreur).
Une fois la réponse traitée, il (le RIL) envoie au Framework (RILJ) la RIL_RESPONSE avec les paramètres (si besoin).
Le RIL dépile ensuite les autres requêtes (envoie de SMS, activation des données, mesure du signal, etc.) et les exécute une à une.
L’information de l’appel remonte quant à elle jusqu’au Dialer par le biais des interfaces.
Note:
Le seul bémol de cette architecture, c’est que, par défaut, le RIL empile les requêtes à destination du Modem.
Alors qu’avec quelques modifications, on pourrait ouvrir plusieurs canaux AT (car les Modems le supportent) et exécuter des requêtes en parallèle pour gagner en efficacité.
Mais tout cela reste du ressort des constructeurs.
Certaines mise à jour de radio n'ont pas besoin de changer le RIL!
-Si vous rencontrez quelques problèmes, vous pourriez revenir à votre RIL origine facilement: il suffit de reflacher la ROM ou de faire une restauration nandroid!
-Les fichiers RIL sont stockés dans PARTIE ROM, donc si vous faite un WIPE & installer une autre ROM, rien ne reste sur votre téléphone!
Source: XDA et tutomobile
Dernière édition par yosscal le Jeu 30 Juin 2011 - 14:15, édité 1 fois