Vista rápida
-
Aplicaciones de Android se compone de uno o más componentes de la aplicación (actividades, servicios, proveedores de contenido y receptores de radiodifusión)
-
Cada componente realiza una función diferente en el comportamiento global de la aplicación, y cada uno de ellos se puede activar de forma individual (aunque por otras aplicaciones)
-
El archivo de manifiesto debe declarar todos los componentes de la aplicación y también debe declarar todos los requisitos de aplicación, como la versión mínima de Android necesarios y todas las configuraciones de hardware necesarios
-
Código de no aplicación de recursos (imágenes, secuencias, archivos de diseño, etc) deben incluir alternativas para las configuraciones de dispositivo diferente (como cadenas en distintos lenguajes y diferentes diseños para diferentes tamaños de pantalla)
En este documento
-
Componentes de la aplicación
-
La activación de los componentes
-
El archivo de manifiesto
-
La declaración de los componentes
-
La declaración de los requisitos de aplicación
-
Recursos de aplicación
Las Aplicaciones Android están escritas en el lenguaje de programación Java. Las herramientas de Android SDK, compilar el código, junto con los datos y archivos de recursos-en un paquete de Android , un archivo comprimido con un . apk
sufijo. Todo el código en una sola . apk de
archivo es considerado como una aplicación y es el archivo que con Android utiliza para instalar la aplicación.
Una vez instalado en un dispositivo, cada aplicación Android vive en su propia seguridad sandbox:
-
El sistema operativo Android es un sistema multi-usuario de Linux en el que cada aplicación es un usuario diferente.
-
Por defecto, el sistema asigna a cada solicitud un único ID de usuario de Linux (el ID es utilizado sólo por el sistema y se desconoce a la aplicación). El sistema establece permisos para todos los archivos en una aplicación para que sólo el ID de usuario asignado a esa aplicación puede acceder a ellos.
-
Cada proceso tiene su propia máquina virtual (VM), por lo que el código de una aplicación se ejecuta de manera aislada de otras aplicaciones.
-
Por defecto, cada aplicación se ejecuta en su proceso de Linux propia. Android se inicia el proceso cuando alguno de los componentes de la aplicación necesitan ser ejecutados, y luego cierra el proceso cuando ya no se necesita o cuando el sistema debe recuperar la memoria para otras aplicaciones.
De esta manera, el sistema Android implementa el principio de privilegios mínimos. Es decir, cada aplicación, por defecto, sólo tiene acceso a los componentes que necesita para hacer su trabajo y nada más. Esto crea un ambiente muy seguro en el que una aplicación no puede acceder a partes del sistema para el cual no se le da permiso.
Sin embargo, hay maneras para que una aplicación para compartir datos con otras aplicaciones y de una aplicación para acceder a los servicios del sistema:
-
Es posible disponer de dos aplicaciones que comparten el mismo ID de usuario de Linux, en cuyo caso pueden acceder a los demás archivos. Para ahorrar recursos del sistema, las aplicaciones con el mismo ID de usuario también puede hacer arreglos para ejecutar en el mismo proceso y Linux comparten la misma máquina virtual (las solicitudes deben estar firmadas con el mismo certificado).
-
Una aplicación puede solicitar permiso para acceder a los datos del dispositivo, tales como los contactos del usuario, los mensajes SMS, el almacenamiento capaz (tarjeta SD), cámara, Bluetooth, y mucho más. Todos los permisos de la aplicación debe ser concedida por el usuario durante la instalación.
Que cubre los conceptos básicos acerca de cómo una aplicación Android que existe dentro del sistema. El resto de este documento es una introducción a:
-
Los componentes básicos que definen el marco de la aplicación.
-
El archivo de manifiesto en el que se declaran los componentes y las funciones requeridas de dispositivo para su aplicación.
-
Recursos que están separados del código de la aplicación y permitir que la aplicación para optimizar su comportamiento con elegancia para una variedad de configuraciones de los dispositivos.
Componentes de la aplicación
Componentes de la aplicación son los componentes esenciales de una aplicación Android. Cada componente es un punto diferente a través del cual el sistema puede entrar en su aplicación. No todos los componentes son verdaderos puntos de entrada para el usuario y algunos dependen unos de otros, pero cada uno existe como una entidad propia y desempeña un papel específico, cada uno es una pieza única que ayuda a definir el comportamiento general de la aplicación.
Hay cuatro tipos diferentes de componentes de la aplicación. Cada tipo tiene un propósito distinto y tiene un ciclo vital distinto que define cómo el componente se crea y destruye.
Estos son los cuatro tipos de componentes de la aplicación:
-
Actividades
-
Una actividad representa una pantalla única con una interfaz de usuario. Por ejemplo, una aplicación de correo electrónico puede haber una actividad que muestra una lista de correos electrónicos nuevos, otra actividad para componer un correo electrónico, así como otra actividad para la lectura de mensajes de correo electrónico. Aunque las actividades de trabajo para formar una experiencia de usuario coherente en la aplicación de correo electrónico, cada una es independiente de los otros. Como tal, una aplicación puede comenzar a cualquiera de estas actividades (si la aplicación de correo electrónico lo permite). Por ejemplo, una aplicación de cámara se puede iniciar la actividad en la aplicación de correo electrónico que compone nuevos mensajes de correo, para que el usuario pueda compartir una imagen.
Una actividad que se implementa como una subclase de actividad
y se puede aprender más sobre esto en la actividades de guía para el desarrollador.
-
Servicios
-
Un servicio es un componente que se ejecuta en segundo plano para realizar operaciones de larga duración o para realizar un trabajo de procesos remotos. Un servicio no proporciona una interfaz de usuario. Por ejemplo, un servicio puede reproducir música en segundo plano mientras el usuario está en una aplicación diferente, o puede obtener los datos por la red sin la interacción del usuario con el bloqueo de una actividad. Otro de los componentes, tales como actividad, puede iniciar el servicio y se deja correr o se unen a ella con el fin de interactuar con él.
Un servicio se implementa como una subclase de servicio
y usted puede aprender más sobre él en el Servicios de guía para el desarrollador.
-
Los proveedores de contenido (Content provider)
-
Un proveedor de contenidos administra un conjunto compartido de datos de aplicación. Puede almacenar los datos en el sistema de archivos, una base de datos SQLite, en la web, o cualquier otro lugar de almacenamiento permanente de su aplicación puede tener acceso. A través del proveedor de contenidos, otras aplicaciones pueden consultar o modificar incluso los datos (si el proveedor de contenido lo permite). Por ejemplo, el sistema Android ofrece un proveedor de contenidos que gestiona la información de contacto del usuario. Por lo tanto, cualquier aplicación con los permisos adecuados puede hacer una consulta por parte del proveedor de contenido (como ContactsContract.Data
) a leer y escribir información sobre una persona en particular.
Los proveedores de contenidos también son útiles para la lectura y escritura de datos que son privativos de su aplicación y no se comparten. Por ejemplo, el Bloc de Notas aplicación de ejemplo utiliza un proveedor de contenido para guardar notas.
Un proveedor de contenido se lleva a cabo como una subclase de ContentProvider
y debe implementar un conjunto estándar de API que permite a otras aplicaciones para realizar transacciones. Para más información, consulte el contenido de los proveedores de guía para el desarrollador.
-
Receptores de radiodifusión (Broadcast receivers)
-
Un receptor de radiodifusión es un componente que responde a los anuncios de difusión en todo el sistema. Muchas emisiones se originan en el sistema-por ejemplo, una emisión de anunciar que la pantalla se ha apagado, la batería está baja, o una imagen fue capturada. Las solicitudes también se pueden iniciar las emisiones, por ejemplo, para permitir que otras aplicaciones de saber que algunos datos han sido descargados en el dispositivo y está disponible para que los utilice. A pesar de receptores de radiodifusión no mostrar una interfaz de usuario, pueden crear una notificación de la barra de estado para alertar al usuario cuando un evento de difusión se produce. Más comúnmente, sin embargo, un receptor de radiodifusión es una "puerta" a otros componentes y tiene la intención de hacer una mínima cantidad de trabajo. Por ejemplo, se podría iniciar un servicio para realizar un trabajo basado en el evento.
Un receptor de radiodifusión se implementa como una subclase de BroadcastReceiver
y cada emisión se entrega como una intención
de objetos. Para más información, consulte la BroadcastReceiver
clase.
Un aspecto único del diseño del sistema Android es que cualquier aplicación puede comenzar otro componente de la aplicación. Por ejemplo, si desea que el usuario capturar una foto con la cámara del dispositivo, es probable que haya otra aplicación que hace eso y su aplicación se puede utilizar, en lugar de desarrollar una actividad para capturar una foto de ti mismo. No es necesario incorporar o incluso enlazan con el código de la aplicación de la cámara. En su lugar, sólo tiene que iniciar la actividad en la aplicación de cámara que capta una foto. Cuando esté completo, la foto es incluso volvió a su aplicación para que pueda usarlo. Para el usuario, parece como si la cámara es en realidad una parte de su solicitud.
Cuando el sistema arranca un componente, se inicia el proceso para que la aplicación (si no está abierto) y crea una instancia de las clases necesarias para el componente. Por ejemplo, si su aplicación se inicia la actividad en la aplicación de cámara que captura una foto, que la actividad se ejecuta en el proceso que pertenece a la aplicación de la cámara, no en el proceso de la aplicación. Por lo tanto, a diferencia de la mayoría de las aplicaciones en otros sistemas, las aplicaciones de Android no tiene un único punto de entrada (no hay main ()
función, por ejemplo).
Debido a que el sistema se ejecuta cada aplicación en un proceso separado con permisos de archivos que limitan el acceso a otras aplicaciones, su aplicación no pueden activar directamente un componente de otra aplicación. El sistema Android, sin embargo, se puede. Por lo tanto, para activar un componente de otra aplicación, debe entregar un mensaje al sistema que especifica su intención de iniciar un componente particular. Entonces, el sistema activa el componente para usted.
Componentes de la activación
Tres de los cuatro tipos de componentes, actividades, servicios y difusión receptores son activados por un mensaje asincrónico llama intención . Intenciones se unen los componentes individuales el uno al otro en tiempo de ejecución (se puede pensar en ellos como los mensajeros que la solicitud de una acción de otros componentes), si el componente pertenece a su aplicación u otra.
La intención es creada con una intención
de objetos, que define un mensaje de que se active un componente específico o un determinado tipo de componentes, la intención puede ser explícita o implícita, respectivamente.
Para las actividades y servicios, la intención define la acción a realizar (por ejemplo, para "ver" o "enviar" algo) y puede especificar el URI de la información para actuar en (entre otras cosas, que el componente que está siendo iniciado puede ser que necesite saber ). Por ejemplo, la intención podría transmitir una petición para una actividad para mostrar una imagen o abrir una página web. En algunos casos, puede iniciar una actividad para recibir un resultado, en cuyo caso, la actividad también se devuelve el resultado de una intención
(por ejemplo, puede emitir un intento para que el usuario elija un contacto personal y lo han devuelto a usted -la intención de retorno incluye un URI que apunta al contacto seleccionado).
Para receptores de radiodifusión, la intención simplemente define el anuncio se emite (por ejemplo, una emisión para indicar la batería del dispositivo es bajo sólo incluye una cadena de acción conocida que indica "batería baja").
El tipo de otro componente, el proveedor de contenido, no está activado por las intenciones. Por el contrario, se activa cuando el blanco de una solicitud de un ContentResolver
. La resolución de contenido maneja todas las transacciones directas con el proveedor de contenido de modo que el componente que es la realización de transacciones con el proveedor no tiene por qué y en lugar de llamadas a métodos en el ContentResolver
objeto. Esto deja una capa de abstracción entre el proveedor de contenidos y la información del componente solicita (por seguridad).
Hay métodos diferentes para activiting cada tipo de componente:
-
Usted puede iniciar una actividad (o darle algo nuevo que hacer) haciendo pasar una intención
de startActivity ()
o startActivityForResult ()
(si desea que la actividad para devolver un resultado).
-
Usted puede iniciar un servicio (o dar nuevas instrucciones para un servicio continuo) al aprobar una intención
de StartService ()
. O se puede enlazar con el servicio pasando una intención
de bindService ()
.
-
Usted puede iniciar una transmisión, pasando una intención
de métodos como sendBroadcast ()
, sendOrderedBroadcast ()
, o sendStickyBroadcast ()
.
-
Usted puede realizar una consulta a un proveedor de contenidos llamando query ()
en un ContentResolver
.
Para más información sobre el uso de las intenciones, ver la intención y la intención de filtros de documentos. Más información sobre la activación de los componentes específicos también se proporciona en los siguientes documentos: Actividades , Servicios , BroadcastReceiver
y proveedores de contenido .
El archivo de manifiesto
Antes de que el sistema Android puede iniciar un componente de aplicación, el sistema debe saber que existe el componente de la lectura de la aplicación AndroidManifest.xml
archivo (el "manifiesto" de archivos). Su aplicación debe declarar todos sus componentes en este archivo, que debe estar en la raíz del directorio del proyecto de aplicación.
El manifiesto hace una serie de cosas, además de declarar los componentes de la aplicación, tales como:
-
Identificar los permisos de usuario de la aplicación requiere, tales como acceso a Internet o acceso de lectura a los contactos del usuario.
-
Declarar el mínimo nivel de la API necesaria para la aplicación, sobre la base de que la aplicación utiliza las API.
-
Declarar las características de hardware y software utilizado o requerido por la aplicación, tales como una cámara, los servicios de bluetooth, o una pantalla multitouch.
-
API bibliotecas de la aplicación debe estar vinculada en contra (que no sea la API de Android marco), como la biblioteca de Google Maps .
-
Y más
La declaración de los componentes
La tarea principal del manifiesto es informar al sistema acerca de los componentes de la aplicación. Por ejemplo, un archivo de manifiesto se puede declarar una actividad de la siguiente manera:
<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
<application android:icon="@drawable/app_icon.png" ... >
<activity android:name="com.example.project.ExampleActivity"
android:label="@string/example_label" ... >
</activity>
...
</application>
</manifest>
En el <application>
elemento, el androide: icono de
puntos de atributos a los recursos de un icono que identifica la aplicación.
En el <activity>
elemento, el androide: el nombre de
atributo especifica el nombre de clase completo de la actividad
de la subclase y el androide: la etiqueta
especifica los atributos de una cadena que se utiliza la etiqueta visible para el usuario de la actividad.
Usted debe declarar todos los componentes de la aplicación de esta manera:
<activity>
elementos para las actividades
<service>
elementos de los servicios
<receiver>
elementos para receptores de radiodifusión
<provider>
elementos para los proveedores de contenido
Actividades, servicios y proveedores de contenido que incluya en su fuente pero no se declara en el manifiesto no son visibles para el sistema y, en consecuencia, no se puede ejecutar. Sin embargo, los receptores de radiodifusión puede ser declarado en el manifiesto o creados de forma dinámica en el código (como BroadcastReceiver
objetos) e inscrita en el sistema llamando a registerReceiver ()
.
Para más información sobre cómo estructurar el archivo de manifiesto para su aplicación, consulte el Archivo de AndroidManifest.xml documentación.
La declaración de las capacidades de los componentes
Como se mencionó anteriormente, en la activación de los componentes , puede utilizar una intención
para iniciar las actividades, servicios y receptores de radiodifusión. Puede hacerlo por nombrar explícitamente el componente de destino (con el nombre de la clase de componentes) en el intento. Sin embargo, el poder real de las intenciones radica en el concepto de las acciones de la intención. Con las acciones de la intención, sólo tiene que describir el tipo de acción que desea realizar (y, opcionalmente, los datos sobre la cual desea realizar la acción) y que el sistema pueda encontrar un componente en el dispositivo que puede realizar la acción y empezar a que. Si hay varios componentes que pueden llevar a cabo la acción descrita por el intento, entonces el usuario selecciona cual usar.
La forma en que el sistema identifica los componentes que pueden responder a la intención es comparar la intención de recibir a los filtros de la intención prevista en el archivo de manifiesto de otras aplicaciones en el dispositivo.
Cuando se declara un componente en el manifiesto de su aplicación, si lo desea, puede incluir filtros intención de que declare la capacidad del componente para que pueda responder a las intenciones de otras aplicaciones. Se puede declarar un filtro de intención para el componente mediante la adición de un <intent-filter>
elemento como un elemento hijo de la declaración del componente.
Por ejemplo, una aplicación de correo electrónico con una actividad para componer un nuevo correo electrónico podría declarar un filtro de la intención de manifestar su entrada para responder a "enviar" las intenciones (para enviar correo electrónico). Una actividad en su aplicación se puede crear una intención de "enviar" la acción (ACTION_SEND
), que el sistema de partidos a la aplicación de correo electrónico de "enviar" la actividad y lo lanza al llamar a la intención con startActivity ()
.
Para más información sobre la creación de filtros intención, ver la intención y la intención de filtros de documentos.
La declaración de los requisitos de aplicación
Hay una gran variedad de dispositivos que funcionan con Android, y no todos ellos ofrecen las mismas características y capacidades. Con el fin de impedir que su aplicación se instala en los dispositivos que carecen de las características que necesita su aplicación, es importante que se definan claramente el perfil de los tipos de dispositivos de aplicación es compatible con dispositivo de declarar y los requisitos de software en el archivo de manifiesto. La mayoría de estas declaraciones son sólo informativos y el sistema no los lee, pero los servicios externos, tales como Android Market los lee con el fin de proporcionar filtrado para los usuarios cuando buscan aplicaciones de su dispositivo.
Por ejemplo, si su aplicación requiere una cámara y utiliza las API introducido en Android 2.1 ( Nivel API 7), debe declarar estos como los requisitos en el archivo de manifiesto. De esta forma, los dispositivos que hacen no tiene una cámara y tiene una versión para Android menor de 2,1 no se puede instalar la aplicación desde Android Market.
Sin embargo, también puede declarar que la aplicación utiliza la cámara, pero no requieren la misma. En ese caso, la aplicación debe realizar una comprobación en tiempo de ejecución para determinar si el dispositivo tiene una cámara y desactivar las funciones que utilizan la cámara si no está disponible.
Aquí están algunas de las características de los dispositivos importantes que usted debe tener en cuenta al diseñar y desarrollar su aplicación:
Tamaño de la pantalla y la densidad
Con el fin de clasificar los dispositivos de su tipo de pantalla, Android se definen dos características de cada dispositivo: tamaño de la pantalla (las dimensiones físicas de la pantalla) y la densidad de la pantalla (la densidad física de los píxeles en la pantalla, o dpi-puntos por pulgada). Para simplificar todos los diferentes tipos de configuraciones de pantalla, el sistema Android que se generaliza en grupos selectos que sean más fáciles de destino.
Los tamaños de pantalla son: pequeñas y grandes, normal, grande y extra grande.
La densidad de la pantalla son: baja densidad, de densidad media, alta densidad y alta densidad extra.
Por defecto, su aplicación es compatible con todos los tamaños de pantalla y densidades, ya que el sistema Android hace los ajustes necesarios al diseño de interfaz de usuario y los recursos de la imagen. Sin embargo, usted debe crear diseños especializados para ciertos tamaños de pantalla y proporcionan imágenes especializados para ciertas densidades, utilizando fuentes alternativas de diseño, y declarando en su manifiesto exactamente qué tamaños de pantalla de su aplicación es compatible con la <supports-screens>
elemento.
Para más información, consulte el apoyo de varias pantallas documento.
Configuraciones de entrada
Muchos dispositivos proporcionan un tipo diferente de mecanismo de entrada del usuario, tales como un teclado físico, trackball, o un cojín de navegación de cinco direcciones. Si su aplicación requiere un determinado tipo de hardware de entrada, entonces usted debe declararlo en su manifiesto con la <uses-configuration>
elemento. Sin embargo, es raro que una aplicación debe requerir una configuración de entrada determinado.
Las características del dispositivo
Hay muchos equipos y software que pueden o no pueden existir en un determinado dispositivo con Android, tales como una cámara, un sensor de luz, bluetooth, una cierta versión de OpenGL, o la fidelidad de la pantalla táctil. Usted nunca debe asumir que una determinada característica está disponible en todos los dispositivos con Android (que no sea la disponibilidad de la biblioteca estándar de Android), por lo que debe declarar cualquiera de las funciones que utiliza la aplicación con la <uses-feature>
elemento.
Plataforma de la versión
Diferentes con Android a menudo ejecutar diferentes versiones de la plataforma Android, como el Android 1.6 o Android 2.3. Cada versión sucesiva a menudo incluye APIs adicionales no disponibles en la versión anterior. Con el fin de indicar qué conjunto de APIs están disponibles, cada versión de la plataforma especifica un nivel de API (por ejemplo, Android 1.0 es el Nivel 1 del API y Android 2.3 es el nivel API 9). Si utiliza las API que se han añadido a la plataforma con la versión 1.0, debe declarar el nivel de API mínima a la que se introdujeron las API que utilizan los <uses-sdk>
elemento.
Es importante que declare todos los requisitos para su aplicación, ya que, al distribuir la aplicación en Android Market, el mercado utiliza estas declaraciones para filtrar qué aplicaciones están disponibles en cada dispositivo. Como tal, su aplicación debe estar disponible sólo para dispositivos que cumplen con todos los requisitos de su aplicación.
Para obtener más información acerca de cómo Android filtros de mercado de las aplicaciones sobre la base de estos requisitos (y otros), ver el mercado de filtros de documentos.
Recursos de aplicación
Una aplicación Android se compone de algo más que código que requiere de recursos que están separados desde el código fuente, como imágenes, archivos de audio, y cualquier cosa relacionada con la presentación visual de la aplicación. Por ejemplo, debe definir las animaciones, menús, estilos, colores y el diseño de interfaces de usuario con la actividad de los archivos XML. Utilizando recursos de la aplicación hace que sea fácil de actualizar varias características de su aplicación sin modificar código y mediante la provisión de sistemas de recursos alternativos, le permite optimizar la aplicación para una variedad de configuraciones de los dispositivos (tales como los diferentes idiomas y tamaños de pantalla).
Para todos los recursos que incluya en su proyecto Android, las herramientas del SDK construir definir un ID único entero, que se puede utilizar para hacer referencia al recurso de su código de aplicación o de otros recursos definidos en XML. Por ejemplo, si la aplicación contiene una imagen llamada logo.png
(salvo en el res / dibujable /
directorio), las herramientas del SDK genera un ID de recursos denominado R.drawable.logo
, que se puede utilizar para hacer referencia a la imagen e insertarla en la interfaz de usuario.
Uno de los aspectos más importantes de la provisión de recursos aparte de su código fuente es la capacidad para que usted pueda proporcionar recursos alternativos para las configuraciones de dispositivo diferente. Por ejemplo, mediante la definición de cadenas de la interfaz de usuario en XML, se puede traducir las cadenas a otros idiomas y salvar esas cadenas en archivos separados. Entonces, basado en un lenguaje de clasificación que se anexan al nombre del directorio de recursos (como res / valores fr-/
para valores de la cadena francesa) y el ajuste de idioma del usuario, el sistema Android aplica las cadenas de un lenguaje apropiado para la interfaz de usuario.
Android es compatible con muchos diferentes calificadores de los recursos alternativos. El calificador es una cadena corta que se incluye en el nombre de los directorios de sus recursos a fin de definir la configuración del dispositivo para que esos recursos deben ser utilizados. Como otro ejemplo, a menudo se deben crear diferentes diseños para sus actividades, dependiendo de la orientación de la pantalla del dispositivo y el tamaño. Por ejemplo, cuando la pantalla del dispositivo es en orientación vertical (altura), es posible que desee un diseño con botones para ser vertical, pero cuando la pantalla está en horizontal (ancho), los botones deben estar alineados horizontalmente. Para cambiar el diseño en función de la orientación, se pueden definir dos diseños diferentes y aplicar el calificativo apropiado para nombrar el directorio de cada diseño. Entonces, el sistema aplica automáticamente el diseño adecuado en función de la orientación del dispositivo actual.
Para más información sobre los diferentes tipos de recursos que se pueden incluir en su aplicación y la forma de crear recursos alternativos para diferentes configuraciones de los dispositivos, consulte la Aplicación de Recursos guía para desarrolladores.
Fuente: http://developer.android.com/guide/topics/fundamentals.html