Red de conocimiento informático - Computadora portátil - Arquitectura del sistema Android

Arquitectura del sistema Android

Android se ejecuta en el kernel de Linux, que no es GNU/Linux, porque Android no soporta la mayoría de las características soportadas por GNU/Linux, incluyendo Cairo, X11, Alsa, FFmpeg, GTK, Pango y Glibc, estos Se han eliminado características. Android reemplazó Glibc con Bionic, Cairo con Skia, FFmpeg con opencore, etc. Para estar disponible comercialmente, Android tuvo que eliminar partes que estaban sujetas a la licencia GNU GPL. Bionic/Libc/Kernel/ no es un archivo de encabezado del kernel estándar. Los encabezados del kernel de Android se generan a partir de los encabezados del kernel de Linux, utilizando herramientas que preservan constantes, estructuras de datos y macros. Esto se hace para preservar constantes, estructuras de datos y macros.

Los controles del kernel de Linux de Android incluyen seguridad, gestión de memoria, gestión de procesos, pila de red, modelo de controlador, etc. Antes de descargar el código fuente de Android, instale el repositorio de herramientas de compilación para inicializar el código fuente. Repo es una herramienta utilizada por Android para ayudar al trabajo de Git. APK es el sufijo de aplicaciones de Android y es la abreviatura de AndroidPackage o Android Installation Kit (apk). APK es un formato de archivo similar a Symbian Sis o Sisx. Se puede instalar transfiriendo el archivo APK directamente a un emulador de Android o ejecutándolo en un teléfono Android. Los archivos APK son los mismos que Sis, que empaqueta proyectos compilados con el SDK de Android en archivos de instalación en formato apk. El archivo APK está en realidad en formato zip, pero el sufijo se modifica a apk y UnZip lo descomprime. Archivo Dex, Dex es el nombre completo de la ejecución de la máquina virtual Dalvik, es decir, el archivo ejecutable de Android Dalvik, no el código de bytes de Java ME, sino el código de bytes de Dalvik.

Estructura del archivo APK

Una estructura de archivo APK:

1.META-INF/ (Nota: los archivos Jar se pueden ver a menudo);

2.res/ (Nota: el directorio donde se almacenan los archivos de recursos);

3.AndroidManifest.xml (Nota: el archivo de configuración global del programa);

4.classes .dex (Nota: código de bytes de Dalvik);

5.resources.arsc (Nota: archivo de recursos binarios compilados).

Resumen Descubrimos que Android primero necesita descomprimirlo cuando ejecuta el programa y luego lo instala directamente de manera similar a Symbian, mientras que los archivos PE en Windows Mobile son diferentes, lo que no es muy bueno para la confidencialidad y confiabilidad. Para programas avanzados, puede usar el comando dexdump para descompilar, ¡pero esto está en línea con la ley de desarrollo! Los Windows Gadgets de Microsoft, conocidos como WPF, también utilizan esta arquitectura.

En la plataforma Android, el archivo ejecutable dalvik vm está empaquetado en formato apk. El cargador de tiempo de ejecución final lo descomprimirá y luego obtendrá las ramas de permiso relacionadas con el acceso de seguridad en el archivo androidmanifest.xml compilado. Todavía existen muchas restricciones de seguridad. Si pasa el archivo apk a la carpeta /system/app, encontrará que la ejecución no tiene restricciones.

Por lo general, los archivos que instalamos pueden no estar en esta carpeta, pero en la ROM de Android, los archivos apk del sistema se colocan en esta carpeta de forma predeterminada y tienen acceso de root. HAL (Capa de abstracción de hardware) de Android es un módulo de controlador de hardware que se puede proporcionar como código fuente cerrado. El propósito de HAL es aislar el marco de Android del kernel de Linux, de modo que Android no dependa demasiado del kernel de Linux para lograr el concepto de independencia del kernel, de modo que el desarrollo del marco de Android no necesite considerar el kernel de Linux. . HAL está diseñado para aislar el marco de Android del kernel de Linux para que Android no dependa demasiado del kernel de Linux, permitiendo así el concepto de independencia del kernel y permitiendo el desarrollo del marco de Android sin considerar la implementación del controlador.

HAL stub es un concepto de proxy, que existe en forma de archivo *.so. El código auxiliar "proporciona" operaciones a HAL y el tiempo de ejecución de Android obtiene las operaciones del código auxiliar de HAL. El HAL contiene una serie de códigos auxiliares (agentes) que permiten que el tiempo de ejecución obtenga operaciones especificando un "tipo" (es decir, ID del módulo). Como puente entre el sistema operativo y la aplicación, la aplicación se divide en dos capas: biblioteca y máquina virtual. Bionic es una versión modificada de Android libc. Android también incluye Webkit, el motor detrás del navegador Safari de Apple, y Surface Flinger, que puede mostrar contenido 2D o 3D en la pantalla.

Android utiliza OpenCORE como framework multimedia básico. Open CORE se puede dividir en siete bloques:

Android utiliza skia como motor gráfico central y adopta OpenGL/ES.

skia es comparable a Linux Cairo, pero en comparación con Linux Cairo, skia todavía está a sólo unos pasos de distancia. skia fue adquirida por Google en 2005. A principios de 2007, se hizo público el código fuente de skia GL. Skia es también el motor gráfico del navegador Google Chrome.

La base de datos multimedia de Android utiliza el sistema de base de datos SQLite. La base de datos se divide en base de datos de uso privado y base de datos privada. Los usuarios pueden obtener la base de datos *** a través de la clase ContentResolver (Columna).

La capa intermedia de Android está implementada en Java y utiliza una máquina virtual Dalvik especial, que es una máquina virtual Java "basada en registros" en la que las variables se almacenan en registros. La máquina virtual Dalvik es una máquina virtual Java "basada en registros", donde las variables se almacenan en registros y la cantidad de instrucciones en la máquina virtual es relativamente pequeña.

Una máquina virtual Dalvik puede tener varias instancias y cada aplicación de Android se ejecuta en su propia máquina virtual Dalvik, lo que permite que el sistema ejecute la aplicación de manera óptima. En lugar de ejecutar el código de bytes de Java, la máquina virtual Dalvik ejecuta un archivo llamado archivo .dex. La máquina virtual Dalvik no ejecuta el código de bytes de Java (Bytecode). El propio Android es un sistema operativo separado por permisos. En este sistema operativo, cada aplicación se ejecuta con una identidad de sistema única (ID de usuario de Linux e ID de grupo). Cada parte del sistema también utiliza su propia identidad independiente. Así es como Linux aísla una aplicación de otra y una aplicación del sistema.

Se proporcionan más funciones de seguridad del sistema a través del mecanismo de permisos.

Los permisos pueden restringir operaciones específicas a procesos específicos o pueden restringir el acceso a segmentos de datos específicos según los permisos de URI.

La filosofía de diseño central de la arquitectura de seguridad de Android es que, de forma predeterminada, ninguna aplicación tiene permiso para realizar operaciones que tengan un impacto significativo en otras aplicaciones, el sistema o el usuario. Esto incluye leer y escribir los datos privados del usuario (contactos o correo electrónico), leer y escribir otros archivos de aplicaciones, acceder a la red o evitar que el dispositivo entre en modo de espera.

Al instalar una aplicación, el instalador del paquete otorga permisos a la aplicación después de verificar los permisos mencionados en la firma del programa y confirmados por el usuario. Desde la perspectiva del usuario, las aplicaciones de Android generalmente requieren los siguientes permisos:

Llamar, enviar SMS o MMS, modificar/eliminar contenido de la tarjeta SD, leer información de contacto, leer información del calendario, escribir datos del calendario, leer el estado del teléfono o identificador, geolocalización precisa (basada en GPS), geolocalización difusa (basada en red), crear conexión Bluetooth, acceso completo a Internet, verificar el estado de la red, verificar el estado de WiFi, evitar el modo de espera del teléfono, modificar la configuración global del sistema, leer la configuración de sincronización, auto -iniciar al arrancar, reiniciar otras aplicaciones, finalizar aplicaciones en ejecución, configurar aplicaciones preferidas, control de vibración, tomar fotografías, etc.

Las aplicaciones deben solicitar permisos razonables según la funcionalidad que proporcionan. Los usuarios también pueden determinar simplemente si una aplicación es segura analizando los permisos que requiere. Si una aplicación es independiente, no tiene anuncios y no requiere descargas adicionales, entonces su solicitud de acceso a la red es cuestionable.