ASPECTOS FUNDAMENTALES DE LA APLICACIÓ N

Para escribir aplicaciones de Android, puede utilizar los lenguajes Kotlin, Java y C ++. La herramienta SDK de Android
compila su código, datos y archivos de recursos en un paquete APK-Android, que es un archivo con el sufijo .apk. El
archivo APK contiene todo el contenido de la aplicación de Android, y es un archivo que utilizan los dispositivos con
tecnología Android para instalar la aplicación.

Cada aplicación de Android reside en su propia zona de pruebas de seguridad y está protegida por las siguientes funciones
de seguridad de Android:

 El sistema operativo Android es un sistema Linux multiusuario, donde cada aplicación es un usuario diferente.
 De forma predeterminada, el sistema asigna un ID de usuario de Linux único a cada aplicación (el sistema solo
usa este ID y la aplicación desconoce el ID). El sistema establece permisos para todos los archivos de la
aplicación de modo que solo el ID de usuario asignado a la aplicación pueda acceder a ellos.
 Cada proceso tiene su propia máquina virtual (VM), por lo que un código de aplicación se ejecuta
independientemente de otras aplicaciones. De forma predeterminada, cada aplicación ejecuta su propio proceso
de Linux.
 Cuando sea necesario ejecutar cualquier componente de la aplicación, el sistema Android iniciará el proceso y
luego lo apagará cuando ya no sea necesario o el sistema deba recuperar memoria para otras aplicaciones.

De esta forma, el sistema Android implementa el principio de privilegio mínimo. En otras palabras, de forma
predeterminada, cada aplicación solo puede acceder a los componentes necesarios para realizar el trabajo y no a otros
permisos. Esto crea un entorno muy seguro en el que la aplicación no puede acceder a partes del sistema para las que no
tiene permiso. Sin embargo, las aplicaciones pueden compartir datos con otras aplicaciones de las siguientes formas y
pueden acceder a los servicios del sistema de las siguientes formas:

 Puede hacer que dos aplicaciones compartan la misma ID de usuario de Linux para que puedan acceder a los
archivos de la otra. Para ahorrar recursos del sistema, las aplicaciones con el mismo ID de usuario también
pueden coordinar la ejecución en el mismo proceso de Linux y compartir la misma VM. Estas aplicaciones
también deben estar firmadas con el mismo certificado.
 La aplicación puede solicitar permiso para acceder a los datos del dispositivo, como los contactos del usuario,
SMS, dispositivo de almacenamiento (tarjeta SD), cámara y conexión Bluetooth. El usuario debe otorgar
explícitamente estos permisos.

Describe los componentes de una aplicación

En Java o .NET estamos acostumbrados a manejar conceptos como ventanas, controles, eventos o servicios como
elementos básicos en la construcción de aplicaciones. Pues bien, en Android tendremos los mismos elementos básicos,
aunque con ligeros cambios en términos y métodos.

Repasemos brevemente el glosario Estos componentes principales pueden ser parte de una aplicación de Android o estar
relacionados con su funcionamiento. En aras de la claridad y para evitar confusiones al consultar documentos en inglés,
intentaré traducir los nombres originales de los componentes lo menos posible.

ACTIVITY
Las actividades (activity) representan los componentes principales de la interfaz gráfica de una aplicación de Android.
Puede pensar en las actividades como elementos similares a ventanas o pantallas en cualquier otro lenguaje visual.

View
Las vistas (view) son los componentes básicos para construir interfaces gráficas de aplicaciones, por ejemplo similares a
los controles Java o .NET. Al principio, Android nos proporcionaba una gran cantidad de controles básicos, como cuadros
de texto, botones, listas desplegables o imágenes, aunque también es posible ampliar las funciones de estos controles
básicos o crear nuestros propios controles personalizados.

Fragment
Los fragmentos (fragment) pueden entenderse como parte o parte de la interfaz de usuario de la aplicación (generalmente
reutilizable). De esta manera, la actividad puede contener múltiples fragmentos para formar una interfaz completa de la
aplicación, además, estos fragmentos se pueden reutilizar en diferentes actividades o partes de la aplicación. El uso de
fragmentos en la aplicación no es obligatorio, pero serán de gran utilidad en determinadas situaciones, por ejemplo,
adaptando la interfaz de nuestra aplicación a diferentes dispositivos, tamaños de pantalla, orientaciones, etc.

Service
Los servicios (service) son componentes que no tienen una interfaz gráfica ejecutándose en segundo plano.
Conceptualmente, son similares a los servicios proporcionados en cualquier otro sistema operativo. Si necesitas
interactuar con el usuario, el servicio puede realizar cualquier tipo de operación, como actualizar datos, lanzar
notificaciones e incluso mostrar elementos visuales (como actividades).

Content Provider
Un proveedor de contenidos (content provider) este es un mecanismo definido en Android para compartir datos entre
aplicaciones. A través de estos componentes, es posible compartir algunos datos de nuestra aplicación sin mostrar
información detallada sobre su almacenamiento interno, su estructura o implementación. Del mismo modo, nuestra
aplicación puede acceder a otros datos a través del proveedor de contenido definido por el proveedor de contenido.

Broadcast Receiver
Un broadcast receiver es un componente que se utiliza para detectar ciertos mensajes o ciertos mensajes generados por el
sistema o eventos globales (por ejemplo: "batería baja", "mensajes de texto recibidos", "insertar tarjeta SD", etc.) y
reaccionar ante ellos ( Cualquier aplicación puede generar mensajes) (en terminología de Android) es un tipo broadcast, es
decir, no para una aplicación específica, sino para cualquiera que quiera escucharla).
Widget
Los widgets son elementos visuales, generalmente interactivos, y pueden mostrarse en la pantalla de inicio de un
dispositivo Android y recibir actualizaciones periódicas. Permiten a los usuarios mostrar información sobre aplicaciones
directamente en la pantalla de inicio.

Intent
Un intent este es el elemento básico de comunicación entre los diferentes componentes de Android que describimos
anteriormente. Pueden entenderse como mensajes o solicitudes enviadas entre diferentes componentes de una aplicación o
entre diferentes aplicaciones. Con intenciones, puede mostrar cualquier otra actividad, iniciar servicios, enviar mensajes
de difusión, iniciar otras aplicaciones, etc.

Actividades
Las actividades son el punto de entrada para la interacción con los usuarios. Representa una sola pantalla con una interfaz
de usuario. Por ejemplo, una aplicación de correo electrónico tiene una actividad para enumerar nuevos correos
electrónicos, otra actividad para redactar un correo electrónico y otra actividad para leer el correo electrónico. Aunque
estas actividades pueden funcionar juntas para proporcionar una experiencia de usuario coherente en una aplicación de
correo electrónico, cada actividad es independiente entre sí. De esta manera, otras aplicaciones pueden iniciar cualquiera
de estas actividades (si lo permite la aplicación de correo electrónico).

 Mantenga un registro de lo que realmente le importa al usuario (lo que se muestra en la pantalla) para asegurarse
de que el sistema continúe ejecutando el proceso de actividades de alojamiento.
 Sabiendo que los procesos utilizados anteriormente contienen elementos que los usuarios pueden devolver
(actividades detenidas), por lo que estos procesos tienen mayor prioridad que otros procesos.
 Ayude a la aplicación a controlar la finalización de su proceso para que el usuario pueda volver al estado
anterior de la actividad.
 Permita que las aplicaciones implementen flujos de usuarios entre sí y permitan que los sistemas se coordinen
(el ejemplo más común es compartir).

Servicios
Un servicio es un punto de entrada general y, por varias razones, este punto de entrada le permite ejecutar su aplicación en
segundo plano. Es un componente que se ejecuta en segundo plano para realizar operaciones de larga duración o realizar
tareas de procesos remotos. El servicio no proporciona una interfaz de usuario. Por ejemplo, el servicio puede reproducir
música de fondo mientras el usuario está en otra aplicación, o puede capturar datos a través de la red sin evitar que el
usuario interactúe con la actividad. Otro componente (como una actividad) puede iniciar el servicio y permitir que se
ejecute o se vincule al servicio para interactuar.

Dos ejemplos son la salida de datos en segundo plano o la reproducción de música después de que el usuario sale de la
aplicación. Sincronizar datos o reproducir música en segundo plano también son dos servicios de inicio muy diferentes
que cambiarán la forma en que el sistema los gestiona:

 El usuario conoce la reproducción de música, por lo que la aplicación comunica este mensaje al sistema, le
indica que se ejecute en segundo plano y envía una notificación al usuario. En este caso, el sistema hará todo lo
posible para mantener el proceso de servicio en funcionamiento, porque si el servicio se interrumpe, el usuario
quedará insatisfecho.
 Los usuarios no conocen los servicios en segundo plano convencionales, por lo que el sistema tiene una mayor
libertad de gestión. Si se necesita RAM en un proceso que requiere más usuarios, puede permitir que se pause
(reiniciar más tarde).
Los servicios vinculados se están ejecutando porque otra aplicación (o sistema) le indica que los use. Básicamente, lo que
sucede es que un servicio proporciona una API para otro proceso. Por tanto, el sistema sabe que existen dependencias
entre estos procesos. Por lo tanto, si el proceso A está vinculado a un servicio en el proceso B, sabe que debe mantener el
proceso B (y los servicios correspondientes) en ejecución para el proceso A. Además, si el usuario también está interesado
en el proceso A, entonces sabe que debe tenerlo en cuenta. Debido a su flexibilidad (o no obstante), los servicios se han
convertido en componentes muy útiles de todo tipo de conceptos de sistemas convencionales.

Receptores de emisiones
El receptor de transmisión es un componente que permite al sistema entregar eventos a aplicaciones distintas al flujo de
usuario típico, de modo que la aplicación pueda responder a los anuncios de transmisión de todo el sistema. Dado que el
receptor de transmisión es otro punto de entrada bien definido para la aplicación, el sistema puede incluso entregar
transmisiones a aplicaciones que no se están ejecutando.

Por ejemplo, una aplicación puede configurar alertas para publicar notificaciones sobre eventos futuros a los usuarios. Al
transmitir la alarma al receptor de transmisión de la aplicación, la aplicación no necesita continuar ejecutándose antes de
que se active la alarma. El sistema produce muchas emisiones (por ejemplo, las que anuncian que la pantalla está apagada,
la batería está baja o la imagen ha sido capturada). La aplicación también puede comenzar a transmitir, por ejemplo, para
notificar a otras aplicaciones que los datos se han descargado al dispositivo y están disponibles para su uso.

Proveedores de contenido
El proveedor de contenido administra un conjunto de datos compartidos de la aplicación y usted puede almacenarlos en el
sistema de archivos, la base de datos SQLite, la Web o cualquier otra ubicación de almacenamiento persistente accesible
por la aplicación. A través del proveedor de contenido, otras aplicaciones pueden ver o modificar los datos si el proveedor
de contenido lo permite. Por ejemplo, el sistema Android proporciona un proveedor de contenido para administrar la
información de contacto del usuario. De esta manera, cualquier aplicación con los permisos adecuados puede consultar al
proveedor de contenido (como ContactsContract.Data) para leer y escribir información sobre una persona específica.

Para el sistema, el proveedor de contenido es el punto de entrada de la aplicación para publicar elementos de datos con
nombre y se identifica mediante el esquema de URI. Por lo tanto, la aplicación puede decidir cómo asignar los datos que
contiene al espacio de nombres URI y pasar estos URI a otras entidades, que luego pueden usarlos para acceder a los
datos. Por tanto, el sistema puede realizar algunas tareas específicas al gestionar aplicaciones:

La asignación de un URI no requiere que la aplicación siga ejecutándose, por lo que el URI puede persistir
incluso después de que se cierre la aplicación a la que pertenece. Si el sistema va a recuperar datos de la
aplicación del URI en cuestión, solo necesita asegurarse de que la aplicación del URI continúe ejecutándose.
Estos URI también proporcionan un modelo de seguridad importante y detallado. Por ejemplo, una aplicación
puede poner el URI de una imagen que tiene en el portapapeles, pero el proveedor de contenido se bloqueará
para que otras aplicaciones no puedan acceder a él libremente. Si otra aplicación intenta acceder al URI en el
portapapeles, el sistema puede usar permisos URI temporales para otorgar acceso, de modo que solo pueda usar
el URI para acceder a datos, pero no a otros datos.

Activación de componentes
De los cuatro tipos de componentes, tres (actividad, servicio y receptor de transmisión) se activan mediante mensajes
asíncronos llamados intenciones. La intención es vincular componentes juntos en tiempo de ejecución. Imagina que son
mensajeros que hacen que otros componentes soliciten acciones, ya sean de tu aplicación o de otros componentes. Utilice
el objeto Intent para crear un Intent que defina un mensaje para activar un componente específico (intención explícita) o
un tipo específico de componente (intención implícita).
Para las actividades y los servicios, la intención define la acción que se tomará (por ejemplo, ver o enviar algún contenido)
y puede especificar el URI de los datos para realizar la operación y otro contenido que puede necesitar ser conocido por el
componente inicial. Por ejemplo, una intención puede pasar una solicitud de una actividad para mostrar una imagen o
abrir una página web. En algunos casos, puede iniciar un evento para recibir resultados. En este caso, la actividad también
devolverá el resultado en el Intent. Por ejemplo, puede publicar una intención para permitir que los usuarios seleccionen
contactos personales y se los devuelvan. La intención devuelta incluye el URI que apunta al contacto seleccionado.

HAY FORMAS INDEPENDIENTES DE ACTIVAR CADA TIPO DE COMPONENTE:

 Puede iniciar la actividad o asignarle una nueva tarea pasando el Intent to startActivity o startActivityForResult
(cuando desee que la actividad devuelva resultados).
 En Android 5.0 (API nivel 21) y versiones posteriores, puede usar la clase JobScheduler para programar
operaciones. En versiones anteriores de Android, puede iniciar un servicio (o proporcionar una nueva
descripción a un servicio en ejecución) pasando un Intent a startService .
 Puede vincularse al servicio pasando el Intent a bindService . Puede comenzar a transmitir pasando el Intent a
métodos como sendBroadcast , sendOrderedBroadcast o sendStickyBroadcast .
 Puede consultar el proveedor de contenido llamando a query en ContentResolver.

El archivo de manifiesto
Para que el sistema Android inicie un componente de la aplicación, debe confirmar la existencia del componente leyendo
el archivo de manifiesto de la aplicación (AndroidManifest.xml). Su aplicación debe declarar todos sus componentes en
este archivo, que debe estar ubicado en el directorio raíz del directorio del proyecto de la aplicación.

ADEMÁS DE DECLARAR LOS COMPONENTES DE LA APLICACIÓN, EL MANIFIESTO TAMBIÉN

PUEDE HACER CIERTAS COSAS, COMO:

 Identifica los permisos de usuario requeridos por la aplicación, como el acceso a Internet o el acceso de lectura a
los contactos del usuario.
 Declare el nivel de API mínimo en función de la API utilizada por la aplicación.
 Declare las funciones de hardware y software que utiliza o requiere la aplicación, como cámaras, servicios
Bluetooth o pantallas multitáctiles.
 Declare la biblioteca de API (excepto la API del marco de trabajo de Android) que la aplicación necesita
enlazar, como la biblioteca de Google Maps.

Declaración de componentes
La tarea principal del manifiesto es informarle al sistema acerca de los componentes de la aplicación. Por ejemplo, un
archivo de manifiesto puede declarar una actividad de la siguiente manera:
En el elemento <application>, el atributo android:icon señala los recursos de un ícono que identifica la aplicación.

En el elemento <activity>, el atributo android:name especifica el nombre de clase plenamente calificado de la

subclase Activity, y el atributo android:label especifica una cadena para usar como etiqueta de la actividad visible para el
usuario.

DEBES DECLARAR TODOS LOS COMPONENTES DE LA APLICACIÓN MEDIANTE ESTOS

ELEMENTOS:

 Elementos <activity> para las actividades.

 Elementos<service> para los servicios.
 Elementos <receiver> para los receptores de emisión.
 Elementos <provider> para los proveedores de contenido.

Declaración de capacidades de los componentes

Como se mencionó anteriormente, en la activación de componentes, puede usar Intents para iniciar actividades, servicios
y receptores de transmisión. Puede usar intents nombrando explícitamente el componente de destino en la intención
(usando el nombre de clase del componente). También puede usar intenciones implícitas, que describen el tipo de
operación a realizar y, opcionalmente, los datos sobre los que se realizará la operación. Las intenciones implícitas
permiten que el sistema encuentre componentes en el dispositivo que puedan realizar una operación e iniciar la operación.
Si hay varios componentes que pueden realizar la operación descrita por la intención, el usuario selecciona el componente
que desea utilizar.

Declaración de requisitos de la aplicación

Hay muchos dispositivos que utilizan la tecnología Android, pero no todos tienen las mismas funciones. Para evitar que la
aplicación se instale en dispositivos que no tienen las funciones requeridas por la aplicación, es importante definir
claramente un archivo de configuración para los tipos de dispositivos admitidos por la aplicación; para esto, declare los
requisitos de dispositivo y software en el archivo de manifiesto. La mayoría de estas declaraciones son solo información
de referencia y el sistema no las leerá, pero los servicios externos (como Google Play) pueden proporcionar a los usuarios
opciones de filtrado al buscar aplicaciones desde el dispositivo.
Recursos de la aplicación
En Android, una aplicación no solo se compone de código; requiere recursos que son independientes del código fuente,
como imágenes, archivos de audio y otros elementos relacionados con la presentación de la aplicación. Por ejemplo,
puede utilizar archivos XML para definir animaciones, menús, estilos, colores y el diseño de la interfaz de usuario activa.
Los recursos de la aplicación le permiten actualizar fácilmente muchas funciones de la aplicación sin cambiar el código.
Además, proporcionar conjuntos de recursos alternativos le permite optimizar aplicaciones para varias configuraciones de
dispositivos, como diferentes idiomas y tamaños de pantalla.

Uno de los aspectos más importantes de proporcionar recursos independientes del código fuente es la capacidad de
proporcionar recursos alternativos para diferentes configuraciones de dispositivos. Por ejemplo, al definir cadenas de IU
en XML, puede convertir las cadenas a otros idiomas y guardarlas en un archivo separado. Luego, el sistema Android
aplicará la cadena de idioma correspondiente a su interfaz de usuario en función del calificador de idioma que adjunte al
nombre del directorio de recursos (por ejemplo, res / values-fr / para valores de cadena en francés). Idioma de usuario.

Para cambiar el diseño en función de la dirección, puede definir dos diseños diferentes y aplicar el calificador apropiado al
nombre de directorio de cada diseño. Luego, el sistema aplicará automáticamente el diseño correspondiente según la
orientación actual del dispositivo.