Architecture du noyau du système d'exploitation Android. Test du système d'exploitation mobile Android. Comment fonctionne le système d'exploitation Android

Essai

Architecture de la plate-forme Google Android

Introduction

Android est une pile logicielle pour appareils mobiles qui comprend un système d'exploitation, un middleware et des applications utilisateur de base (client de messagerie, calendrier, cartes, navigateur, contacts, etc.).

Contrairement aux idées reçues, Android est installé non seulement sur les tablettes et les smartphones, mais aussi sur les liseuses, les lecteurs numériques, les montres, les netbooks et même les lunettes Google.

Cette plateforme est la plus populaire du marché : elle est installée sur 68% des appareils. Le nombre de programmes disponibles sur la boutique d'applications Google Play dépasse les 600 000 unités. Pendant toute la durée de fonctionnement du magasin, 20 milliards d'installations d'applications ont été réalisées. Selon Andy Rubin, responsable du développement Android chez Google, 1,3 million d'appareils Android sont activés chaque jour dans le monde.

Ces données m'ont incité à étudier la question de l'architecture de la plateforme.

Architecture Android

Figure 1. Structure de la plateforme Google Android

L'architecture de Google Android se compose de quatre couches (la numérotation indique l'ordre des couches de bas en haut).

)La version 2.6 du noyau OS Linux assure le fonctionnement du système. Il est responsable de la sécurité, de la mémoire, de l'alimentation et de la gestion des processus, et fournit également une pile réseau et un modèle de pilote. Il joue également un rôle de connexion entre le matériel et le reste de la pile logicielle.

)Le middleware est un ensemble de bibliothèques conçues pour fournir des fonctionnalités critiques aux applications.

En voici quelques uns:

· Gestionnaire de surfaces - gestionnaire de fenêtres composites. Au lieu de dessiner des graphiques dans le tampon d'affichage, le système envoie les commandes de dessin entrantes au tampon hors écran, où elles s'accumulent avec d'autres, constituant une certaine composition, puis sont affichées à l'utilisateur sur l'écran. Cela vous permet de créer des effets fluides intéressants, une transparence de fenêtre et des transitions fluides.

· Cadre médiatique - bibliothèques implémentées sur la base de PacketVideo OpenCORE. Avec leur aide, le système enregistre/lit du contenu audio et vidéo, et affiche des images statiques. Les formats MPEG4, H.264, MP3, AAC, AMR, JPG et PNG, etc. sont pris en charge.

· SQLite - un SGBD relationnel utilisé sous Android comme moteur principal pour travailler avec les bases de données utilisées par les applications pour stocker des informations.

· Bibliothèques 3D - utilisé pour le rendu de graphiques 3D, en utilisant l'accélération matérielle si possible. Implémenté sur la base de l'API OpenGL ES 1.0.

· Type libre - une bibliothèque pour travailler sur la rastérisation des polices et effectuer des opérations sur celles-ci.

· LibWebCore - Bibliothèques du moteur de navigateur WebKit.

· bibliothèque est une bibliothèque de langage C standard configurée pour fonctionner sur des appareils basés sur Linux.

Toutes les bibliothèques sont écrites en C++ et compilées pour un matériel spécifique.

L'environnement Android Runtime se situe au même niveau. Il se compose de la machine virtuelle Dalvik Java et des bibliothèques du noyau. Dalvik prend en charge le fonctionnement simultané de plusieurs applications et exécute des fichiers dans un format spécial .dex, optimisé pour les appareils dotés d'une petite quantité de mémoire. Les bibliothèques principales sont écrites en Java et prennent en charge un large éventail de fonctionnalités.

Chaque application du runtime Android s'exécute dans sa propre instance de la machine virtuelle Dalvik. Autrement dit, tous les processus en cours d'exécution sont isolés du système d'exploitation et les uns des autres. Une fonctionnalité de la structure Android Runtime permet aux programmes de s'exécuter strictement au sein d'une machine virtuelle. Grâce à cela, le noyau du système d'exploitation est protégé de l'influence d'autres composants. Les codes d'erreur ou les logiciels malveillants ne pourront pas endommager le système ou l'appareil lui-même. La fonction de protection, outre l'exécution directe du code du programme, est l'une des fonctions clés de ce niveau.

3)Le niveau suivant est l'Application Framework, ou cadre d'application. C'est grâce aux frameworks d'application que les développeurs accèdent aux API fournies par les composants système sous-jacents. De plus, grâce à l'architecture du framework, toute application dispose de capacités déjà implémentées d'autres applications auxquelles l'accès est autorisé.

L'ensemble de base de services et de systèmes qui sous-tendent chaque application et font partie du cadre comprend :

· Ensemble de vues riche et extensible ( Vues ), qui peut être utilisé pour créer des composants d'application visuels tels que des listes, des champs de texte, des tableaux, des boutons ou même un navigateur Web intégré.

· Fournisseurs de contenu ( Fournisseurs de contenu ), qui gère les données que certaines applications mettent à disposition d'autres afin qu'elles puissent les utiliser pour leur travail.

· Gestionnaire de ressources ( Gestionnaire de ressources ), donnant accès à des ressources sans fonctionnalité (ne contenant pas de code), par exemple des chaînes de données, des graphiques, des fichiers et autres.

· Gestionnaire d'alertes ( Gestionnaire de notifications ), qui permet à toutes les applications d'afficher leurs propres notifications à l'utilisateur dans la barre d'état.

· Gestionnaire d'actions ( Responsable d'activité ), qui gère les cycles de vie des applications, stocke des données sur l'historique du travail avec les actions et fournit également un système de navigation pour celles-ci.

· Gestionnaire d'emplacement ( Gestionnaire de localisation ), permettant aux applications de recevoir périodiquement des données de géolocalisation mises à jour sur l'appareil.

Ainsi, les applications du système d'exploitation Android peuvent disposer d'outils auxiliaires.

Différences entre un framework et une bibliothèque

· Le framework exécute uniquement le code écrit pour lui, les bibliothèques s'exécutent elles-mêmes.

· Le cadre se compose de bibliothèques avec des fonctionnalités et des objectifs différents, et les bibliothèques combinent des ensembles de fonctions dont la logique est similaire.

4)Niveau applications. Cela inclut les programmes de base préinstallés sur Android. Il s'agit d'un navigateur, d'un client de messagerie, d'un programme d'envoi de SMS, de cartes, d'un calendrier, d'un gestionnaire de contacts. La liste des applications intégrées peut varier selon le modèle d'appareil et la version d'Android. Les logiciels tiers se situent également à ce niveau. Le système vous permet de l'installer sans restrictions, de sorte que toutes les applications standards peuvent être remplacé par des analogues. Les applications Android sont écrites en Java.

Conclusion

utilisateur du programme Android fonctionnant

Les caractéristiques architecturales de la plateforme Google Android lui ont permis de prendre la première place parmi les autres plateformes. Les principaux :

)Machine virtuelle orientée registre Dalvik pour exécuter des applications.

)Bibliothèques innovantes qui étendent considérablement les fonctionnalités des appareils.

)SGBD SQLite "léger" pour le stockage de données.

)La possibilité de prendre en charge les graphiques 3D et 2D, et même de les combiner dans une seule application.

)Multitâche et isolation des processus les uns des autres.

)Polyvalence de l'architecture et haute qualité.

Liste des sources

1.Goloshchapov A.L. Google Android : composants du système et communications réseau. - Saint-Pétersbourg : BHV-Pétersbourg, 2012. - 384 p.

2.Felker D. Android : développement d'applications pour les nuls. - M. : Dialectique, 2012. - 336 p.

3.Hashimi S., Komatineni S., McLean D. Développement d'applications Android. - Saint-Pétersbourg : Peter, 2011. - 736 p.

Les gestionnaires de fichiers sur Android peuvent être un outil pratique pour organiser le stockage de données sur votre smartphone, mais la structure Android elle-même (ou son absence apparente) peut sembler un peu déroutante si vous n'y êtes pas habitué. Les données d'application, les images, la musique - et l'accès à tout cela à partir d'un seul dossier racine - constituent une approche de la structure hiérarchique légèrement différente de celle à laquelle les utilisateurs de PC et de Mac sont habitués, et elle offre aux utilisateurs beaucoup plus d'options qu'iOS.

Sur Android, vous ne pourrez pas accéder aux fichiers système profondément cachés via un gestionnaire de fichiers classique ou en vous connectant à un PC. Mais cela ne signifie pas que vous pouvez supprimer n’importe quel fichier de votre choix sur un coup de tête. Jetons un coup d'œil à la façon dont les dossiers typiques sont organisés dans la mémoire de l'appareil, à quoi ils servent et ce que vous pouvez et ce que vous ne pouvez pas supprimer.

Hiérarchie de la mémoire des appareils Android

Étant donné qu'Android est un système d'exploitation basé sur Linux, le système de fichiers de votre téléphone est également organisé comme Linux. Dans ce système, chaque périphérique dispose de six partitions principales : démarrage, système, récupération, données, cache et divers. Les cartes mémoire microSD ont également leur propre hiérarchie de mémoire. Les appareils équipés d'Android 7.0 Nougat sont capables de se mettre à jour en permanence car une seconde est créée en conjonction avec la partition système et l'une d'elles est mise à jour en arrière-plan, et lors du redémarrage, un changement se produit, permettant au système mis à jour de fonctionner. .

Voici une description rapide du contenu de chaque dossier.

  • botte– Ce dossier contient le noyau, le disque virtuel, etc., c'est-à-dire ce qui est nécessaire pour démarrer le téléphone lorsque vous l'allumez.
  • système– Le dossier système contient les fichiers du système d'exploitation (également appelés image système), qui incluent également l'interface graphique Android et les applications préinstallées.
  • récupération– Une option alternative pour démarrer le système d'exploitation, les programmes du dossier de récupération permettent à l'utilisateur de faire des sauvegardes d'autres dossiers et de les restaurer.
  • données– Le dossier de données stocke les informations utilisateur, des contacts et messages aux applications et à la musique, et vous avez accès à cette section via un navigateur de fichiers. Après une réinitialisation d'usine, cette partition est effacée.
  • cache– Android stocke ici les données et les composants d’application fréquemment utilisés. Cette partition peut être effacée pour résoudre certains problèmes et sera automatiquement restaurée et mise à jour au fil du temps.
  • divers– Cette section contient d'autres informations importantes sur les paramètres système telles que la configuration USB, les paramètres réseau de votre opérateur et d'autres paramètres matériels qui apparaissent sous forme de commutateurs marche/arrêt dans l'interface graphique.

Sans root, les utilisateurs d'Android ne peuvent accéder qu'à la partition de données qui s'ouvre à vous lorsque vous connectez l'appareil à votre PC ou utilisez un navigateur de fichiers. Si la mémoire de votre téléphone peut être étendue à l'aide d'une carte, la mémoire de la carte est également incluse dans cette section avec des données accessibles via un PC ou une visionneuse de fichiers.

En règle générale, vous n'avez accès qu'aux données d'application stockées dans la section des données utilisateur. Pour accéder au reste de la mémoire, vous aurez besoin des droits root

Applications et dossiers dans la section données

Ainsi, en jetant un coup d'œil rapide aux dossiers principaux, nous avons remarqué que nous n'avons pas accès aux fichiers de démarrage, aux fichiers de récupération et/ou aux fichiers système Android lorsque nous visualisons simplement les fichiers à l'aide du navigateur. Ce qui nous amène à une conclusion réconfortante : vous ne pouvez pas simplement provoquer l’effondrement du système par vos actions. Une situation complètement différente se produit lorsque vous disposez des droits root. D'une manière ou d'une autre, vous devez être plus prudent avec ce qui est stocké dans cette section : certaines applications peuvent utiliser les données stockées ici, et leur déplacement ou leur suppression peut conduire à un fonctionnement instable du système.

Voyons maintenant ce qu'il y a dans la section données de votre appareil. Pour rendre cela possible, les téléphones équipés des versions Android Marshmallow ou Nougat disposent de leur propre gestionnaire de fichiers, qui donne accès à l'intégralité de la partition. Cette option se trouve dans le menu Paramètres-Mémoire-Stockage-Autre. Certains appareils exécutant d'anciennes versions d'Android peuvent ou non disposer de leur propre gestionnaire de fichiers, selon le fabricant.

Alternativement, il existe de nombreuses applications tierces disponibles sur le Play Store qui remplissent le même rôle, telles que FX File Explorer ou Total Commander.

Vous pouvez également gérer vos fichiers depuis votre PC grâce à une connexion USB. Assurez-vous simplement que votre téléphone est en mode MTP (File Transfer) afin que vous puissiez voir tous vos fichiers.


Vous pouvez accéder à la mémoire de votre appareil à l'aide d'un PC ou directement via un navigateur de fichiers

Si vous avez l'impression que la mémoire de votre appareil semble pleine et qu'il y a trop de dossiers, examinez-les de plus près. Vous verrez de nombreux dossiers associés aux applications, peut-être même des restes d'applications que vous avez déjà supprimées. En règle générale, il est préférable de laisser les dossiers d'application seuls, mais si vous vous souvenez que l'application a été désinstallée et que le dossier reste, sa suppression ne causera aucun dommage. Très probablement, il est vide ou contient des fichiers journaux inutiles.

Même si vous n'avez pas installé beaucoup d'applications, cette section de données utilisateur peut contenir par défaut un certain nombre de dossiers - ils stockent vos contacts, votre musique, vos images et tout le reste. Voici les dossiers d’applications non tierces les plus basiques que vous pouvez trouver.

  • Android– Il s’agit de l’emplacement par défaut où le cache de l’application et les données sont enregistrés. Il n'est pas recommandé de supprimer ce dossier si vous ne souhaitez pas perdre les données de l'application. La suppression de ce dossier peut empêcher certains d'entre eux de fonctionner correctement.
  • Alarmes, sonneries, notifications– comme leurs noms l'indiquent, ces dossiers stockent des fichiers audio pour les alarmes, les sonneries et les notifications, qui peuvent être utilisés à la fois par des applications par défaut et par des applications tierces.
  • Papier carton– les données d'un certain nombre d'applications VR sont stockées ici, et s'il n'y en a pas, elles restent vides.
  • DCIM– voici les photos que vous avez prises à l’aide de votre application appareil photo principale. Vous pouvez également voir un tel dossier sur une carte microSD si vous y enregistrez également des photos.
  • Téléchargements– c’est ici que se trouve tout ce que vous avez téléchargé dans votre navigateur Web, comme Chrome ou Firefox.
  • Images, musique, films, vidéo– Ce sont les dossiers par défaut utilisés par vos applications multimédias. Certaines applications vous permettent de désigner d'autres dossiers, mais la plupart des lecteurs multimédias utiliseront par défaut ces répertoires. Les captures d'écran sont le plus souvent enregistrées dans le dossier images.
  • Baladodiffusions– Ce dossier est utilisé par un certain nombre d'applications pour séparer les podcasts des autres fichiers musicaux. Si vous n'utilisez pas d'applications de podcast, elle sera vide.

Alors, quels dossiers puis-je (ou devrais-je) supprimer ?

Si vous n'êtes pas sûr, ne le supprimez pas. Cela est vrai pour tous les dossiers d'application et ne doit pas être touché à moins que vous sachiez exactement ce que vous voulez faire. Il est absolument sûr d'ajouter et de supprimer des fichiers de n'importe quel dossier multimédia, mais essayez de ne pas détruire le dossier lui-même dans la précipitation pour rétablir l'ordre. Si vous voyez que le dossier est vide, par exemple s'il n'y a rien dans le dossier Alarmes, vous pensez peut-être qu'il n'est pas nécessaire en lui-même. Mais d’un autre côté, le dossier ne prend pas beaucoup de place. Et peut-être que certaines applications en auront besoin plus tard, alors est-il vraiment nécessaire de le supprimer ?

Au fil du temps, la mémoire interne de votre appareil contiendra beaucoup plus de dossiers que ceux répertoriés ci-dessus. Vous installerez et désinstallerez de plus en plus d’applications. Par conséquent, cela ne fait jamais de mal de ranger votre appareil, à moins que vous ne déplaciez rarement des fichiers sur votre téléphone, que vous les téléchargiez et les supprimiez. Et pourtant, supprimer un dossier vide ne vous libérera pas d’espace mémoire supplémentaire. Donc, si vous voulez gagner une place, il est préférable de regarder quelles applications/films vous pouvez supprimer et dont vous n’avez pas besoin, que vous ne regarderez pas, etc.

Maintenant que vous avez une image plus complète de ce que ces dossiers sont stockés dans la mémoire de votre appareil, il vous sera plus facile de gérer vos fichiers sans craindre de « faire quelque chose de mal ».

  • / - Le dossier racine.
  • /poubelle- un dossier contenant des fichiers exécutables et des liens vers des fichiers exécutables. Les fichiers exécutables sont des programmes qui s'exécutent au démarrage du système, ainsi que les programmes les plus nécessaires accessibles à tous. Exemple: ls, monter, pwd, décompresser.
  • /données- un dossier contenant des données sur la synchronisation et les comptes, les mots de passe des points d'accès wifi et les paramètres VPN, etc.
  • /données/application– un dossier contenant les programmes et jeux installés.
  • /données/données– un dossier contenant les données de l'application, leurs paramètres, les sauvegardes de jeu et d'autres informations.
  • /data/dalvik-cache- zone de mémoire cache logicielle pour le programme Dalvik. Dalvik est une machine virtuelle Java, qui sert de base à l'exécution de programmes portant l'extension *.apk. Afin d'accélérer le lancement des programmes, un cache est créé.
  • /dév- un dossier contenant les fichiers de divers appareils, réels et virtuels, ainsi que les appareils qui n'existent pas, mais qui pourraient exister.
  • /etc- un dossier contenant les fichiers de configuration utilisés lors du chargement du système d'exploitation et lors du fonctionnement de divers programmes.
  • /lib- un dossier contenant les bibliothèques de fonctions nécessaires à divers programmes et au compilateur du langage C, ainsi que des modules (pilotes de périphériques) connectés au noyau.
  • /lib/modules/- un dossier contenant les modules (pilotes de périphériques) du noyau qui portent l'extension .ko. Ce dossier contient des sous-dossiers correspondant aux versions du noyau (par exemple, 2.6.32.9-default) installées sur le système. Autrement dit, chaque version du noyau possède son propre ensemble de modules. C’est très important et vous devez y prêter attention. Souvent, lors de la compilation d'un noyau, ils oublient de changer de version ; lorsqu'un nouveau noyau est chargé, il utilise les modules de la version précédente et le système ne démarre pas. La version actuelle du noyau peut être trouvée à l'aide de la commande uname -r, la version renvoyée correspondra certainement au nom de l'un des dossiers de /lib/modules/ .
  • /mois- contient des dossiers pour les systèmes de fichiers temporairement montés.
  • /proc- un dossier virtuel contenant tous les détails du système Android, y compris le noyau, les processus et les paramètres de configuration. Le dossier /proc est décrit plus en détail dans un article séparé.
  • /sbin- un dossier contenant des fichiers exécutables de programmes conçus pour contrôler le système lui-même. Exemple: siconfig , mec, mdev, vconfig .
  • /carte SD- un dossier contenant les fichiers et dossiers sur la carte mémoire SD (si installée).
  • /sys un dossier contenant la configuration actuelle du système pour le moment. /sys très étroitement lié à udev si vous connectez (déconnectez) des appareils, le contenu du répertoire /sys change de manière dynamique. Vous pouvez voir un exemple. Exécutez la commande ls /sys/bus/usb/devices/ pour afficher les périphériques USB actuels dans le système. Connectez maintenant le lecteur flash et exécutez la commande ls /sys/bus/usb/devices/ encore. Vous verrez qu'il y a désormais plus d'appareils.
  • /système- un dossier (caché par défaut) contenant les fichiers système et les dossiers contenant les données et tout le nécessaire au fonctionnement du système d'exploitation Android.
  • /système/application– un dossier contenant les applications système (SMS, téléphone, calendrier, paramètres, etc.), ainsi que les applications installées par le fabricant de l'appareil (widgets de marque, fonds d'écran animés, etc.).
  • /système/polices– dossier avec les polices système.
  • /système/média– un dossier contenant des sonneries standards, des notifications, des alarmes et des sons d'interface, ainsi qu'une animation de démarrage.
  • /système/build.prop– un fichier contenant un grand nombre de paramètres, tels que la densité de l'écran, le délai du capteur de proximité, le contrôle wifi, le nom et le fabricant de l'appareil, et bien d'autres paramètres.

L'un des systèmes d'exploitation les plus populaires aujourd'hui est Android. Il est installé sur des millions d'appareils mobiles. Le système est un ensemble de dossiers et de fichiers qui assurent son fonctionnement. Mais vous êtes-vous déjà demandé ce que contenait chaque dossier ? Certains sont assez lourds, la main est donc tentée de les retirer. Avant de faire cela, vous devez absolument vous familiariser avec la responsabilité de chaque dossier, ainsi que son importance pour le système d'exploitation. Nous vous expliquerons également les moyens de supprimer un dossier inutile.

Répertoires de clés de base dans le système d'exploitation Android

La première priorité avant de supprimer est de savoir ce que contient le répertoire, car cela détermine s'il peut être supprimé ou non. Si vous effacez des fichiers importants par erreur, vous pouvez non seulement perturber le fonctionnement de certaines applications, mais également rendre l'ensemble du système d'exploitation complètement inutilisable.

Il convient de noter que la liste des dossiers peut différer selon l'appareil et la version du système Android. De plus, des applications spécifiques peuvent créer leurs propres dossiers dans la mémoire du téléphone Android. Voyons quels répertoires sont disponibles sur Android.

Le cache est un dossier pour stocker des fichiers temporaires. Il peut contenir une mise à jour du système. Si vous ne prévoyez pas de mettre à jour vers une version plus récente d'Android, vous n'avez pas besoin du fichier de mise à jour. Vous pouvez supprimer ce dossier, et dans certains cas, c'est même nécessaire.

Les données sont l'un des plus grands catalogues qui, comme son nom l'indique, contient une variété de données. Cela inclut les données de compte, les informations sur les mots de passe enregistrés, les points d'accès Wi-Fi, etc. Puisque ce dossier contient beaucoup d’informations, regardons ses sous-répertoires :

  1. App – un répertoire contenant les fichiers d’installation de diverses applications. Vous pouvez le supprimer si vous n'avez pas besoin de toutes les applications téléchargées sur votre téléphone ;
  2. Données – incluent les paramètres, les sauvegardes et autres informations de service nécessaires au fonctionnement d'applications spécifiques. S'il n'y a aucune donnée importante pour vous dans les applications, vous pouvez également les supprimer ;
  3. Le Presse-papiers est un presse-papiers de données spécial qui contient également les dernières captures d'écran. Il est possible de supprimer ce dossier, mais ce n'est pas recommandé ;
  4. Dalvik-cache est une zone de cache pour un programme appelé Davlink. Cette application est une machine virtuelle Java qui permet au téléphone d'exécuter les fichiers apk de l'application. Pour accélérer autant que possible ce processus, les fichiers sont créés dans la mémoire cache. Il est recommandé de nettoyer le contenu régulièrement, mais vous ne devez pas supprimer Dalvik-cache.

Le dossier efs contient des informations sur le numéro de série du téléphone (IMEI), l'adresse MAC, Bluetooth et Wi-Fi. Ce répertoire ne peut pas être supprimé. De plus, il est recommandé de faire une sauvegarde de ce dossier, car sa suppression entraînerait la perte du numéro unique de votre smartphone.

Le répertoire etc contient des fichiers de configuration, principalement utilisés lors du chargement du système d'exploitation, des processus de divers programmes, par exemple pour déterminer la localisation GPS. C'est l'un des répertoires système qui ne peut pas être supprimé.

Répertoire lib – il contient diverses bibliothèques nécessaires au bon fonctionnement des fonctions et des modules du programme. Ce dossier contient également des fichiers qui garantissent le fonctionnement des pilotes. Il ne peut pas être supprimé.

Le répertoire mnt contient des images des systèmes montés. Les partitions d'une carte mémoire installée, d'une mémoire interne ou d'autres périphériques virtuels peuvent se trouver ici. Bien entendu, vous ne pouvez pas non plus supprimer ce répertoire.

Le dossier proc – il contient toutes les informations clés concernant le système d’exploitation Android installé : informations sur le noyau, les paramètres de configuration et le matériel. Tous les fichiers et dossiers existants sont virtuels et pèsent zéro octet. Le système les crée automatiquement lorsque l'utilisateur y accède. Ce dossier ne peut pas être supprimé avec les droits d'utilisateur normaux.

Le répertoire sbin est l'un des dossiers clés nécessaires au fonctionnement du téléphone. Il contient des fichiers exécutables de tous les programmes conçus pour gérer le système. Il ne peut donc pas être supprimé.

Le répertoire sys contient la configuration actuelle du système. Il s'agit d'un répertoire dynamique. Les informations qu'il contient changent constamment. Ce dossier ne peut pas être effacé.

La section système est la « colonne vertébrale » de l'ensemble du système d'exploitation, car c'est là que se trouvent tous les fichiers, sans lesquels Android ne peut pas fonctionner. Le répertoire système (comme tout autre répertoire interne) ne peut pas être supprimé. Pour faire connaissance, regardons de plus près le contenu de ce répertoire :

  1. Application – fond d'écran du système, les applications standard (calendrier, bloc-notes, SMS) se trouvent dans ce dossier.
  2. Bin comprend des fichiers exécutables et des liens ;
  3. Build.prop contient un grand nombre de paramètres pour le téléphone, par exemple, combien de temps le capteur est retardé après avoir appuyé sur, quelle est la densité de l'écran, et plus encore ;
  4. Polices – informations sur toutes les polices standard prises en charge sur le téléphone.
  5. Framework – tout ce qui est nécessaire à l'interface, notamment les icônes, les rideaux et autres éléments graphiques ;
  6. Lib – bibliothèque d'applications ;
  7. Médias – toutes les mélodies et sons standards (réveil, notifications SMS, tonalités d’appel) ;
  8. Tts comprend des packs de langue.

Documents – un dossier pouvant contenir divers documents, notamment des fichiers .doc et .pdf. Si le contenu du dossier ne vous intéresse pas, vous pouvez le supprimer.

Bluetooth – contient tous les fichiers reçus par l'appareil via Bluetooth. S'il ne contient aucune donnée importante, il est supprimé sans problème. Il peut être localisé non seulement dans la mémoire interne, mais également sur une carte SD.

DCIM est un répertoire spécial pour enregistrer les photos prises avec l'appareil photo de votre smartphone. En règle générale, il comprend une section Appareil photo, dans laquelle se trouvent toutes les photos. Si la photo dont vous avez besoin ne se trouve pas sur votre téléphone, vous pouvez la supprimer. Des sections telles que Images, Images, Audio, Musique (s'il n'y a pas de fichiers importants à l'intérieur) peuvent également être supprimées.

Méthodes de suppression

Comment puis-je supprimer un dossier spécifique ? La première consiste à utiliser des fonctions standard. Pour ce faire, vous avez besoin de :

Veuillez noter que les outils standard n'affichent pas tous les dossiers et fichiers existants, car les fichiers système sont souvent masqués. Tout gestionnaire de fichiers tiers, par exemple le programme ES Explorer, vous aidera à en savoir plus. Vous pouvez le télécharger depuis le Google Play Store. L'application offre de nombreuses opportunités. Avec lui, vous pouvez afficher les dossiers existants et en supprimer certains. Pour ce faire, vous avez besoin de :

Il convient de noter que la suppression des dossiers système est impossible car l'utilisateur dispose de droits d'accès limités. Ils ne peuvent être supprimés qu'en obtenant des droits de superutilisateur spéciaux (l'équivalent sous Windows est Administrateur).

En contact avec

Introduction

En communiquant sur des forums et en étant curateur de plusieurs sujets, je suis souvent confronté à une incompréhension totale des débutants sur le design d'Android. "Eh bien, pourquoi l'utilisateur moyen a-t-il besoin de savoir cela ?" - vous dites. Et ici, je suis d'accord avec vous, posant une contre-question : "Pourquoi alors un utilisateur ordinaire se retrouve-t-il dans la jungle du firmware, de l'accès root et des réglages du système, sans rien y comprendre ?" C'est ce qui m'a poussé à écrire cet article, dans lequel je vais essayer, dans un langage ordinaire et compréhensible, de transmettre des choses complexes.

Le matériel s'adresse principalement aux utilisateurs ordinaires. Par conséquent, des informations concises et superficielles seront présentées ici sans profondeurs ni nuances techniques.

  1. Sections de mémoire interne.
  2. Chargeur de démarrage, récupération, adb Etdémarrage rapide
  3. Internalités du système.
  4. Racine.


1. Sections de mémoire interne

La mémoire interne d'un appareil Android est divisée en plusieurs lecteurs logiques (partitions).

Je ne donnerai que les principaux :


Fig. 1

Chargeur de démarrage– voici le firmware (bootloader) qui permet de lancer le système d'exploitation, la récupération et d'autres modes de service.

Récupération– comme son nom l'indique, un menu de récupération technique ou simplement Recovery est installé ici.

Botte- le cœur de l'OS Android, voici le noyau, les pilotes et les paramètres de gestion du processeur et de la mémoire.

Système– la partition système, qui contient tous les fichiers nécessaires au fonctionnement de l’OS Android, c’est comme le dossier Windows sur votre lecteur C:\ (ci-après je ferai une association avec le système d'exploitationles fenêtres)

Données– une section pour installer les applications et stocker leurs données. (Programme des dossiers)

Utilisateur– c'est la célèbre carte SD ou, plus simplement, un emplacement pour les fichiers utilisateur (Mes documents). Ici, je suis obligé de faire une digression, parce que... le placement de cette section a plusieurs options :

  • La partition ne se trouve pas dans la mémoire interne, mais à la place, un lecteur externe est utilisé - l'option la plus populaire. (Fig. 1)
  • Sur les appareils dotés d'une grande mémoire intégrée, cette section est considérée commecarte SD , et la carte mémoire externe est considérée commecarte SD 2 ouextsd (il peut y avoir d'autres options de nom). Généralement trouvé sur les appareils avecAndroid3.2. (Fig.2 Option 1)
  • Cette option a remplacé la version précédente, ainsi qu'Android 4.0. ChapitreUtilisateur remplacé par un dossiermédias sur la rubriqueDonnées , qui permettait d'utiliser toute la mémoire disponible pour l'utilisateur pour installer des programmes et stocker des données, et non la quantité que le constructeur nous avait allouée. Autrement ditcarte SD Etdonnées sont un tout. (Fig.2 Option 2)


Figure 2

2. Chargeur de démarrage Récupération BAD et démarrage rapide

Maintenant que nous savons ce qui se trouve où, voyons pourquoi il se trouve là.

Commençons avec Chargeur de démarrage. C'est le bootloader qui lance Android, la récupération, etc. Lorsque nous appuyons sur le bouton d'alimentation, le chargeur de démarrage démarre et, s'il n'y a pas de commandes supplémentaires (touches enfoncées), commence le chargement botte. Si une combinaison de touches a été appuyée (chaque appareil a la sienne), alors elle se lance, selon la commande, recovery, fastboot ou apx. La figure ci-dessous montre clairement ce qui déclenche Chargeur de démarrage et comment les sections sont interconnectées.


Figure 3

Comme le montre la figure 3, section Récupération n'affecte pas le chargement du système d'exploitation Android, mais pourquoi est-ce nécessaire alors ? Essayons de le comprendre.

Récupération (récupération) est essentiellement un petit utilitaire basé sur le noyau Linux et chargé indépendamment d'Android. Ses fonctionnalités standards ne sont pas riches : vous pouvez réinitialiser l'appareil aux paramètres d'usine ou mettre à jour le firmware (pré-téléchargé surcarte SD). Mais, grâce aux artisans, nous avons modifié les récupérations grâce auxquelles vous pouvez installer des modifications (coutume) firmware, configurer Android, créer des sauvegardes et bien plus encore. La présence ou l'absence de récupération, ainsi que sa version, n'affectent pas les performances du système d'exploitation Android (une question très courante sur les forums).

Des lecteurs particulièrement attentifs l’auront peut-être remarqué Figure 3 quelques Démarrage rapide. Il s'agit d'une interface permettant de travailler directement avec les partitions de mémoire interne à l'aide de la ligne de commande. Grâce à lui, vous pouvez flasher la récupération, la version du noyau ou du nouveau firmware, ou formater (supprimer toutes les informations) une section ou une autre.

Puisque nous parlons d'interfaces, je veux en parler d'une autre, assez connue - adb (Android déboguer pont) . C'est ce qu'on appelle Mode débogage et il est nommé ainsi pour une raison : grâce à lui, vous pouvez surveiller le travail du système dans son ensemble et des applications individuelles. Mais ce n'est pas tout, avec l'aide adb Vous pouvez obtenir un accès complet au système de fichiers de l'appareil et modifier les fichiers système, ou extraire des informations importantes lorsque le chargement de votre appareil est bloqué. Toutes les fonctions Mode débogage Je ne le décrirai pas parce que mon objectif est de transmettre des informations générales, et non sur les fonctions d'un mode particulier.

3. Internalités du système

Après avoir compris la théorie, lançons le système d'exploitation Android.

Appuyez sur le bouton d'alimentation et ça démarre Chargeur de démarrage qui charge Cœur(démarrage), il s'exécute à son tour système(Système), eh bien, il est déjà en train de charger programmes(données) et espace utilisateur (utilisateur). ( Fig.3)

Passons maintenant au répertoire racine et examinons l'intérieur du système d'exploitation Android lui-même :


(Fig.4)

Dans ce diagramme, j'ai fourni uniquement les répertoires nécessaires à titre de référence. En fait, il y en a beaucoup plus et il n'y a qu'un seul dossier à examiner Système vous aurez besoin d'un article entier.

Et donc, dossier données. Comme son nom l’indique, cela a quelque chose à voir avec les données, mais de quel type ? Oui, pour presque tout le monde, cela inclut la synchronisation et les données de compte, les mots de passe des points d'accès wifi et les paramètres VPN, etc. Entre autres choses, vous pouvez trouver ici des dossiers application, données Et Dalvik- cache– regardons leur objectif :

  • application– les programmes et les jeux sont installés ici.
  • données– les données d'application, les paramètres, les sauvegardes de jeu et d'autres informations sont stockées ici.
  • Dalvik- cache- zone de mémoire cache logicielle pour le programme Dalvik. Dalvik est une machine virtuelle Java, qui sert de base à l'exécution de programmes portant l'extension *.apk. Afin d'accélérer le lancement des programmes, leur cache est créé.

Dossier Système stocke les données du système et tout ce qui est nécessaire au fonctionnement du système d'exploitation. Examinons certains de ces dossiers :

  • application– voici les applications système (SMS, téléphone, calendrier, paramètres, etc.), ainsi que les applications installées par le fabricant de l'appareil (widgets de marque, fonds d'écran animés, etc.).
  • polices– polices système
  • médias- contient des sonneries standard, des notifications, des alarmes et des sons d'interface, ainsi qu'une animation de démarrage (bootanimation)
  • construire. soutenir– Ce fichier est presque le premier à être mentionné dans les conversations et les articles sur le réglage fin du système. Il contient un grand nombre de paramètres, tels que la densité de l'écran, le délai du capteur de proximité, le contrôle Wi-Fi, le nom et le fabricant de l'appareil, ainsi que de nombreux autres paramètres.

4. Racine

- Savoir ce qu'il y a dans quel dossier est une bonne chose, mais pouvez-vous faire quelque chose ?

Oui! Mais nous avons besoin de droits superutilisateur (racine) ou, si nous faisons une analogie avec Windows, les droits d'administrateur. Au départ, tous les appareils Android sont livrés sans racine droits pour l'utilisateur final, c'est-à-dire Lorsque nous achetons un appareil, nous n’en sommes pas propriétaires à part entière. Ceci est fait à la fois pour se protéger contre les logiciels malveillants et contre l'utilisateur lui-même - après tout, entre des mains incompétentes, un accès complet au système peut entraîner la « mort » du système d'exploitation et la nécessité ultérieure de flasher l'appareil.

"Eh bien, à quoi sert une chose aussi dangereuse ?"- tu demandes.

Maintenant, je vais vous dire :

  • La possibilité de sauvegarder les données et de les restaurer après un flashage ou une suppression accidentelle.
  • Affiner le système manuellement ou à l'aide de programmes spéciaux.
  • Suppression d'applications système, de sonneries, de fonds d'écran, etc.
  • Changer l'apparence du système d'exploitation (par exemple, afficher la charge de la batterie en pourcentage)
  • Ajout de fonctionnalités (soutienannonce- ponctuellement réseaux par exemple)

Cette liste peut être poursuivie pendant longtemps, mais je pense que ces exemples suffiront à se faire une idée des capacités et de l'étendue de l'application des privilèges root.

Tout cela est génial, mais désormais n'importe quel programme pourra accéder au « cœur » du système d'exploitation et à mes données ?

Non. Vous décidez si vous autorisez ou non telle ou telle application à obtenir un accès root. Pour cela, il existe un programme appelé Superuser ou sa sœur avancée SuperSU. Sans ce programme ou un programme similaire, il n'est pas possible d'utiliser root.

Épilogue

Comme vous pouvez le constater, Android n’est pas si compliqué. J'espère qu'après avoir lu l'article, vous avez appris quelque chose de nouveau ou reçu une réponse à une question qui vous intéresse depuis longtemps.

Je prends congé alors, rendez-vous dans les commentaires. 😉

Vous êtes-vous déjà demandé comment fonctionnent fastboot ou ADB ? Ou pourquoi est-il presque impossible de transformer un smartphone sous Android en brique ? Ou peut-être avez-vous longtemps voulu savoir où réside la magie du framework Xposed et pourquoi les scripts de démarrage /system/etc/init.d sont nécessaires ? Et la console de récupération ? Est-ce une partie d'Android ou une chose en soi et pourquoi la récupération régulière ne convient-elle pas à l'installation d'un micrologiciel tiers ? Vous trouverez des réponses à toutes ces questions et à bien d’autres dans cet article.

Comment fonctionne Android

Vous pouvez découvrir les capacités cachées des systèmes logiciels en comprenant le principe de leur fonctionnement. Dans certains cas, cela est difficile à faire, car le code système peut être fermé, mais dans le cas d'Android, nous pouvons étudier l'ensemble du système de fond en comble. Dans cet article, je ne parlerai pas de toutes les nuances d'Android et me concentrerai uniquement sur le démarrage du système d'exploitation et les événements qui se produisent dans l'intervalle entre l'appui sur le bouton d'alimentation et l'apparition du bureau.

En cours de route, j'expliquerai ce que nous pouvons changer dans cette chaîne d'événements et comment les développeurs de micrologiciels personnalisés utilisent ces capacités pour mettre en œuvre des éléments tels que le réglage des paramètres du système d'exploitation, l'extension de l'espace de stockage des applications, la connexion du swap, diverses personnalisations et bien plus encore. Toutes ces informations peuvent être utilisées pour créer votre propre firmware et mettre en œuvre divers hacks et modifications.

La première étape. ABOOT et table de partition

Tout commence par le chargeur de démarrage principal. Après la mise sous tension, le système exécute le code du chargeur de démarrage stocké dans la mémoire permanente de l'appareil. Ensuite, il transfère le contrôle au chargeur de démarrage aboot avec prise en charge intégrée du protocole fastboot, mais le fabricant de la puce mobile ou du smartphone/tablette a le droit de choisir n'importe quel autre chargeur de démarrage de son choix. Par exemple, Rockchip utilise son propre chargeur de démarrage qui n'est pas compatible avec le démarrage rapide et nécessite des outils propriétaires pour le flasher et le gérer.

Le protocole fastboot, quant à lui, est un système de gestion du chargeur de démarrage à partir d'un PC, qui vous permet d'effectuer des actions telles que le déverrouillage du chargeur de démarrage, le flashage d'un nouveau noyau et la récupération, l'installation du firmware et bien d'autres. La raison d'être de fastboot est de pouvoir restaurer un smartphone à son état d'origine dans une situation où tous les autres moyens échouent. Fastboot restera en place même si, à la suite d'expériences, vous effacez toutes les partitions de mémoire NAND contenant Android et la récupération de votre smartphone.

Après avoir reçu le contrôle, aboot vérifie la table de partition et transfère le contrôle au noyau flashé dans la partition nommée boot, après quoi le noyau extrait l'image RAM de la même partition en mémoire et commence à charger Android ou la console de récupération. La mémoire NAND des appareils Android est divisée en six sections requises sous condition :

  • boot - contient le noyau et le disque RAM, généralement d'une taille d'environ 16 Mo ;
  • récupération - console de récupération, composée d'un noyau, d'un ensemble d'applications console et d'un fichier de paramètres, d'une taille de 16 Mo ;
  • système - contient Android, dans les appareils modernes, la taille est d'au moins 1 Go ;
  • cache - conçu pour stocker les données mises en cache, également utilisé pour sauvegarder le micrologiciel lors d'une mise à jour OTA et a donc une taille similaire à la taille de la partition système ;
  • données utilisateur - contient les paramètres, les applications et les données utilisateur, tout l'espace mémoire NAND restant lui est alloué ;
  • misc - contient un indicateur qui détermine dans quel mode le système doit démarrer : Android ou récupération.

En plus d'eux, il peut y avoir d'autres sections, mais le balisage général est déterminé au stade de la conception du smartphone et, en cas de démarrage, est intégré au code du chargeur de démarrage. Cela signifie que : 1) la table de partition ne peut pas être supprimée, puisqu'elle peut toujours être restaurée à l'aide de la commande fastboot oem format ; 2) pour changer la table de partition, vous devrez déverrouiller et reflasher le bootloader avec de nouveaux paramètres. Il existe cependant des exceptions à cette règle. Par exemple, le chargeur de démarrage du même Rockchip stocke des informations sur les partitions dans le premier bloc de mémoire NAND, il n'est donc pas nécessaire de flasher le chargeur de démarrage pour le modifier.

La section divers est particulièrement intéressante. On suppose qu'il a été créé à l'origine pour stocker divers paramètres indépendamment du système principal, mais pour le moment, il n'est utilisé que dans un seul but : indiquer au chargeur de démarrage à partir de quelle partition le système doit être chargé - démarrage ou récupération. Cette fonctionnalité, en particulier, est utilisée par l'application ROM Manager pour redémarrer automatiquement le système en mode récupération avec installation automatique du micrologiciel. Sur cette base, le mécanisme de double démarrage Ubuntu Touch est construit, qui met le chargeur de démarrage Ubuntu en mode récupération et vous permet de contrôler quel système démarrera la prochaine fois. Effacé la partition diverse - chargements Android, remplissage de données - chargements de récupération... c'est-à-dire Ubuntu Touch.

Deuxième étape. Section de démarrage

Si la section misc n'a pas d'indicateur de démarrage de récupération, aboot transfère le contrôle au code situé dans la section de démarrage. Ce n'est rien de plus que le noyau Linux ; il est situé au début de la section, et immédiatement suivi d'une image disque RAM emballée à l'aide des archiveurs cpio et gzip, contenant les répertoires nécessaires au fonctionnement d'Android, le système d'initialisation init et d'autres outils. Il n'y a pas de système de fichiers sur la partition de démarrage ; le noyau et le disque RAM se suivent simplement. Le contenu du disque RAM est :

  • data - répertoire pour monter la partition du même nom ;
  • dev - fichiers de périphérique ;
  • proc - procfs est monté ici ;
  • res - un ensemble d'images pour le chargeur (voir ci-dessous) ;
  • sbin - un ensemble d'utilitaires et de démons (adbd, par exemple) ;
  • sys - sysfs est monté ici ;
  • système - répertoire pour monter la partition système ;
  • chargeur - application pour afficher le processus de charge ;
  • build.prop - paramètres système ;
  • init - système d'initialisation ;
  • init.rc - paramètres du système d'initialisation ;
  • ueventd.rc - paramètres du démon uventd inclus dans init.

C'est, pour ainsi dire, le squelette du système : un ensemble de répertoires pour connecter les systèmes de fichiers à partir des partitions de mémoire NAND et un système d'initialisation qui gérera le reste du travail de démarrage du système. L'élément central ici est l'application init et sa configuration init.rc, dont je parlerai en détail plus tard. En attendant, j'aimerais attirer votre attention sur les fichiers charger et ueventd.rc, ainsi que sur les répertoires sbin, proc et sys.

Le fichier du chargeur est une petite application dont le seul travail est d'afficher l'icône de la batterie. Cela n'a rien à voir avec Android et est utilisé lorsque l'appareil est connecté au chargeur à l'état éteint. Dans ce cas, Android ne se charge pas et le système charge simplement le noyau, connecte le disque RAM et démarre le chargeur. Ce dernier affiche une icône de batterie dont l'image, dans tous les états possibles, est stockée dans des fichiers PNG ordinaires dans le répertoire res.

Le fichier ueventd.rc est une configuration qui détermine quels fichiers de périphérique dans le répertoire sys doivent être créés lors du démarrage du système. Dans les systèmes basés sur le noyau Linux, l'accès au matériel s'effectue via des fichiers spéciaux dans le répertoire dev, et le démon ueventd, qui fait partie d'init, est responsable de leur création dans Android. Dans une situation normale, il fonctionne en mode automatique, en acceptant les commandes pour créer des fichiers à partir du noyau, mais certains fichiers doivent être créés indépendamment. Ils sont répertoriés dans ueventd.rc.

Le répertoire sbin en stock Android ne contient généralement rien d'autre que adbd, c'est-à-dire le démon ADB, qui est responsable du débogage du système à partir du PC. Il s'exécute à un stade précoce du démarrage du système d'exploitation et vous permet d'identifier d'éventuels problèmes lors de la phase d'initialisation du système d'exploitation. Dans les firmwares personnalisés, vous pouvez trouver de nombreux autres fichiers dans ce répertoire, par exemple mke2fs, qui peuvent être requis si les partitions doivent être reformatées en ext3/4. De plus, les moddeurs y placent souvent une BusyBox, avec laquelle vous pouvez appeler des centaines de commandes Linux.

Le répertoire proc est standard pour Linux ; dans les prochaines étapes de démarrage, init s'y connectera procfs, un système de fichiers virtuel qui donne accès aux informations sur tous les processus du système. Le système connectera sysfs au répertoire sys, qui ouvre l'accès aux informations sur le matériel et ses paramètres. En utilisant sysfs, vous pouvez, par exemple, mettre l'appareil en veille ou modifier l'algorithme d'économie d'énergie utilisé.

Le fichier build.prop est conçu pour stocker les paramètres Android de bas niveau. Plus tard, le système réinitialisera ces paramètres et les écrasera avec les valeurs du fichier system/build.prop actuellement inaccessible.


Points à retenir du texte

  • Fastboot restera en place même si, à la suite d'expériences, vous effacez le contenu de toutes les sections de mémoire NAND de votre smartphone
  • La section de récupération est complètement autonome et contient un système d'exploitation miniature qui n'a aucun rapport avec Android
  • En modifiant légèrement le fichier fstab, on peut forcer init à démarrer le système depuis la carte mémoire

Deuxième étape, alternative. Section de récupération

Si l'indicateur de démarrage de récupération dans la section misc est activé ou si l'utilisateur allume le smartphone avec la touche de réduction du volume enfoncée, aboot transférera le contrôle au code situé au début de la section de récupération. Comme la partition de démarrage, elle contient le noyau et un disque RAM, qui est décompressé en mémoire et devient la racine du système de fichiers. Cependant, le contenu du disque RAM est ici quelque peu différent.

Contrairement à la partition de démarrage, qui fait office de lien de transition entre les différentes étapes de chargement de l'OS, la partition de récupération est totalement autosuffisante et contient un système d'exploitation miniature qui n'est en aucun cas connecté à Android. Recovery possède son propre noyau, son propre ensemble d'applications (commandes) et sa propre interface qui permet à l'utilisateur d'activer les fonctions de service.

Dans une récupération standard (stock), il n'y a généralement que trois fonctions de ce type : installation du micrologiciel signé avec la clé du fabricant du smartphone, effacement et redémarrage. Les récupérations tierces modifiées, telles que ClockworkMod et TWRP, ont beaucoup plus de fonctions. Ils peuvent formater des systèmes de fichiers, installer un micrologiciel signé avec n'importe quelle clé (lire : personnalisé), monter des systèmes de fichiers sur d'autres partitions (à des fins de débogage du système d'exploitation) et inclure la prise en charge des scripts, qui vous permet d'automatiser le processus du micrologiciel et de nombreuses autres fonctions.

À l'aide de scripts, par exemple, vous pouvez vous assurer qu'après le démarrage, la récupération trouve automatiquement le micrologiciel nécessaire sur la carte mémoire, les installe et redémarre sous Android. Cette fonctionnalité est utilisée par le ROM Manager, les outils de flashage automatique, ainsi que le mécanisme de mise à jour automatique de CyanogenMod et d'autres micrologiciels.

La récupération personnalisée prend également en charge les scripts de sauvegarde situés dans le répertoire /system/addon.d/. Avant de flasher, la récupération vérifie les scripts et les exécute avant de flasher le micrologiciel. Grâce à de tels scripts, les gapps ne disparaissent pas après l'installation d'une nouvelle version du firmware.

commandes de démarrage rapide

Pour accéder à fastboot, vous devez installer le SDK Android, connecter votre smartphone à votre PC à l'aide d'un câble et l'allumer en maintenant les deux boutons de volume enfoncés. Après cela, vous devez accéder au sous-répertoire platform-tools du SDK et exécuter la commande

Appareils à démarrage rapide

Le nom de l'appareil sera affiché à l'écran. Autres commandes disponibles :

  • déverrouillage OEM Fatsboot- déverrouillage du bootloader sur les Nexus ;
  • mettre à jour le fichier.zip- installation du firmware ;
  • démarrage flash boot.img- flasher l'image de la partition de démarrage ;
  • récupération flash recovery.img- flasher l'image de la partition de récupération ;
  • système flash système.img- flasher l'image système ;
  • format OEM- restauration d'une table de partition détruite ;

Troisième étape. Initialisation

Ainsi, après avoir reçu le contrôle, le noyau connecte le disque RAM et, après avoir initialisé tous ses sous-systèmes et pilotes, démarre le processus d'initialisation, qui lance l'initialisation d'Android. Comme je l'ai déjà dit, init possède un fichier de configuration init.rc, à partir duquel le processus apprend exactement ce qu'il doit faire pour faire démarrer le système. Dans les smartphones modernes, cette configuration a une longueur impressionnante de plusieurs centaines de lignes et est également équipée d'une bande-annonce de plusieurs configurations enfants connectées à la configuration principale à l'aide de la directive d'importation. Cependant, son format est assez simple et consiste essentiellement en un ensemble de commandes divisées en blocs.

Chaque bloc définit une étape de chargement ou, dans le langage des développeurs Android, une action. Les blocs sont séparés les uns des autres par une directive on suivie du nom de l'action, comme on early-init ou on post-fs. Le bloc de commandes ne sera exécuté que si le déclencheur du même nom se déclenche. Au démarrage, init activera tour à tour les déclencheurs early-init, init, early-fs, fs, post-fs, early-boot et boot, lançant ainsi les blocs de commande correspondants.


Si le fichier de configuration contient plusieurs autres configurations répertoriées au début (et c'est presque toujours le cas), alors les blocs de commande du même nom qu'ils contiennent seront combinés avec la configuration principale, de sorte que lorsque le déclencheur se déclenche, init exécuter des commandes à partir des blocs correspondants de tous les fichiers. Ceci est fait pour faciliter la création de fichiers de configuration pour plusieurs appareils, lorsque la configuration principale contient des commandes communes à tous les appareils et que celles spécifiques à chaque appareil sont écrites dans des fichiers séparés.

La configuration supplémentaire la plus remarquable est nommée initrc.device_name.rc, où le nom du périphérique est déterminé automatiquement en fonction du contenu de la variable système ro.hardware. Il s'agit d'un fichier de configuration spécifique à la plate-forme qui contient des blocs de commande spécifiques au périphérique. En plus des commandes responsables du réglage du noyau, il contient également quelque chose comme ceci :

Mount_all ./fstab.device_name

Cela signifie que init doit maintenant monter tous les systèmes de fichiers répertoriés dans le fichier ./fstab.device_name, qui a la structure suivante :

Nom_du_périphérique (partition) point_de_montage système_fichier options_fs autres options

Il contient généralement des instructions pour monter des systèmes de fichiers à partir de partitions NAND internes vers les répertoires /system (OS), /data (paramètres de l'application) et /cache (données mises en cache). Cependant, en modifiant légèrement ce fichier, on peut forcer init à démarrer le système depuis la carte mémoire. Pour ce faire, divisez simplement la carte mémoire en trois 4 sections : 1 Go/ext4, 2 Go/ext4, 1 Go/ext4 et l'espace fat32 restant. Ensuite, vous devez déterminer les noms des partitions de la carte mémoire dans le répertoire /dev (ils diffèrent selon les périphériques) et les remplacer par les noms de périphériques d'origine dans le fichier fstab.


À la fin du bloc d'initialisation de démarrage, il rencontrera très probablement la commande class_start default, qui vous informera que vous devez alors démarrer tous les services répertoriés dans la configuration liés à la classe par défaut. La description des services commence par la directive service, suivie du nom du service et de la commande qui doit être exécutée pour le démarrer. Contrairement aux commandes répertoriées dans les blocs, les services doivent être exécutés en permanence, donc tout au long de la vie du smartphone, init restera en arrière-plan et surveillera cela.

Android moderne comprend des dizaines de services, mais deux d'entre eux ont un statut particulier et déterminent tout le cycle de vie du système.

Commandes init.rc

Le processus d'initialisation possède un ensemble de commandes intégré, dont beaucoup suivent le jeu de commandes Linux standard. Les plus remarquables d'entre eux :

  • exec /chemin/vers/commande- exécuter une commande externe ;
  • interface ifup- augmenter l'interface réseau ;
  • class_start nom_classe- démarrer les services appartenant à la classe spécifiée ;
  • class_stop nom_classe- arrêter les services ;
  • insmod /chemin/vers/module- charger le module noyau ;
  • monter le répertoire des périphériques FS- connecter le système de fichiers ;
  • valeur du nom setprop- définir une variable système ;
  • démarrer le service_name- démarrer le service spécifié ;
  • nom du déclencheur- activer le déclencheur (exécuter le bloc de commandes spécifié) ;
  • écrire /chemin/vers/ligne de fichier- écrire une ligne dans un fichier.

Quatrième étape. Zygote et app_process

À un certain stade du chargement, init rencontrera quelque chose comme ce bloc à la fin de la configuration :

Service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server classe socket par défaut zygote stream 660 système racine au redémarrage écrire /sys/android_power/request_state wake onrestart écrire /sys/power/state on onrestart redémarrer les médias onrestart redémarrer netd

Ceci est une description du service Zygote, un composant clé de tout système Android responsable de l'initialisation, du démarrage des services système, du démarrage et de l'arrêt des applications utilisateur et de nombreuses autres tâches. Zygote est lancé à l'aide d'une petite application /system/bin/app_process, qui est très clairement visible dans la partie ci-dessus de la configuration. La tâche app_proccess consiste à lancer la machine virtuelle Dalvik, dont le code se trouve dans la bibliothèque partagée /system/lib/libandroid_runtime.so, puis à exécuter Zygote par-dessus.

Une fois que tout cela est fait et que Zygote a le contrôle, il commence à construire le runtime de l'application Java en chargeant toutes les classes Java du framework (actuellement plus de 2000 d'entre elles). Il démarre ensuite le serveur_système, qui comprend la plupart des services système de haut niveau (écrits en Java), notamment le gestionnaire de fenêtres, la barre d'état, le gestionnaire de packages et, plus important encore, le gestionnaire d'activités, qui sera à l'avenir chargé de recevoir applications de signaux de début et de fin.

Après cela, Zygote ouvre le socket /dev/socket/zygote et se met en veille, en attendant les données. A ce moment, l'Activity Manager précédemment lancé envoie une intention de diffusion Intent.CATEGORY_HOME pour trouver l'application responsable de la création du bureau et donne son nom à Zygote via le socket. Ce dernier, à son tour, crée et exécute l'application au-dessus de la machine virtuelle. Voila, nous avons un bureau sur notre écran, trouvé par Activity Manager et lancé par Zygote, et une barre d'état lancée par system_server dans le cadre du service Status Bar. Après avoir appuyé sur l'icône, le bureau enverra une intention avec le nom de cette application, Activity Manager la recevra et enverra une commande pour démarrer l'application au démon Zygote.

INFO

Dans la terminologie Linux, un disque RAM est une sorte de disque dur virtuel qui n'existe que dans la RAM. Au début du processus de démarrage, le noyau extrait le contenu du disque de l'image et le monte en tant que système de fichiers racine (rootfs).

Pendant le processus de démarrage, Android affiche trois écrans de démarrage différents : le premier apparaît immédiatement après avoir appuyé sur le bouton d'alimentation et est flashé dans le noyau Linux, le second est affiché pendant les premières étapes de l'initialisation et enregistré dans le fichier /initlogo.rle (à peine utilisé aujourd'hui), ce dernier est lancé à l'aide de l'application bootanimation et est contenu dans le fichier /system/media/bootanimation.zip.

En plus des déclencheurs standards, init vous permet de définir vos propres déclencheurs, qui peuvent être déclenchés par divers événements : connexion d'un appareil à USB, modification de l'état d'un smartphone ou modification de l'état des variables système.

Entre autres choses, Activity Manager tue également les applications en arrière-plan lorsque la mémoire est insuffisante. Les valeurs de seuil de mémoire libre sont contenues dans le fichier /sys/module/lowmemorykiller/parameters/minfree.

Tout cela peut paraître un peu déroutant, mais le plus important est de se rappeler trois choses simples :

À bien des égards, Android est très différent des autres systèmes d’exploitation, et il est difficile de le comprendre tout de suite. Cependant, si vous comprenez comment tout fonctionne, les possibilités sont tout simplement infinies. Contrairement à iOS et Windows Phone, le système d'exploitation de Google possède une architecture très flexible qui permet de modifier sérieusement son comportement sans avoir à écrire de code. Dans la plupart des cas, il suffit de corriger les configurations et scripts nécessaires.

Android est une pile logicielle open source basée sur Linux créée pour un large éventail d'appareils et de facteurs de forme. Le diagramme suivant montre les principaux composants de la plateforme Android.

Figure 1.

Le noyau Linux

La base de la plateforme Android est le noyau Linux. Par exemple, s'appuie sur le noyau Linux pour les fonctionnalités sous-jacentes telles que le threading et la gestion de la mémoire de bas niveau.

L'utilisation d'un noyau Linux permet à Android d'en tirer parti et permet aux fabricants d'appareils de développer des pilotes matériels pour un noyau bien connu.

Couche d'abstraction matérielle (HAL)

Android comprend également un ensemble de bibliothèques d'exécution de base qui fournissent la plupart des fonctionnalités du langage de programmation Java, y compris certaines fonctionnalités du langage Java 8, utilisées par le framework API Java.

Bibliothèques C/C++ natives

De nombreux composants et services de base du système Android, tels que ART et HAL, sont construits à partir de code natif qui nécessite des bibliothèques natives écrites en C et C++. La plate-forme Android fournit des API de framework Java pour exposer les fonctionnalités de certaines de ces bibliothèques natives aux applications. Par exemple, vous pouvez accéder à OpenGL ES via l'API Java OpenGL du framework Android pour ajouter la prise en charge du dessin et de la manipulation de graphiques 2D et 3D dans votre application.

Si vous développez une application nécessitant du code C ou C++, vous pouvez utiliser le NDK Android pour accéder à certaines de ces bibliothèques de plateforme natives directement à partir de votre code natif.

Cadre API Java

L'ensemble des fonctionnalités du système d'exploitation Android est disponible via des API écrites en langage Java. Ces API constituent les éléments de base dont vous avez besoin pour créer des applications Android en simplifiant la réutilisation des composants et services principaux et modulaires du système, notamment :

  • Un système d'affichage riche et extensible que vous pouvez utiliser pour créer l'interface utilisateur d'une application, comprenant des listes, des grilles, des zones de texte, des boutons et même un navigateur Web intégrable.
  • A, donnant accès à des ressources non codées telles que des chaînes localisées, des graphiques et des fichiers de mise en page
  • Un gestionnaire de notifications qui permet à toutes les applications d'afficher des alertes personnalisées dans la barre d'état
  • Un gestionnaire d'activités qui gère le cycle de vie des applications et fournit une pile de navigation commune
  • Fournisseurs de contenu qui permettent aux applications d'accéder aux données d'autres applications, telles que l'application Contacts, ou de partager leurs propres données

Les développeurs ont un accès complet aux mêmes API de framework que celles utilisées par les applications système Android.

Applications système

Android est livré avec un ensemble d'applications de base pour la messagerie électronique, la messagerie SMS, les calendriers, la navigation Internet, les contacts, etc. Les applications incluses avec la plateforme n'ont pas de statut particulier parmi les applications que l'utilisateur choisit d'installer. Ainsi, une application tierce peut devenir le navigateur Web par défaut de l'utilisateur, la messagerie SMS ou même le clavier par défaut (certaines exceptions s'appliquent, comme l'application Paramètres du système).

Les applications système fonctionnent à la fois comme des applications pour les utilisateurs et pour fournir des fonctionnalités clés auxquelles les développeurs peuvent accéder depuis leur propre application. Par exemple, si votre application souhaite envoyer un message SMS, vous n'avez pas besoin de créer cette fonctionnalité vous-même : vous pouvez plutôt appeler l'application SMS déjà installée pour envoyer un message au destinataire que vous spécifiez.

Vous êtes-vous déjà demandé comment fonctionnent fastboot ou ADB ? Ou pourquoi est-il presque impossible de transformer un smartphone sous Android en brique ? Ou peut-être avez-vous longtemps voulu savoir où réside la magie du framework Xposed et pourquoi les scripts de démarrage /system/etc/init.d sont nécessaires ? Et la console de récupération ? Est-ce une partie d'Android ou une chose en soi et pourquoi la récupération régulière ne convient-elle pas à l'installation d'un micrologiciel tiers ? Vous trouverez des réponses à toutes ces questions et à bien d’autres dans cet article.

Comment fonctionne Android

Vous pouvez découvrir les capacités cachées des systèmes logiciels en comprenant le principe de leur fonctionnement. Dans certains cas, cela est difficile à faire, car le code système peut être fermé, mais dans le cas d'Android, nous pouvons étudier l'ensemble du système de fond en comble. Dans cet article, je ne parlerai pas de toutes les nuances d'Android et me concentrerai uniquement sur le démarrage du système d'exploitation et les événements qui se produisent dans l'intervalle entre l'appui sur le bouton d'alimentation et l'apparition du bureau.

En cours de route, j'expliquerai ce que nous pouvons changer dans cette chaîne d'événements et comment les développeurs de micrologiciels personnalisés utilisent ces capacités pour mettre en œuvre des éléments tels que le réglage des paramètres du système d'exploitation, l'extension de l'espace de stockage des applications, la connexion du swap, diverses personnalisations et bien plus encore. Toutes ces informations peuvent être utilisées pour créer votre propre firmware et mettre en œuvre divers hacks et modifications.

La première étape. ABOOT et table de partition

Tout commence par le chargeur de démarrage principal. Après la mise sous tension, le système exécute le code du chargeur de démarrage stocké dans la mémoire permanente de l'appareil. Ensuite, il transfère le contrôle au chargeur de démarrage aboot avec prise en charge intégrée du protocole fastboot, mais le fabricant de la puce mobile ou du smartphone/tablette a le droit de choisir n'importe quel autre chargeur de démarrage de son choix. Par exemple, Rockchip utilise son propre chargeur de démarrage qui n'est pas compatible avec le démarrage rapide et nécessite des outils propriétaires pour le flasher et le gérer.

Le protocole fastboot, quant à lui, est un système de gestion du chargeur de démarrage à partir d'un PC, qui vous permet d'effectuer des actions telles que le déverrouillage du chargeur de démarrage, le flashage d'un nouveau noyau et la récupération, l'installation du firmware et bien d'autres. La raison d'être de fastboot est de pouvoir restaurer un smartphone à son état d'origine dans une situation où tous les autres moyens échouent. Fastboot restera en place même si, à la suite d'expériences, vous effacez toutes les partitions de mémoire NAND contenant Android et la récupération de votre smartphone.

Après avoir reçu le contrôle, aboot vérifie la table de partition et transfère le contrôle au noyau flashé dans la partition nommée boot, après quoi le noyau extrait l'image RAM de la même partition en mémoire et commence à charger Android ou la console de récupération. La mémoire NAND des appareils Android est divisée en six sections requises sous condition :

  • boot - contient le noyau et le disque RAM, généralement d'une taille d'environ 16 Mo ;
  • récupération - console de récupération, composée d'un noyau, d'un ensemble d'applications console et d'un fichier de paramètres, d'une taille de 16 Mo ;
  • système - contient Android, dans les appareils modernes, la taille est d'au moins 1 Go ;
  • cache - conçu pour stocker les données mises en cache, également utilisé pour sauvegarder le micrologiciel lors d'une mise à jour OTA et a donc une taille similaire à la taille de la partition système ;
  • données utilisateur - contient les paramètres, les applications et les données utilisateur, tout l'espace mémoire NAND restant lui est alloué ;
  • misc - contient un indicateur qui détermine dans quel mode le système doit démarrer : Android ou récupération.
En plus d'eux, il peut y avoir d'autres sections, mais le balisage général est déterminé au stade de la conception du smartphone et, en cas de démarrage, est intégré au code du chargeur de démarrage. Cela signifie que : 1) la table de partition ne peut pas être supprimée, puisqu'elle peut toujours être restaurée à l'aide de la commande fastboot oem format ; 2) pour changer la table de partition, vous devrez déverrouiller et reflasher le bootloader avec de nouveaux paramètres. Il existe cependant des exceptions à cette règle. Par exemple, le chargeur de démarrage du même Rockchip stocke des informations sur les partitions dans le premier bloc de mémoire NAND, il n'est donc pas nécessaire de flasher le chargeur de démarrage pour le modifier.

Partie du code du chargeur de démarrage qui définit la table de partition


La section divers est particulièrement intéressante. On suppose qu'il a été créé à l'origine pour stocker divers paramètres indépendamment du système principal, mais pour le moment, il n'est utilisé que dans un seul but : indiquer au chargeur de démarrage à partir de quelle partition le système doit être chargé - démarrage ou récupération. Cette fonctionnalité, en particulier, est utilisée par l'application ROM Manager pour redémarrer automatiquement le système en mode récupération avec installation automatique du micrologiciel. Sur cette base, le mécanisme de double démarrage Ubuntu Touch est construit, qui met le chargeur de démarrage Ubuntu en mode récupération et vous permet de contrôler quel système démarrera la prochaine fois. Effacé la partition diverse - chargements Android, remplissage de données - chargements de récupération... c'est-à-dire Ubuntu Touch.

Deuxième étape. Section de démarrage

Si la section misc n'a pas d'indicateur de démarrage de récupération, aboot transfère le contrôle au code situé dans la section de démarrage. Ce n'est rien de plus que le noyau Linux ; il est situé au début de la section, et immédiatement suivi d'une image disque RAM emballée à l'aide des archiveurs cpio et gzip, contenant les répertoires nécessaires au fonctionnement d'Android, le système d'initialisation init et d'autres outils. Il n'y a pas de système de fichiers sur la partition de démarrage ; le noyau et le disque RAM se suivent simplement. Le contenu du disque RAM est :

  • data - répertoire pour monter la partition du même nom ;
  • dev - fichiers de périphérique ;
  • proc - procfs est monté ici ;
  • res - un ensemble d'images pour le chargeur (voir ci-dessous) ;
  • sbin - un ensemble d'utilitaires et de démons (adbd, par exemple) ;
  • sys - sysfs est monté ici ;
  • système - répertoire pour monter la partition système ;
  • chargeur - application pour afficher le processus de charge ;
  • build.prop - paramètres système ;
  • init - système d'initialisation ;
  • init.rc - paramètres du système d'initialisation ;
  • ueventd.rc - paramètres du démon uventd inclus dans init.
C'est, pour ainsi dire, le squelette du système : un ensemble de répertoires pour connecter les systèmes de fichiers à partir des partitions de mémoire NAND et un système d'initialisation qui gérera le reste du travail de démarrage du système. L'élément central ici est l'application init et sa configuration init.rc, dont je parlerai en détail plus tard. En attendant, j'aimerais attirer votre attention sur les fichiers charger et ueventd.rc, ainsi que sur les répertoires sbin, proc et sys.

Le fichier du chargeur est une petite application dont le seul travail est d'afficher l'icône de la batterie. Cela n'a rien à voir avec Android et est utilisé lorsque l'appareil est connecté au chargeur à l'état éteint. Dans ce cas, Android ne se charge pas et le système charge simplement le noyau, connecte le disque RAM et démarre le chargeur. Ce dernier affiche une icône de batterie dont l'image, dans tous les états possibles, est stockée dans des fichiers PNG ordinaires dans le répertoire res.

Le fichier ueventd.rc est une configuration qui détermine quels fichiers de périphérique dans le répertoire sys doivent être créés lors du démarrage du système. Dans les systèmes basés sur le noyau Linux, l'accès au matériel s'effectue via des fichiers spéciaux dans le répertoire dev, et le démon ueventd, qui fait partie d'init, est responsable de leur création dans Android. Dans une situation normale, il fonctionne en mode automatique, en acceptant les commandes pour créer des fichiers à partir du noyau, mais certains fichiers doivent être créés indépendamment. Ils sont répertoriés dans ueventd.rc.

Le répertoire sbin en stock Android ne contient généralement rien d'autre que adbd, c'est-à-dire le démon ADB, qui est responsable du débogage du système à partir du PC. Il s'exécute à un stade précoce du démarrage du système d'exploitation et vous permet d'identifier d'éventuels problèmes lors de la phase d'initialisation du système d'exploitation. Dans les firmwares personnalisés, vous pouvez trouver de nombreux autres fichiers dans ce répertoire, par exemple mke2fs, qui peuvent être requis si les partitions doivent être reformatées en ext3/4. De plus, les moddeurs y placent souvent une BusyBox, avec laquelle vous pouvez appeler des centaines de commandes Linux.

Le répertoire proc est standard pour Linux ; dans les prochaines étapes de démarrage, init s'y connectera procfs, un système de fichiers virtuel qui donne accès aux informations sur tous les processus du système. Le système connectera sysfs au répertoire sys, qui ouvre l'accès aux informations sur le matériel et ses paramètres. En utilisant sysfs, vous pouvez, par exemple, mettre l'appareil en veille ou modifier l'algorithme d'économie d'énergie utilisé.

Le fichier build.prop est conçu pour stocker les paramètres Android de bas niveau. Plus tard, le système réinitialisera ces paramètres et les écrasera avec les valeurs du fichier system/build.prop actuellement inaccessible.


Section racine du décodeur OUYA TV


Deuxième étape, alternative. Section de récupération

Si l'indicateur de démarrage de récupération dans la section misc est activé ou si l'utilisateur allume le smartphone avec la touche de réduction du volume enfoncée, aboot transférera le contrôle au code situé au début de la section de récupération. Comme la partition de démarrage, elle contient le noyau et un disque RAM, qui est décompressé en mémoire et devient la racine du système de fichiers. Cependant, le contenu du disque RAM est ici quelque peu différent.

Contrairement à la partition de démarrage, qui fait office de lien de transition entre les différentes étapes de chargement de l'OS, la partition de récupération est totalement autosuffisante et contient un système d'exploitation miniature qui n'est en aucun cas connecté à Android. Recovery possède son propre noyau, son propre ensemble d'applications (commandes) et sa propre interface qui permet à l'utilisateur d'activer les fonctions de service.

Dans une récupération standard (stock), il n'y a généralement que trois fonctions de ce type : installation du micrologiciel signé avec la clé du fabricant du smartphone, effacement et redémarrage. Les récupérations tierces modifiées, telles que ClockworkMod et TWRP, ont beaucoup plus de fonctions. Ils peuvent formater des systèmes de fichiers, installer un micrologiciel signé avec n'importe quelle clé (lire : personnalisé), monter des systèmes de fichiers sur d'autres partitions (à des fins de débogage du système d'exploitation) et inclure la prise en charge des scripts, qui vous permet d'automatiser le processus du micrologiciel et de nombreuses autres fonctions.

À l'aide de scripts, par exemple, vous pouvez vous assurer qu'après le démarrage, la récupération trouve automatiquement le micrologiciel nécessaire sur la carte mémoire, les installe et redémarre sous Android. Cette fonctionnalité est utilisée par le ROM Manager, les outils de flashage automatique, ainsi que le mécanisme de mise à jour automatique de CyanogenMod et d'autres micrologiciels.

La récupération personnalisée prend également en charge les scripts de sauvegarde situés dans le répertoire /system/addon.d/. Avant de flasher, la récupération vérifie les scripts et les exécute avant de flasher le micrologiciel. Grâce à de tels scripts, les gapps ne disparaissent pas après l'installation d'une nouvelle version du firmware.

Troisième étape. Initialisation

Ainsi, après avoir reçu le contrôle, le noyau connecte le disque RAM et, après avoir initialisé tous ses sous-systèmes et pilotes, démarre le processus d'initialisation, qui lance l'initialisation d'Android. Comme je l'ai déjà dit, init possède un fichier de configuration init.rc, à partir duquel le processus apprend exactement ce qu'il doit faire pour faire démarrer le système. Dans les smartphones modernes, cette configuration a une longueur impressionnante de plusieurs centaines de lignes et est également équipée d'une bande-annonce de plusieurs configurations enfants connectées à la configuration principale à l'aide de la directive d'importation. Cependant, son format est assez simple et consiste essentiellement en un ensemble de commandes divisées en blocs.

Chaque bloc définit une étape de chargement ou, dans le langage des développeurs Android, une action. Les blocs sont séparés les uns des autres par une directive on suivie du nom de l'action, comme on early-init ou on post-fs. Le bloc de commandes ne sera exécuté que si le déclencheur du même nom se déclenche. Au démarrage, init activera tour à tour les déclencheurs early-init, init, early-fs, fs, post-fs, early-boot et boot, lançant ainsi les blocs de commande correspondants.


Une partie de la configuration init.rc de CyanogenMod


Si le fichier de configuration contient plusieurs autres configurations répertoriées au début (et c'est presque toujours le cas), alors les blocs de commande du même nom qu'ils contiennent seront combinés avec la configuration principale, de sorte que lorsque le déclencheur se déclenche, init exécuter des commandes à partir des blocs correspondants de tous les fichiers. Ceci est fait pour faciliter la création de fichiers de configuration pour plusieurs appareils, lorsque la configuration principale contient des commandes communes à tous les appareils et que celles spécifiques à chaque appareil sont écrites dans des fichiers séparés.

La configuration supplémentaire la plus remarquable est nommée initrc.device_name.rc, où le nom du périphérique est déterminé automatiquement en fonction du contenu de la variable système ro.hardware. Il s'agit d'un fichier de configuration spécifique à la plate-forme qui contient des blocs de commande spécifiques au périphérique. En plus des commandes responsables du réglage du noyau, il contient également quelque chose comme ceci :

Code:

Mount_all ./fstab.device_name

Cela signifie que init doit maintenant monter tous les systèmes de fichiers répertoriés dans le fichier ./fstab.device_name, qui a la structure suivante :

Code:

Nom_du_périphérique (partition) point_de_montage système_fichier options_fs autres options

Il contient généralement des instructions pour monter des systèmes de fichiers à partir de partitions NAND internes vers les répertoires /system (OS), /data (paramètres de l'application) et /cache (données mises en cache). Cependant, en modifiant légèrement ce fichier, on peut forcer init à démarrer le système depuis la carte mémoire. Pour ce faire, divisez simplement la carte mémoire en trois 4 sections : 1 Go/ext4, 2 Go/ext4, 1 Go/ext4 et l'espace fat32 restant. Ensuite, vous devez déterminer les noms des partitions de la carte mémoire dans le répertoire /dev (ils diffèrent selon les périphériques) et les remplacer par les noms de périphériques d'origine dans le fichier fstab.


Contenu typique du fichier fstab


À la fin du bloc d'initialisation de démarrage, il rencontrera très probablement la commande class_start default, qui vous informera que vous devez alors démarrer tous les services répertoriés dans la configuration liés à la classe par défaut. La description des services commence par la directive service, suivie du nom du service et de la commande qui doit être exécutée pour le démarrer. Contrairement aux commandes répertoriées dans les blocs, les services doivent être exécutés en permanence, donc tout au long de la vie du smartphone, init restera en arrière-plan et surveillera cela.

Android moderne comprend des dizaines de services, mais deux d'entre eux ont un statut particulier et déterminent tout le cycle de vie du système.

Quatrième étape. Zygote et app_process

À un certain stade du chargement, init rencontrera quelque chose comme ce bloc à la fin de la configuration :

Code:

Service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server classe socket par défaut zygote stream 660 système racine au redémarrage écrire /sys/android_power/request_state wake onrestart écrire /sys/power/state on onrestart redémarrer les médias onrestart redémarrer netd

Ceci est une description du service Zygote, un composant clé de tout système Android responsable de l'initialisation, du démarrage des services système, du démarrage et de l'arrêt des applications utilisateur et de nombreuses autres tâches. Zygote est lancé à l'aide d'une petite application /system/bin/app_process, qui est très clairement visible dans la partie ci-dessus de la configuration. La tâche app_proccess consiste à lancer la machine virtuelle Dalvik, dont le code se trouve dans la bibliothèque partagée /system/lib/libandroid_runtime.so, puis à exécuter Zygote par-dessus.

Une fois que tout cela est fait et que Zygote a le contrôle, il commence à construire le runtime de l'application Java en chargeant toutes les classes Java du framework (actuellement plus de 2000 d'entre elles). Il démarre ensuite le serveur_système, qui comprend la plupart des services système de haut niveau (écrits en Java), notamment le gestionnaire de fenêtres, la barre d'état, le gestionnaire de packages et, plus important encore, le gestionnaire d'activités, qui sera à l'avenir chargé de recevoir applications de signaux de début et de fin.

Après cela, Zygote ouvre le socket /dev/socket/zygote et se met en veille, en attendant les données. A ce moment, l'Activity Manager précédemment lancé envoie une intention de diffusion Intent.CATEGORY_HOME pour trouver l'application responsable de la création du bureau et donne son nom à Zygote via le socket. Ce dernier, à son tour, crée et exécute l'application au-dessus de la machine virtuelle. Voila, nous avons un bureau sur notre écran, trouvé par Activity Manager et lancé par Zygote, et une barre d'état lancée par system_server dans le cadre du service Status Bar. Après avoir appuyé sur l'icône, le bureau enverra une intention avec le nom de cette application, Activity Manager la recevra et enverra une commande pour démarrer l'application au démon Zygote.

Tout cela peut paraître un peu déroutant, mais le plus important est de se rappeler trois choses simples :

  • Le processus de démarrage d'Android est divisé en deux étapes clés : avant Zygote et après. Avant de démarrer Zygote, le système initialise les composants de bas niveau du système d'exploitation. Il s'agit d'opérations telles que la connexion (montage) de systèmes de fichiers, le lancement de services de bas niveau (par exemple, rild, qui est responsable du travail avec le modem GSM, SurfaceFlinger, qui contrôle ce qui est affiché à l'écran, vold, qui contrôle le fichier monté systèmes). Une fois Zygote lancé, l'initialisation commence exclusivement sur les composants Java, qui constituent 80 % du système d'exploitation. Ceci, en particulier, est utilisé par le framework Xposed bien connu, qui, une fois installé, remplace app_process par sa propre version modifiée, capable d'intercepter les appels de n'importe quelle classe Java, en les remplaçant par d'autres. C'est pourquoi les modules Xposed offrent de si larges possibilités pour modifier l'apparence et le comportement d'Android. En fait, ils ne changent rien au système, mais l'obligent simplement à utiliser des composants tiers au lieu des leurs.
  • Les applications Java ne démarrent jamais à partir de zéro. Lorsque Zygote reçoit une demande de démarrage d'une application du gestionnaire d'activité, il ne lance pas une nouvelle machine virtuelle, mais simplement des forks, c'est-à-dire qu'il se copie puis lance l'application souhaitée par-dessus la copie reçue de la machine virtuelle. Ce principe de fonctionnement permet, d'une part, de réduire au minimum la consommation mémoire, puisque Linux copie la mémoire en mode copie sur écriture lors d'un fork (le nouveau processus fait référence à la mémoire de l'ancien), et d'autre part, d'accélérer considérablement le lancement de l'application : bifurquer le processus est beaucoup plus rapide que lancer une nouvelle machine virtuelle et charger les classes Java nécessaires à l'application.
  • Android utilise des intentions partout. Les composants Android n'utilisent jamais d'appels directs aux procédures et aux classes pour communiquer entre eux. Au lieu de cela, on utilise un système de messages (intents) qui, en plus d'un haut niveau de sécurité, offre également de nombreux autres avantages, comme par exemple la possibilité d'appeler une application sans rien savoir d'elle. J'ai déjà écrit ci-dessus que pour lancer le bureau, le système doit simplement envoyer l'intention Intent.CATEGORY_HOME, à laquelle répondra toute application capable d'exécuter la fonction de lancement. Le bouton « Partager » fonctionne de la même manière, comme de nombreux autres composants du système.