SISTEMAS EMBEBIDOS ACTIVIDAD No. 14 COLABORATIVO 3
GRUPO No. 11 CESAR ESCORCIA RAMIREZ - 79892083
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA CEAD JOSE ACEVEDO Y GOMEZ 25 DE OCTUBRE DE 2014
Fase 1. Sistemas operativos Realice una investigación sobre el sistema operativo Android, características, versiones, características del Kernel, etc. Android el sistema operativo móvil de Google ha ido rejuveneciéndose hasta convertirse en lo que hoy en día es Android 5.0 Lollipop, la versión más reciente de Android. Pero para hablar de Lollipop primero es necesario que conozcamos la verdadera historia de Android, una historia que en seis años ha marcado un antes y un después en el mercado de la telefonía móvil. En el año 2008. Por aquella época el Nokia N95 8 GB con el sistema operativo Symbian S60 nos mostraban el camino que parecía que seguirían los teléfonos inteligentes del futuro. Pero, al otro lado del charco, los usuarios estadounidenses recibieron de la mano de la compañía telefónica T-Mobile el que los usuarios europeos que conocemos como el HTC Dream, un teléfono inteligente considerado como el primer móvil comercial en incorporar el sistema operativo Android. El HTC Dream de la compañía taiwanesa HTC era un móvil muy sencillo: pantalla de 3.2 pulgadas con 480 x 320 píxeles de resolución, procesador mononúcleo con 528 MHz de velocidad de reloj, 256 MegaBytes de memoria interna, 3.15 megapíxeles en la cámara principal y era compatible con los politonos. Pero la verdadera especificación que caracterizaba este terminal era su sistema operativo: se trataba de Android en su versión de Android 1.0 Apple Pie, es decir, la primera versión del sistema operativo de Google. Los años fueron pasando mientras se sucedían nuevas versiones de Android tales como Android 1.1 Banana Bread (destinada únicamente a los usuarios estadounidenses y formada por pequeñas mejoras), Android 1.5 Cupcake (con novedades como la llegada del teclado virtual, los widgets en la pantalla principal, transiciones de pantalla mucho más modernas, etcétera) y Android 1.6 Donut (mejora de la tienda de Android Market con colores renovados, mejoras en la aplicación de la cámara, etcétera). Y así llegamos a los últimos meses del año 2009. Fue concretamente en octubre cuando comenzó a distribuirse Android 2.0 Eclair, una nueva versión de Android que está considerada como el trampolín que hizo posible que este sistema operativo se expandiera entre el público general. Compatibilidad con fondos de pantalla animados, compatibilidad con Bluetooth 2.1, múltiples mejoras en la aplicación de la Cámara (opción de flash, zoom digital,
modos de escena, etcétera) y una mejora general del rendimiento eran las características con las que esta versión se presentó en el mercado de la telefonía móvil de la mano de terminales como, por ejemplo, el HTC Hero. Al año siguiente, concretamente durante el mes de mayo de 2010, los usuarios recibieron una nueva actualización: Android 2.2 Froyo. Se trataba de una actualización también importante, ya que trajo consigo novedades tan esperadas como la compatibilidad con Adoble Flash 10.1 (lo que permitía reproducir archivos y páginas multimedia desde el móvil), una Radio FM, la opción de crear una zona WiFi (es decir, compartir los datos del teléfono con otro dispositivo) y una mejora general en el rendimiento. De hecho, esta fue la versión que ayudó a que el sistema operativo Android pasara de tener una cuota de mercado de un 3.5% en el año 2009 a tener una cuota de un 25.5% en el año 2010, tal y como indican los datos de aquella época. Mientras Android se expandía como la pólvora e iOS mantenía una cuota de mercado estándar, el sistema operativo Symbian comenzaba a caer en un abismo que lo conduciría a su desaparición definitiva pocos años después. Y no podemos pasar al siguiente capítulo de Android sin mencionar la versión de Android 2.3 Gingerbread. De cara al público general se trató de una actualización distribuida a finales del año 2010 con novedades tales como una renovada interfaz de usuario, una mejora a nivel interno para preparar el sistema operativo para la llegada de los procesadores de doble núcleo (todo una revolución por aquellos tiempos, ya que móviles como el Nexus S todavía incorporan un procesador mono-núcleo), un renovado teclado virtual, la introducción de los comandos de voz y la llegada de un apartado que permitía conocer las aplicaciones que se estaban ejecutando en cada momento en el móvil. Pero, además de todo ello, Android 2.3 Gingerbread tiene el dudoso honor de ser una de las versiones más problemáticas de Android. Las cifras oficiales apuntan a que la tasa de fallos de esta actualización llegó a superar el 1.7%, mientras que actualizaciones más recientes como Android 4.4 KitKat apenas alcanzaron una tasa de fallos de un 0.7%. Por ello, esta versión llegó a denominarse con el nombre de “Gingerbread de la muerte“, principalmente porque causaba muertes
súbitas en los móviles que no eran capaces de ejecutar correctamente esta actualización. Polémicas por un lado y novedades por el otro, llegamos al año 2011 y con él recibimos la actualización de Android 3.0 Honeycomb. Diseño adaptado a las tabletas, posibilidad de cambiar el tamaño de los widgets, mejoras en la barra de notificaciones, videollamadas a través de Google Talk y compatibilidad con
teclados externos fueron las principales novedades con las que se caracterizó esta versión. Pero fue a finales del año 2011, en el mes de octubre para ser exactos, cuando los usuarios recibieron una actualización que probablemente resultará mucho más familiar a los lectores: Android 4.0 Ice Cream Sandwich. Estamos hablando de una época en la que el mercado comenzaba a estar repleto de móviles con el sistema operativo de Google: HTC Sensation XL, Motorola Razr y Samsung Galaxy Nexus son algunos de los ejemplos de los teléfonos que triunfaban durante estas fechas. Y ojo, porque durante estas fechas también se lanzó al mercado el que vendría a ser uno de los móviles más vendidos de la compañía estadounidense Apple: el iPhone 4S. Android 4.0 Ice Cream Sandwich trajo consigo una interfaz completamente renovada y modernizada, la opción de crear carpetas, una fuente de letra propia, botones virtuales en la parte inferior de la pantalla para navegar por la interfaz, navegador Google Chrome activado por defecto, desbloqueo facial y otras tantas mejoras que hicieron que el sistema operativo Android estuviera completamente listo para comenzar a dominar el mercado. De hecho, los estudios oficiales de aquellos años señalaban que Android estaría presente en dos de cada tres móviles vendidos a lo largo del año 2012. El 2012 fue un año de esplendor para el sistema operativo Android. Android 4.1, Android 4.2 y Android 4.3 Jelly Bean fueron las tres siguientes actualizaciones que recibieron los móviles y las tabletas que funcionaban bajo este sistema operativo. Poco se puede decir de unas actualizaciones que dieron vida a teléfonos inteligentes tan exitosos como el Samsung Galaxy S, el Samsung Galaxy S2, el Nexus 4, el Huawei Ascend Y e, incluso, las primeras tabletas Samsung Galaxy Tab 10.1. 2013 fue el año de la introducción de una actualización que todos conocemos: Android 4.4 KitKat. Importantes mejoras en la interfaz, un nuevo teclado de emoticonos, nuevas opciones de Hangouts y significativas mejoras de rendimiento fueron las novedades con las que se presentó esta actualización en el mercado de la telefonía móvil. Y llegamos al 2014, el año en el que nos encontramos en estos momentos. Android 5.0 Lollipop es la versión que marcará la historia de este sistema operativo durante los últimos meses de este año y durante todo el año 2015. Estamos en la época de los teléfonos inteligentes con diseños y prestaciones espectaculares, la época en la que incluso los wearables (es decir, los accesorios de pulsera) están comenzando a introducirse poco a poco en el mercado de la
telefonía móvil, la época en la que Android cuenta con una cuota de mercado en Europa que alcanza el 75.8%. Resulta difícil predecir qué nos deparará el mercado de la telefonía móvil durante los próximos años, pero podemos afirmar con total seguridad que a día de hoy el sistema operativo Android está viviendo uno de los mejores momentos de su historia. Android bajo la definición de Google se considera un “Software stack” o una pila
de software, ya que esta conformada por: El sistema operativo, donde todas las funciones se desarrollan. El middleware que permite la conexión entre redes. Las aplicaciones o API’s que constituyen todos los programas que el teléfono puede
ejecutar.
Arquitectura Android En las siguientes líneas se dará una visión global por capas de cuál es la arquitectura empleada en Android. Cada una de estas capas utiliza servicios ofrecidos por las anteriores, y ofrece a su vez los suyos propios a las capas de niveles superiores, tal como muestra la siguiente figura 1.
Aplicaciones: Este nivel contiene, tanto las incluidas por defecto de Android como aquellas que el usuario vaya añadiendo posteriormente, ya sean de terceras empresas o de su propio desarrollo. Todas estas aplicaciones utilizan los servicios, las API y librerías de los niveles anteriores. Framework de Aplicaciones: Representa fundamentalmente el conjunto de herramientas de desarrollo de cualquier aplicación. Toda aplicación que se desarrolle para Android, ya sean las propias del dispositivo, las desarrolladas por Google o terceras compañías, o incluso las que el propio usuario cree, utilizan el mismo conjunto de API y el mismo "framework", representado por este nivel. Entre las API más importantes ubicadas aquí, se pueden encontrar las siguientes: Activity Manager: Conjunto de API que gestiona el ciclo de vida de las aplicaciones
en Android. Window Manager: Gestiona las ventanas de las aplicaciones y utiliza la librería
Surface Manager. Telephone Manager: Incluye todas las API vinculadas a las funcionalidades
propias del teléfono (llamadas, mensajes, etc.).
Content Provider: Permite a cualquier aplicación compartir sus datos con las
demás aplicaciones de Android. Por ejemplo, gracias a esta API la información de contactos, agenda, mensajes, etc. será accesible para otras aplicaciones. View System: Proporciona un gran número de elementos para poder construir
interfaces de usuario (GUI), como listas, mosaicos, botones, "check-boxes", tamaño de ventanas, control de las interfaces mediante teclado, etc. Incluye también algunas vistas estándar para las funcionalidades más frecuentes. Location Manager: Posibilita a las aplicaciones la obtención de información de
localización y posicionamiento. Notification Manager: Mediante el cual las aplicaciones, usando un mismo formato,
comunican al usuario eventos que ocurran durante su ejecución: una llamada entrante, un mensaje recibido, conexión Wi-Fi disponible, ubicación en un punto determinado, etc. Si llevan asociada alguna acción, en Android denominada Intent, (por ejemplo, atender una llamada recibida) ésta se activa mediante un simple clic. XMPP Service: Colección de API para utilizar este protocolo de intercambio de
mensajes basado en XML.
Librerías: La siguiente capa se corresponde con las librerías utilizadas por Android. Éstas han sido escritas utilizando C/C++ y proporcionan a Android la mayor parte de sus capacidades más características. Junto al núcleo basado en Linux, estas librerías constituyen el corazón de Android. Entre las librerías más importantes ubicadas aquí, se pueden encontrar las siguientes: Librería libc: Incluye todas las cabeceras y funciones según el estándar del
lenguaje C. Todas las demás librerías se definen en este lenguaje. Librería Surface Manager: Es la encargada de componer los diferentes elementos
de navegación de pantalla. Gestiona también las ventanas pertenecientes a las distintas aplicaciones activas en cada momento. OpenGL/SL y SGL: Representan las librerías gráficas y, por tanto, sustentan la
capacidad gráfica de Android. OpenGL/SL maneja gráficos en 3D y permite utilizar, en caso de que esté disponible en el propio dispositivo móvil, el hardware encargado de proporcionar gráficos 3D. Por otro lado, SGL proporciona gráficos en 2D, por lo que será la librería más habitualmente utilizada por la mayoría de las aplicaciones. Una característica importante de la capacidad gráfica de Android es que es posible desarrollar aplicaciones que combinen gráficos en 3D y 2D.
Librería Media Libraries: Proporciona todos los códecs necesarios para el
contenido multimedia soportado en Android (vídeo, audio, imágenes estáticas y animadas, etc.) FreeType: Permite trabajar de forma rápida y sencilla con distintos tipos de
fuentes. Librería SSL: Posibilita la utilización de dicho protocolo para establecer
comunicaciones seguras. Librería SQLite: Creación y gestión de bases de datos relacionales. Librería WebKit: Proporciona un motor para las aplicaciones de tipo navegador y
forma el núcleo del actual navegador incluido por defecto en la plataforma Android.
Tiempo de ejecución de Android: Al mismo nivel que las librerias de Android se sitúa el entorno de ejecución. Éste lo constituyen las Core Libraries, que son librerias con mulititud de clases Java y la máquina vistual Dalvik. Núcleo Linux: Android utiliza el núcleo de Linux 2.6 como una capa de abstracción para el hardware disponible en los dispositivos móviles. Esta capa contiene los drivers necesarios para que cualquier componente hardware pueda ser utilizado mediante las llamadas correspondientes. Siempre que un fabricante incluye un nuevo elemento de hardware, lo primero que se debe realizar para que pueda ser utilizado desde Android es crear las librerias de control o drivers necesarios dentro de este kernel de Linux embebido en el propio Android. Dalkiv es el nombre de la máquina virtual que utiliza Android (DalvikVM), la cual está basada en registro, diseñada y escrita por " Dan Bornstein" y algunos otros ingenieros de Google. En ella podemos encontrar una gran diferencia con respecto a la máquina virtual Java (JVM), ya que la máquina virtual de Google no está basada en una pila. ¿Por qué " Dalvik "? Éste nombre fue elegido por Bornstein en honor a Dalvík, un pueblo de pescadores de Eyjafjörður (Islandia), donde vivieron algunos de sus antepasados. Dalvik VM es un intérprete que sólo ejecuta los archivos ejecutables con formato .dex (Dalvik Executable). Este formato está optimizado para el almacenamiento eficiente de la memoria, lo cual consigue delegando en el kernel la gestión de hilos (multithreading ), de memoria y de procesos. La herramienta "dx" incluida en el SDK de Android permite transformar las clases compiladas (.class) por un compilador de lenguaje Java en formato .dex.
La Dalvik VM también ha sido optimizada para correr múltiples instancias con muy baja huella.
Figura 1. Arquitectura Android.
Aplicaciones en Android Una aplicación Android corre dentro de su propio proceso Linux, por tanto, una característica fundamental de Android es que el tiempo y ciclo de vida de una aplicación no está controlado por la misma aplicación sino que lo determina el sistema a partir de una combinación de estados como pueden ser qué aplicaciones están funcionando, qué prioridad tienen para el usuario y cuánta memoria queda disponible en el sistema. Una aplicación en Android debe declarar todas sus actividades, los puntos de entrada, la comunicación, las capas, los permisos, y las intenciones a través de AndroidManifest.xml (ver punto 3.2 Interfaces de Usuario). Es muy importante tener en consideración cómo estos componentes impactan en el tiempo de vida del proceso asociado con una aplicación, porque si no son empleados de manera apropiada, el sistema detendrá el proceso de la aplicación aún cuando se esté haciendo algo importante.
Componentes Activity: Sin duda es el componente más habitual de las aplicaciones para Android. Un componente Activity refleja una determinada actividad llevada a cabo por una aplicación, y que lleva asociada típicamente una ventana o interfaz de usuario; es importante señalar que no contempla únicamente el aspecto gráfico, sino que éste forma parte del componente Activity a través de vistas representadas por clases como View y sus derivadas. Este componente se implementa mediante la clase de mismo nombre Activity. La mayoría de las aplicaciones permiten la ejecución de varias acciones a través de la existencia de una o más pantallas. Por ejemplo, piénsese en una aplicación de mensajes de texto. En ella, la lista de contactos se muestra en una ventana. Mediante el despliegue de una segunda ventana, el usuario puede escribir el mensaje al contacto elegido, y en otra tercera puede repasar su historial de mensajes enviados o recibidos. Cada una de estas ventanas debería estar representada a través de un componente Activity, de forma que navegar de una ventana a otra implica lanzar una actividad o dormir otra. Android permite controlar por completo el ciclo de vida de los componentes Activity. Tal y como se puede ver en el siguiente punto, una actividad tiene un ciclo de vida muy definido, que será igual para todas las actividades. Este ciclo de vida es impuesto por el SDK de Android. Las actividades tienen cuatro posibles estados: Activa, pausada, parada y reiniciada.
A la hora de diseñar una aplicación en Android hay que tener en cuenta su ciclo de vida.
Intent: Un Intent consiste básicamente en la voluntad de realizar alguna acción, generalmente asociada a unos datos. Lanzando un Intent, una aplicación puede delegar el trabajo en otra, de forma que el sistema se encarga de buscar qué aplicación de entre las instaladas, es la que puede llevar a cabo la acción solicitada. Por ejemplo, abrir una URL en algún navegador web, o escribir un correo electrónico desde algún cliente de correo. Los Intents están incluidos en el AndroidManifest porque describen dónde y cuándo puede comenzar una actividad. Cuando una actividad crea un Intent, éste puede tener descriptores de lo que se quiere hacer. Una vez se está ejecutando la aplicación, Android compara esta información del Intent con los Intents de cada aplicación, eligiendo el más adecuado para realizar la operación especificada por el llamante. Broadcast Intent Receiver: Un componente Broadcast Intent Receiver se utiliza para lanzar alguna ejecución dentro de la aplicación actual cuando un determinado evento se produzca (generalmente, abrir un componente Activity ). Por ejemplo, una llamada entrante o un SMS recibido. Este componente no tiene interfaz de usuario asociada, pero puede utilizar el API Notification Manager para avisar al usuario del evento producido a través de la barra de estado del dispositivo móvil. Este componente se implementa a través de una clase de nombre BroadcastReceiver. Para que Broadcast Intent Receiver funcione, no es necesario que la aplicación en cuestión sea la aplicación activa en el momento de producirse el evento. El sistema lanzará la aplicación si es necesario cuando el evento monotorizado tenga lugar. Service: Un componente Service representa una aplicación ejecutada sin interfaz de usuario, y que generalmente tiene lugar en segundo plano mientras otras aplicaciones (éstas con interfaz) son las que están activas en la pantalla del dispositivo. Un ejemplo típico de este componente es un reproductor de música. La interfaz del reproductor muestra al usuario las distintas canciones disponibles, así como los típicos botones de reproducción, pausa, volumen, etc. En el momento en el que el usuario reproduce una canción, ésta se escucha mientras se siguen visualizando todas las acciones anteriores, e incluso puede ejecutar una aplicación distinta sin que la música deje de sonar. La interfaz de usuario del reproductor sería un componente Activity, pero la música en reproducción sería un componente Service, porque se ejecuta en background . Este elemento está implementado por la clase de mismo nombre Service. Content Provider: Con el componente Content Provider, cualquier aplicación en Android puede almacenar datos en un fichero, en una base de datos SQLite o en
cualquier otro formato que considere. Además, estos datos pueden ser compartidos entre distintas aplicaciones. Una clase que implemente el componente Content Provider contendrá una serie de métodos que permiten almacenar, recuperar, actualizar y compartir los datos de una aplicación. Existe una colección de clases para distintos tipos de gestión de datos en el paquete android.provider . Además, cualquier formato adicional que se quiera implementar deberá pertenecer a este paquete y seguir sus estándares de funcionamiento. No todas las aplicaciones tienen que tener los cuatro componentes, pero cualquier aplicación será una combinación de estos.
Estado de los procesos Como se ha mencionado anteriormente, cada aplicación de Android corre en su propio proceso, el cual es creado por la aplicación cuando se ejecuta y permanece hasta que la aplicación deja de trabajar o el sistema necesita memoria para otras aplicaciones. Android sitúa cada proceso en una jerarquía de "importancia" basada en estados, como se puede ver a continuación:
Procesos en primer plano (A c t i v e p r o c e s s ): Es un proceso que aloja una Activity en la pantalla y con la que el usuario está interactuando (su método onResume() ha sido llamado) o que un IntentReceiver está ejecutándose. Este tipo de procesos serán eliminados como último recurso si el sistema necesitase memoria.
Procesos visibles (V i s i b l e p r o c e s s ): Es un proceso que aloja una Activity pero no está en primer plano (su método onPause() ha sido llamado). Esto ocurre en situaciones dónde la aplicación muestra un cuadro de diálogo para interactuar con el usuario. Este tipo de procesos no será eliminado en caso que sea necesaria la memoria para mantener a todos los procesos del primer plano corriendo.
Procesos de servicio (S t a rt e d s e r v i c e p r o c e s s ): Es un proceso que aloja un Service que ha sido iniciado con el método startService(). Este tipo de procesos no son visibles y suelen ser importantes para el usuario (conexión con servidores, reproducción de música).
Procesos en segundo plano (B a c k g r o u n d p r o c e s s ) : Es un proceso que aloja una Activity que no es actualmente visible para el usua rio (su método onStop() ha
sido llamado). Normalmente la eliminación de estos procesos no suponen un gran impacto para la actividad del usuario. Es muy usual que existan numerosos procesos de este tipo en el sistema, por lo que el sistema mantiene una lista para asegurar que el último proceso visto por el usuario sea el último en eliminarse en caso de necesitar memoria.
Procesos vacíos (E m p t y p r o c e s s ): Es un proceso que no aloja ningún componente. La razón de existir de este proceso es tener una caché disponible de la aplicación para su próxima activación. Es común, que el sistema elimine este tipo de procesos con frecuencia para obtener memoria disponible. Según esta jerarquía, Android prioriza los procesos existentes en el sistema y decide cuáles han de ser eliminados, con el fin de liberar recursos y poder lanzar la aplicación requerida.
Figura 2. Estado de los procesos.
Para los procesos en segundo plano, existe una lista llamada LRU (Least Recently Used ). En función de esta lista se van eliminando los proces os; los primeros que se eliminan son aquellos que llevan más tiempo sin usarse. Así el sistema se asegura de mantener vivos los procesos que se han usado recientemente.
Ciclo de vida de una actividad
Figura 3. Ciclo de vida de una actividad.
El hecho de que cada aplicación se ejecuta en su propio proceso aporta beneficios en cuestiones básicas como seguridad, gestión de memoria, o la ocupación de la CPU del dispositivo móvil. Android se ocupa de lanzar y parar todos estos procesos, gestionar su ejecución y decidir qué hacer en función de los recursos disponibles y de las órdenes dadas por el usuario.
El usuario desconoce este comportamiento de Android. Simplemente es consciente de que mediante un simple clic pasa de una a otra aplicación y puede volver a cualquiera de ellas en el momento que lo desee. No debe preocuparse sobre cuál es la aplicación que realmente está activa, cuánta memoria está consumiendo, ni si existen o no recursos suficientes para abrir una aplicación adicional. Todo eso son tareas propias del sistema operativo. Android lanza tantos procesos como permitan los recursos del dispositivo. Cada proceso, correspondiente a una aplicación, estará formado por una o varias actividades independientes (componentes Activity) de esa aplicación. Cuando el usuario navega de una actividad a otra, o abre una nueva aplicación, el sistema duerme dicho proceso y realiza una copia de su estado para poder recuperarlo más tarde. El proceso y la actividad siguen existiendo en el sistema, pero están dormidos y su estado ha sido guardado. Es entonces cuando crea, o despierta si ya existe, el proceso para la aplicación que debe ser lanzada, asumiendo que existan recursos para ello. Cada uno de los componentes básicos de Android tiene un ciclo de vida bien definido; esto implica que el desarrollador puede controlar en cada momento en qué estado se encuentra dicho componente, pudiendo así programar las acciones que mejor convengan. El componente Activity, probablemente el más importante, tiene un ciclo de vida como el mostrado en la siguiente figura. De la figura anterior, pueden sacarse las siguientes conclusiones:
onCreate(), onDestroy(): Abarcan todo el ciclo de vida. Cada uno de estos métodos representan el principio y el fin de la actividad. onStart(), onStop(): Representan la parte visible del ciclo de vida. Desde onStart() hasta onStop(), la actividad será visible para el usuario, aunque es posible que no tenga el foco de acción por existir otras actividades superpuestas con las que el usuario está interactuando. Pueden ser llamados múltiples veces. onResume(), onPause(): Delimitan la parte útil del ciclo de vida. Desde onResume() hasta onPause(), la actividad no sólo es visible, sino que además tiene el foco de la acción y el usuario puede interactuar con ella. Tal y como se ve en el diagrama de la figura anterior, el proceso que mantiene a esta Activity puede ser eliminado cuando se encuentra en onPause() o en onStop(), es decir, cuando no tiene el foco de la aplicación. Android nunca elimina procesos con los que el usuario está interactuando en ese momento. Una vez se elimina el proceso, el usuario desconoce dicha situación y puede incluso volver atrás y querer usarlo de nuevo. Entonces el proceso se restaura gracias a una
copia y vuelve a estar activo como si no hubiera sido eliminado. Además, la Activity puede haber estado en segundo plano, invisible, y entonces es despertada pasando por el estado onRestart(). Pero, ¿qué ocurre en realidad cuando no existen recursos suficientes? Obviamente, los recursos son siempre limitados, más aun cuando se está hablando de dispositivos móviles. En el momento en el que Android detecta que no hay los recursos necesarios para poder lanzar una nueva aplicación, analiza los procesos existentes en ese momento y elimina los procesos que sean menos prioritarios para poder liberar sus recursos. Cuando el usuario regresa a una actividad que está dormida, el sistema simplemente la despierta. En este caso, no es necesario recuperar el estado guardado porque el proceso todavía existe y mantiene el mismo estado. Sin embargo, cuando el usuario quiere regresar a una aplicación cuyo proceso ya no existe porque se necesitaba liberar sus recursos, Android lo crea de nuevo y utiliza el estado previamente guardado para poder restaurar una copia fresca del mismo. Como se ya ha explicado, el usuario no percibe esta situación ni conoce si el proceso ha sido eliminado o está dormido.
Fase 2. Embedded Linux y uCLinux
El sistema operativo GNU/Linux, tal como lo conocemos, realiza su primera aparición en 1991 cuando se le suma al proyecto creado por Richard Stallman en 1983, denominado GNU (acrónimo recursivo que significa GNU is Not Unix) el kernel desarrollado por Linus Torvals. Luego de que Richard Stallman crea la Fundación de Software Libre (FSF, del inglés Free Software Foundation) se da origen a la Licencia Pública General GNU (GPL, del inglés GNU General Public Licence) posibilitando el desarrollo de software libre en el sistema de copyright. Esta licencia permitía a cualquier persona, programador o no, acceder al código fuente para realizar aportes y modificaciones libremente, manteniendo este software modificado la misma licencia. Este modelo de desarrollo de código abierto fomenta una comunidad que se retroalimenta con la colaboración, a través de internet, de todos los programadores alrededor del mundo. Este es el principal motivo que justifica el continuo crecimiento y expansión de GNU/Linux.
Si bien GNU/Linux ha sido desarrollado para funcionar en servidores y computadoras de escritorio, en lo últimos años y debido a su código abierto se ha ido diversificando su campo de aplicación. Así fue como en 1996 surgió un proyecto de investigación denominado RT-Linux para implementar GNU/Linux en sistemas de tiempo real, utilizando un kernel pequeño y compacto. Un año más tarde, el proyecto uClinux, comenzaba con el objetivo de utilizar GNU/Linux en procesadores sin unidades de administración de memoria (MMU, del inglés Memory Management Unit), es a partir de esta fecha y durante los 6 años subsiguientes que se comienza a utilizar ampliamente GNU/Linux en sistemas embebidos. Raghavan realiza una breve descripción de los acontecimientos más relevantes relacionados con los sistemas embebidos basados en GNU/Linux: Año 1999 •En la Conferencia de Sistemas Embebidos (ESC, del inglés Embedded Systems
Conference) de Septiembre de 1999 compañías como Lineo, FSM Labs, MontaVista y Zentropix anuncian su soporte a sistemas Linux embebidos. •Rick Lehrbaum comienza el portal de Linux embebido: Linuxdevices.com •BlueCat Linux fue anunciada como la primer distribución comercial de Linux
embebido Año 2000 Una gran cantidad de compañías adoptan Linux embebido en sus lineas de productos •Samsung lanza Yopy, una PDA con Linux embebido. •Ericsson lanza el HS210, un teléfono con pantalla que combina conectividad
inalámbrica con acceso a internet, telefonía y funciones de correo electrónico. •Atmel anuncia el lanzamiento de un dispositivo de único chip basado en Linux, el
AT75C310, que incluye soporte para VoIP y audio.
El desarrollo de herramientas y utilitarios para utilizar en el desarrollo de sistemas Linux embebidos •Busybox •Goahead •Trolltech •ViewML
Otro hecho más que importante fue la fundación del Consorcio de Linux Embebido (ELC, del inglés Embedded Linux Consortium) conformada por corporaciones como Intel e IBM cuyo objetivo fue facilitar el uso de Linux y de código abierto en áreas de sistemas embebidos. Ese mismo año el Laboratorio de Desarrollo de Código Abierto (OSDL, del inglés Open Source Development Lab) es fundado por HP, Intel, IBM y NEC con el objetivo de dar soporte empresarial a soluciones Linux. Año 2001 El gran anuncio de este año fue la liberación del kernel 2.4, la cual luego fue adoptada en la mayoría de las distribuciones embebidas de Linux. •Sharp Electronics introduce PDAs basadas en Linux. •Se libera uClibc 0.9.8, uClibc es una parte integral de la mayoría de las
distribuciones de Linux embebido. •Fue conformado el Consorcio Eclipse, formado por grandes compañías como
IBM, SuSE, Red Hat, Borland con el objetivo de proveer un entorno de desarrollo para sistemas embebidos. Año 2002-2004 Se produce el mayor avance de Linux en el mercado de sistemas embebidos. •Motorola anuncia su teléfono movil A760 que utiliza Linux como sistema operativo
embebido. •Linux alcanza mayor penetración en el mercado de dispositivos de redes como
gatways, routers, y equipos inalámbricos SOHO (del inglés, Small Office-Home Office).
El avance de GNU/Linux como sistema operativo embebido en los últimos años ha sido adoptado por la mayoría de las compañías. AMD, ARM, TI, Motorola, Intel, entre otras, han preferido utilizar GNU/Linux en sus diferentes plataformas de hardware.
Fase 3. Proyecto
BIBLIOGRAFIA
http://www.tuexpertomovil.com/2014/10/20/android-el-sistema-operativo-cuyahistoria-se-resume-en-seis-anos/ http://linuxemb.wikidot.com/tesis-c1
