Comment le code du modem communique-t-il avec le code Android?

Question

Je voudrais connaître une idée de haut niveau de la façon dont le code de modem Android appellera / transmettra un message à la couche d'application Android. Disons que nous prenons des SMS par exemple. Si le réseau envoie des SMS et un modem (par exemple, le code Qualcomm C l’analyse), comment est-il transmis à la couche d’application Android?

Y a-t-il toujours un appel JNI en cours? comme interface entre modem et Android? Pouvez-vous s'il vous plaît partager les informations avec nous. Merci

Answer 1

Dans presque tous les source android de base, comme l'a constaté dans l'AFST/CAF/CM source (Android Open Source Project, CodeAurora Forum, Cyanogenmod respectivement), aura C code appelé le rild, (la Radio de l'Interface de la Couche de Démon). Ceci est communément trouvée dans l' /hardware/ril de l'arborescence source.

Ce démon s'exécute à partir du moment où Android démarre, et crée un socket appelés /dev/socket/rild et /dev/socket/rild-debug. Il y aura une bibliothèque propriétaire venant de Qualcomm, HTC, qui est chargé dynamiquement au moment de l'exécution au démarrage. Il est propriétaire de la bibliothèque qui, à son tour, communique à la radio firmware. Et le rild's des crochets pour les rappels dans la bibliothèque propriétaire y est établi et, ensuite.

Au rild couche, via ladite douille, c'est comment la Android couche (qui se trouve dans l'arborescence source, frameworks/base/telephony/com/android/internal/telephony/RIL.java) communique.

Sur le Java côté, il ouvre le support pour la lecture/écriture, ainsi que d'établir les intentions et mise en place des délégués pour la radiodiffusion ou de recevoir des événements par le biais de ce support.

Par exemple, un appel entrant, le propriétaire de la bibliothèque, invoque un rappel de crochet mis en place par rild. Le rild écrit standard générique À Hayes commandes de modem à la prise, sur le Java côté, il lit et interprète les commandes de modem, et à partir de là, le PhoneManager diffuse CALL_STATE_RINGING, dans lequel le Téléphone application (qui se trouve dans la source d' packages/apps/Phone) a enregistré un récepteur et permet de lancer l'interface Utilisateur, et qui est de savoir comment vous arrivez à répondre à l'appel.

Un autre exemple, faire un appel sortant, vous composez un numéro sur Android, l'intention est créée, et qui à son tour le PhoneManager (C'est la racine de tout cela, ici, ne me souviens pas de ma tête, pense que sa en frameworks/base/core/java quelque part dans l'arborescence des sources) reçoit l'intention, de le convertir en une séquence de commandes de Hayes modem, écrire à la prise de courant, le rild invoque ensuite un rappel à la propriété de la bibliothèque, la bibliothèque propriétaire à son tour, les délégués à la radio firmware.

Dernier exemple, l'envoi de messages texte, de la Messagerie (qui se trouve dans packages/apps/Mms source arbre) de l'application, le texte que vous tapez, obtient poussé dans l'intention, la PhoneManager reçoit l'intention, convertit le texte en GSM-codé à l'aide de 7-bits GSM lettres (IIRC), est écrit à la prise, du rild invoque à son tour un rappel à la bibliothèque propriétaire, la bibliothèque propriétaire à son tour, les délégués à la radio firmware et le texte a maintenant quitté le domaine du combiné et de l'est dans les ondes quelque part... :) avec l'envoi d'un message de diffusion à l'intérieur d'Android lui-même, à condition qu' READ_PHONE_STATE autorisation est utilisée et est spécifié dans la AndroidManifest.xml.

De même, à l'inverse, lors de la réception d'un message texte, il est à l'inverse, le firmware de radio reçoit des octets, le propriétaire de la bibliothèque appelle le rappel à la rild, et donc écrit les octets de la douille. Sur le Java côté, il lit et décode la séquence d'octets, la convertit en texte que nous connaissons, les feux de diffusion avec un message reçu de notification. La Messagerie de l'application, à son tour, a enregistré les récepteurs pour la radiodiffusion, et envoie l'intention de la barre de notification pour dire quelque chose comme "Nouveau message reçu de +xxxxxx"

Les intentions sont trouvés en frameworks/base/telephony/java/com/android/internal/telephony/TelephonyIntents.java

Qui est l'essentiel de la façon dont le système de téléphonie de travaux, la vraie beauté, c'est qu'elle utilise générique À Hayes commandes de modem ainsi de simplifier et de cacher les véritables propriétaires des mécanismes.

Comme pour Qualcomm, HTC, oublier dans la pensée qu'ils avaient jamais ouvrir la source de la bibliothèque en question parce que la radio téléphonie couche est intégré au sein de la soi-C (Système sur une Puce) de circuits!

Qui est aussi, comme une note de côté, pourquoi ses risqué pour flasher le firmware de radio, certains appareils offrent la possibilité de le faire, flash le mauvais firmware (comme incompatible ou ne convient pas pour le combiné), baiser le combiné d'adieu et de l'utiliser comme un bouchon de porte ou de papier-poids! :)

Il convient de noter, qu'il y a zéro JNI mécanismes impliqués.

C'est à partir de ma compréhension de la façon dont il fonctionne, de ce que je peux dire est-ce, la radio firmware est chargé dans une adresse de mémoire quelque part où le noyau linux a réservé l'espace d'adressage et de ne pas y toucher, quelque chose comme dans les vieux PC jours lorsque DOS démarré, il y a d'adresses réservées utilisé par le BIOS, je pense, qui est similaire ici, les adresses marqués comme étant réservés sont occupés par le firmware, dans lequel le propriétaire de la radio de la bibliothèque parle à elle - et puisque la bibliothèque est en cours d'exécution dans l'espace d'adressage détenue par le noyau, un lá propriété de root avec les privilèges de root, il peut "parler" à elle, si vous pensez à l'aide de l'ancien dialecte de BASE de peek et poke, je suppose que vous ne serait pas être loin de la vérité il y a, par écrit, une certaine séquence d'octets à cette adresse, le firmware radio qui agit sur lui, presque comme avoir un vecteur d'interruption de la table... ce devine ici comment cela fonctionne exactement. :)

Answer 2

Continuant à partir de l'explication par t0mm13b, Lorsque nous parlons d'un smartphone, pensez à la couche 3 opérations wrt SMS/Appels.

RIL (niveau Utilisateur) <-> AP <-> CP

AP : Processeur d'Application(Où votre Android système d'exploitation fonctionne. Penser à des jeux, des chansons, des vidéos, appareil photo, etc en cours d'exécution sur ce processeur)

CP : Cellulaire Processeur Qui traite de l'Air-interface pour les appels entrants/sortants/sms, interagit avec Tour de Réseau etc ..)

Maintenant, disons que certaines données sont reçues au CP côté (Il pourrait être données internet/sms/appel). Maintenant, il y a certains canaux logiques entre les AP et les CP. Si le CP va pousser les données reçues à un correspondant de la chaîne en fonction du type de données. Ces données seront reçues par l'AP. AP va envoyer ces données à la RIL/App. RIL décoder ces données (en particulier l'appel/sms de données). Basé sur cette donne notification à l'Utilisateur sur SMS/Appel.