Comment le code du modem parle-t-il à Android code
Je voudrais avoir une idée de haut niveau de la façon dont Android Le code du modem appellera/passera le message à Android couche d'application. Disons que nous prenons SMS par exemple. Si le réseau envoie SMS et modem (disons que le code Qualcomm C l’analyse)) comment est-il transmis à Android Couche d’application?
Y a-t-il toujours un appel JNI? comme interface entre le modem et Android? Pouvez-vous s'il vous plaît partager les informations avec nous. Merci
Dans presque tous les Android base source trouvée dans la source AOSP/CAF/CM (Android Open Source Project, CodeAurora Forum, Cyanogenmod respectivement), aura un code C appelé rild, (démon de couche d'interface radio). Cela se trouve généralement dans le /hardware/ril de l'arborescence source.
Ce démon s'exécute à partir du moment Android démarre et crée une socket appelée /dev/socket/rild et /dev/socket/rild-debug. Il y aura une bibliothèque propriétaire provenant de Qualcomm, HTC, qui sera chargée dynamiquement au moment de l'exécution au démarrage. C'est cette bibliothèque propriétaire qui, à son tour, communique avec le micrologiciel radio. Et les crochets de rild pour les rappels dans la bibliothèque propriétaire sont établis ici et là.
Au niveau de la couche rild, via la socket susmentionnée, est la façon dont la couche Android (trouvée dans l'arborescence source, frameworks/base/telephony/com/Android/internal/telephony/RIL.Java) communique.
Du côté Java côté, il ouvre le socket pour la lecture/écriture, ainsi que pour établir des intentions et configurer des délégués pour la diffusion/réception d'événements via ce socket.
Par exemple, un appel entrant, la bibliothèque propriétaire, appelle un hook de rappel tel que configuré par rild. Le rild écrit les commandes génériques standard AT Hayes modem dans le socket, du côté Java, il lit et interprète les commandes du modem) , et à partir de là, le PhoneManager diffuse CALL_STATE_RINGING, dans laquelle Téléphone application (trouvée dans la source packages/apps/Phone) a enregistré un récepteur et démarre l'interface utilisateur, et c'est ainsi que vous pouvez répondre à l'appel.
Un autre exemple, en faisant un appel sortant, vous composez un numéro sur Android, l'intention est créée et qui à son tour le PhoneManager ( Ceci est la racine de tout cela , ici, je ne me souviens pas du haut de ma tête, pense que c'est dans frameworks/base/core/Java quelque part dans l'arborescence source) reçoit l'intention, convertissez-la en une séquence de AT commandes modem Hayes, écrivez-la dans le socket, le rild puis invoque un rappel à la bibliothèque propriétaire, la bibliothèque propriétaire délègue à son tour au micrologiciel radio.
Dernier exemple, l'envoi de messages texte à partir de Messagerie (trouvé dans packages/apps/Mms arborescence source), le texte que vous tapez est inséré dans une intention, le PhoneManager reçoit l'intention, convertit le texte en code GSM à l'aide de Les lettres GSM 7 bits (IIRC) sont écrites sur le socket, le rild appelle à son tour un rappel vers la bibliothèque propriétaire, la bibliothèque propriétaire délègue à son tour le firmware de la radio et le texte a maintenant quitté le domaine du combiné et se trouve quelque part dans les ondes ... :) En plus d'envoyer un message de diffusion dans Android lui-même, à condition que READ_PHONE_STATE l'autorisation est utilisée et spécifiée dans AndroidManifest.xml .
De même à l'inverse, lors de la réception d'un SMS, c'est l'inverse, le firmware radio reçoit quelques octets, la bibliothèque propriétaire appelle le rappel à rild, et écrit ainsi les octets dans le socket. Du côté Java, il le lit et décode la séquence d'octets, le convertit en texte comme nous le savons, déclenche une diffusion avec une notification de message reçu. Le L'application de messagerie à son tour, a enregistré des récepteurs pour ladite diffusion, et envoie une intention à la barre de notification pour dire quelque chose comme " Nouveau message reçu de + xxxxxx "
Les intentions se trouvent dans frameworks/base/telephony/Java/com/Android/internal/telephony/TelephonyIntents.Java
C'est l'essentiel du fonctionnement du système de téléphonie, la vraie beauté est qu'il utilise des commandes génériques AT modem Hayes simplifiant et masquant ainsi les vrais mécanismes propriétaires.
En ce qui concerne Qualcomm, HTC, oubliez-le en pensant qu'ils ouvriraient jamais la bibliothèque en question, car la couche de radiotéléphonie est intégrée dans les circuits S-o-C (System on a Chip)!
Ce qui explique également pourquoi il est risqué de flasher le firmware de la radio, certains combinés offrent la possibilité de le faire, de flasher le mauvais firmware (tel qu'un incompatible ou ne convient pas pour le combiné), de dire adieu au combiné et d'utiliser que comme butée de porte ou comme presse-papier! :)
Il convient de noter qu'il n'y a aucun mécanisme JNI impliqué.
Cela vient de ma compréhension de son fonctionnement, de ce que je peux dire, le firmware de la radio est chargé dans une adresse mémoire quelque part où le noyau Linux a réservé l'espace d'adressage et ne le touche pas, quelque chose comme dans l'ancien PC jours où DOS a démarré, il y avait des adresses réservées utilisées par le BIOS, je pense, c'est similaire ici, les adresses marquées comme réservées sont occupées par le firmware, dans lequel la bibliothèque de radio propriétaire lui parle - et puisque la bibliothèque fonctionne l'espace d'adresse détenu par le noyau, un lá détenu par root avec des privilèges root, il peut "lui parler", si vous pensez utiliser l'ancien dialecte BASIC de "peek and poke", je suppose que vous ne seriez pas loin du marquez-y, en écrivant une certaine séquence d'octets à cette adresse, le micrologiciel radio agit sur elle, presque comme avoir une table de vecteurs d'interruption ... ceci suppose ici comment cela fonctionne exactement. :)
Dans la continuité de l'explication de t0mm13b, lorsque nous parlons d'un smartphone, pensez aux opérations 3 couches écrites sur SMS/Appels.
RIL (niveau utilisateur) <-> AP <-> CP
AP: Processeur d'application (où votre Android OS fonctionne. Pensez aux jeux, chansons, vidéos, appareil photo, etc. fonctionnant sur ce processeur)
CP: Processeur cellulaire (qui traite en fait de l'interface Air pour les appels/sms entrants/sortants, interagit avec la tour de réseau, etc.)
Supposons maintenant que certaines données soient reçues côté CP (il peut s'agir de données Internet/SMS/appels). Il existe maintenant certains canaux logiques entre AP et CP. Le CP poussera donc les données reçues vers un canal correspondant en fonction du type de données. Ces données seront reçues par AP. AP renverra ces données à RIL/App. RIL décode ces données (en particulier les données d'appel/sms). Sur la base de cela, donne une notification à l'utilisateur sur les SMS/appels.