parte_17.txt

Vicente Sancho Guijarro 34 TEMARIO OPOSICIONES COIICV | TEMA 26 4.1. Historia de Android Android Inc. era una empresa fundada para desarroll ar el software de teléfonos con más funcionalidades que los que había por aquel entonce s, lo que pasarían a llamarse teléfonos inteligentes o smartphones. Se...

Vicente Sancho Guijarro 34 TEMARIO OPOSICIONES COIICV | TEMA 26 4.1. Historia de Android Android Inc. era una empresa fundada para desarroll ar el software de teléfonos con más funcionalidades que los que había por aquel entonce s, lo que pasarían a llamarse teléfonos inteligentes o smartphones. Se lanzaron varios prot otipos para demostrar las ideas que tenían. En julio de 2005, Google adquirió Android y lo prov isionó de los recursos necesarios para continuar el desarrollo como un producto completo. A principi os de 2006, se decidió focalizar la plataforma en Java, que hasta el momento también incluía otros lenguajes como C++ o JavaScript. La primera versión del sistema operativo fue lanzad a en noviembre de 2007. Sólo consistía en un emulador hardware ejecutando el sistema Android con sus aplicaciones del núcleo, documentación de la API y un entorno de desarrollo. A partir de a quí, se fue mejorando el sistema hasta que en agosto de 2008 se alcanzó una versión estable y se integró en el T-Mobile G1 lo que sería Android 1.0. Tras su lanzamiento, en febrero de 2009, apareció l a versión 1.1. No se añadieron apenas funcionalidades, sino que se corrigieron errores de la versión anterior. En abril de 2009 vio la luz la versión 1.5 (Cup cak e). Se incorporó el teclado en pantalla con predicción de texto y los widgets de escritorio. Se añadió el soporte para Bluetooth estéreo. En septiembre de 2009 salió la versión 1.6 (Donut), facilitando la adaptación de una aplicación a las distintas densidades de las pantallas. Se añadi ó la capacidad para comandos por gestos (gestures), la síntesis de voz y la búsqueda avanza da en todo el dispositivo. Al mes siguiente, salió la versión 2.0 (Eclair), la cual tenía como principales novedades un sistema centralizado de manejo de cuentas, soporte para HTM L5, mayor velocidad de hardware y soporte para pantallas multitáctil. En enero de 2010, se la nzó la versión 2.1, con la cual compartió su nombre comercial al llevar pocas novedades, como el reconocimiento de voz. La versión 2.2 (Froyo), lanzada en mayo de 2010, su puso una gran mejora en la velocidad de ejecución de código debido a una nueva versión del compilador JIT de la máquina Dalvik. Se mejoró el navegador web con soporte para Adobe Flas h 10.1 y JavaScript V8. Se introdujo la posibilidad de compartir la conexión a Internet con otros dispositivos (tethering) y el soporte a las notificaciones push. En diciembre de 2010 apareció la versión 2.3 (Ginge rbread), con soporte para varias cámaras, NFC, soporte para giroscopio y barómetro, mejoras e n la máquina virtual Dalvik con un nuevo recolector de basura y se cambió el sistema de arch ivos de YAFFS a ext4. Para mejorar la experiencia con tabletas, en febrer o de 2011 se lanzó versión 3.0, con un rediseño de la interfaz, introduciendo la posibilidad de sus tituir los botones físicos por botones en la pantal la. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Concepto, evolución y tendencias de los sistemas op erativos TEMARIO OPOSICIONES COIICV | TEMA 26 35 Ese mismo año aparecieron las versiones 3.1 y 3.2, con mejoras menores, por lo que a todas las versiones 3.x se les llamó Honeycomb. La siguiente versión fue la 4.0 (Ice Cream Sandwich ), lanzada en octubre de 2011, que básicamente aunaba las características de las versi ones anteriores (2.x para móviles y 3.x para tabletas), en una sola versión compatible con cualq uier dispositivo. La versión 4.1 (Jelly Bean) fue lanzada en julio de 2012, la cual hizo hincapié en mejorar la fluidez de la interfaz de usuario. También apareció por pri mera vez el asistente Google Now. En octubre de 2013, se liberó la versión 4.4 (KitKa t), donde se recortaron componentes para hacer funcionar Android también en dispositivos con un ha rdware más limitado. Se introdujo la máquina virtual ART, destinada a sustituir Dalvik, mejorand o notablemente los tiempos de ejecución. En noviembre de 2014, llegó la versión 5.0 (Lollipo p), con la sustitución definitiva de ART por Dalvik y la extensión de Android a otras plataforma s (Android Wear -relojes-, Android TV - televisores- y Android Auto -vehículos-). Android 6.0 (Mashmallow) fue la siguiente versión, en octubre de 2015. La principal novedad fue la introducción del administrador de permisos, de form a que el usuario puede gestionar cada permiso de forma individual en cada aplicación. 4.2. Características de Android 4.2.1. Principios de diseño de Android • Proveer de una plataforma completa de código abiert o para dispositivos móviles. • Fuerte soporte a aplicaciones de terceros, mediante una API robusta y estable, proporcionado en un SDK (Software Development Kit) bien definido. • Permitir a todas las aplicaciones de terceros compe tir entre sí, así como con las propias aplicaciones de Google. Android debe permanecer neu tral en esta competencia. • Proveer de un modelo de seguridad de aplicaciones. • Dar soporte a las interacciones típicas de los usua rios con el dispositivo móvil, las cuales se suelen caracterizar por gastar cortos espacios d e tiempo en varias aplicaciones. • Gestionar los procesos del usuario, simplificando l a experiencia (p.e. el usuario no debe preocuparse de cerrar las aplicaciones) y gestionan do eficientemente la memoria. • Facilitar la colaboración entre las diferentes apli caciones. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Vicente Sancho Guijarro 36 TEMARIO OPOSICIONES COIICV | TEMA 26 • Crear un sistema operativo completo de propósito ge neral, no limitarse a ser una versión reducida de los sistemas operativos de escritorio, lo que también facilitará el crecimiento del mismo. 4.2.2. Arquitectura de Android Internamente, Android está formado por cuatro capas : núcleo de Linux, Runtime de Android, las librerías nativas y el entorno de aplicación. Figura 7: Arquitectura de Android • El núcleo de Linux. Android está construido sobre e l núcleo Linux estándar, con algunas extensiones. Proporciona servicios como la segurida d, el manejo de la memoria, el multiproceso, la pila de protocolos y el soporte de drivers para dispositivos. Es la única capa dependiente del hardware, ya que actúa como ca pa de abstracción entre el hardware y el resto de la pila. El primer proceso de usuario es init, el cual es la raíz de todos los demás. El proceso init inicia una serie de demonios a bajo nivel, como es el gestor de archivos o el acceso al hardware. Uno de estos procesos es zygote, el cual es el proceso raíz de todos los procesos a alto-nivel programados con Java. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Concepto, evolución y tendencias de los sistemas op erativos TEMARIO OPOSICIONES COIICV | TEMA 26 37 • Runtime de Android. Está basado en el concepto de m áquina virtual utilizado en Java. Pero Google decidió crear una máquina virtual nueva (Dal vik) que se adaptara mejor a las limitaciones de los dispositivos móviles (poca memo ria, procesador limitado). Los ficheros ejecutables en Dalvik llevan la extensión .dex y ca da aplicación se ejecuta en su propio proceso Linux, con su propia instancia de la máquin a virtual. A partir de la versión Android 5.0 se reemplazó Dalvik por ART, la cual consigue r educir el tiempo de ejecución de código hasta en un 33%. También se incluye en el runtime de Android el módu lo Core Libraries, el cual contiene la mayoría de las librerías disponibles en Java. • Librerías Nativas. Incluye un conjunto de librerías en C/C++ usadas en varios componentes de Android, las cuales están compiladas en código n ativo del procesador. Muchas de las librerías utilizan proyectos de código abierto. Alg unas de estas librerías son:
System C library: una derivación de la librería BSD de C estándar (libc), adaptada para dispositivos embebidos basados en Linux.
Media Framework: librería basada en OpenCORE de Pac ketVideo. Soporta codecs de reproducción y grabación de multitud de formatos de audio y vídeo e imágenes MPEG4, H.264, MP3, AAC, AMR, JPG y PNG.
Surface Manager: maneja el acceso al subsistema de representación gráfica en 2D y 3D.
WebKit/Chromium: soporta un moderno navegador Web u tilizado en el navegador Android y en la vista Webview. En la versión 4.4, W ebKit ha sido reemplazada por Chromium/Blink, que es la base del navegador Chrome de Google.
SGL: motor de gráficos 2D.
Librerías 3D: implementación basada en OpenGL ES 1. 0 API. Las librerías utilizan el acelerador hardware 3D si está disponible, o el sof tware altamente optimizado de proyección 3D.
FreeType: fuentes en bitmap y renderizado vectorial .
SQLite: potente y ligero motor de bases de datos re lacionales disponible para todas las aplicaciones.
SSL: proporciona servicios de encriptación Secure S ocket Layer (capa de conexión segura). Entorno de aplicación. Proporciona una plataforma d e desarrollo libre para aplicaciones con gran riqueza e innovaciones (sensores, localiza ción, servicios, barra de notificaciones, etc.). Esta capa ha sido diseñada para simplificar la reutilización de componentes. Las aplicaciones pueden publicar sus capacidades y otra s pueden hacer uso de ellas (sujetas a Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Vicente Sancho Guijarro 38 TEMARIO OPOSICIONES COIICV | TEMA 26 las restricciones de seguridad). Este mismo mecanis mo permite a los usuarios reemplazar componentes. Los servicios más importantes que incluye son:
Views: conjunto de vistas, (parte visual de los com ponentes).
Resource Manager: proporciona acceso a recursos que no están incrustados en el código.
Activity Manager: maneja el ciclo de vida de las ap licaciones y proporciona un sistema de navegación entre ellas.
Notification Manager: permite a las aplicaciones mo strar alertas personalizadas en la barra de estado.
Content Providers: mecanismo sencillo para acceder a datos de otras aplicaciones (como los contactos). Una de las mayores fortalezas del entorno de aplica ción de Android es que se aprovecha el lenguaje de programación Java. El SDK de Android no acaba de ofrecer para su estándar todo lo disponible del entorno de ejecución Java (J RE), pero es compatible con una fracción muy significativa de este Por último, por encima de estas capas se encuentra la capa de las aplicaciones, las cuales se lanzan sobre la máquina virtual Dalvik/ART para gar antizar la seguridad del sistema. Referencias bibliográficas (1) Abraham Silberschatz, Peter Baer Galvin, Greg G agne (2013). Operating System Concepts, 7 th Edition. Ed Wiley. (2) Andrew Tanenbaum, Herbert Bos (2015). Modern Op erating System, 4 th Edition. Ed Pearson. (3) Jesús Tomás Gironés (2015). El gran libro de An droid, 5ª Edición. Ed Marcombo. (4) McLibre, Material Curricular Libre, http://www.mclibre.org (5) The Open Group, Unix, http://www.opengroup.org/unix (6) The Linux Kernel Archives, https://www.kernel.org Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Concepto, evolución y tendencias de los sistemas op erativos TEMARIO OPOSICIONES COIICV | TEMA 26 39 (7) Microsoft Windows, sitio oficial, https://www.microsoft.com/es-es/windows (8) Android, sitio oficial, https://www.android.com/intl/es_es (9) Kantar WorldPanel, Smartphone OS Sales market s hare, http://www.kantarworldpanel.com/global/smartphone-o s-market-share (10) Dennis M. Ritchie, Ken Thompson, The Unix Time -Sharing System, https://people.eecs.berkeley.edu/~brewer/cs262/unix .pdf (11) El Sistema Operativo GNU, https://www.gnu.org (12) Licencia Pública General GPL, https://www.gnu.org/licenses/gpl-3.0.html (13) Linux Kernel Newbies, https://kernelnewbies.org Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Vicente Sancho Guijarro 40 TEMARIO OPOSICIONES COIICV | TEMA 26 Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019TEMARIO OPOSICIONES COIICV | TEMA 27 1 Tema 27. Gestión de entornos basados en servidores con sistema Microsoft. Gestión dominios. Active Directory. Protocolos Guillem Arnau Beneito Colegiado 0809 Active Directory es la implementación de Microsoft de un servicio de directorio, a la que añade herramientas para facilitar la administra ción de usuarios y equipos de complejas organizaciones, confiriéndole la naturale za de dominio. Separa su estructura física y lógica con el fin de facilitar su gestión. Se adapta fácilmente al crecimiento o cambio de estructura de la organizaci ón gracias a la posibilidad de añadir y configurar los controladores de dominio. E l uso de estándares como DNS y LDAP le dota de capacidades de conexión con otros s istemas no propios de Microsoft. Es posible el uso de diferentes versiones de Window s, tanto de clientes como servidores, permitiendo la actualización paulatina de los sistemas operativos sin tener que renunciar a la potencia de la administración ce ntralizada de usuarios y equipos. La posibilidad de definir grupos, tanto de equipos com o de usuarios, facilita enormemente su gestión al poder agrupar objetos que compartan c aracterísticas, ya sean funcionales, técnicas o ambas. Esta flexibilidad pa ra la definición de los objetos administrados se disfruta también en la parte admin istrativa, permitiendo que no haga falta la existencia de súper administradores obliga dos a supervisar todos los aspectos del dominio, pues se habilita la posibilidad de del egar permisos parciales a distintos usuarios con el fin de reducir y especializar la ge stión de todo el ámbito del dominio. Además, se dota al dominio de la posibilidad de apl icar políticas de gestión tanto para usuarios como equipos, con el fin de homogeneizar o particularizar configuraciones y/o restricciones. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Guillem Arnau Beneito 2 TEMARIO OPOSICIONES COIICV | TEMA 27 1. Dominios y directorios La base sobre la que se construye una red de ordena dores Microsoft en una organización es Windows Server. Sobre un servidor o un conjunto de servidores con este sistema operativo se despliegan y construyen todas las funcionalidades y herramientas para administrar tanto recursos físicos (puesto cliente, servidores, impresoras…) c omo humanos (usuarios, grupos y roles). Para facilitar la administración y gestión de los o rdenadores y servidores que forman parte de la organización nace el concepto de dominio, que no es más que el dotar a uno o varios equipos de la red de herramientas para realizar la gestión admini strativa y de seguridad de forma centralizada. Si bien ésta es la definición más genérica, Microsoft le otorga más propiedades, las cuales veremos cuando tratemos los componentes de Active Directory . Un directorio es una estructura jerárquica que alma cena y organiza la información sobre objetos existentes en la red de la organización, tanto usua rios como equipos, permitiendo: • A los administradores: gestionar el acceso de usuar ios a los recursos de dicha red. • A los usuarios: tener un único punto de entrada a l a red de la empresa, de forma que pueda tener disponible en cualquier puesto físico t odos los recursos que necesite. El directorio se apoya en un repositorio: una base de datos que contiene los objetos administrados, optimizada para operaciones de lectura, cualidad qu e le permite búsquedas de grandes volúmenes de información así como con capacidades de explorac ión. Hay muchas implementaciones de directorio, la mayor ía basadas en el protocolo X500, el cual por el tiempo sería reemplazado por LDAP (más ligero). La versión de directorio de Microsoft es Active Directory Domain Services, aunque es más conocido p or cómo se conocía con anterioridad a Windows Server 2008, Active Directory (de ahora en adelante, AD). Así pues, en Active Directory tenemos todas las características vistas de un dire ctorio añadiendo otras funcionalidades, como la distribución masiva de aplicaciones y actualizacion es de sistema a los ordenadores que se desee, entre muchas otras. 2. Active Directory Para empezar a construir un dominio para AD se debe instalar la funcionalidad de Directorio Activo en una o varias máquinas Windows Server 2000 o post erior, pues es la primera versión desde la que está disponible AD. El equipo (o equipos) en lo s que se realice la instalación se convertirá en el Controlador de Dominio, el encargado de realizar las tareas de directorio vistas anteriormente. El Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Gestión de entornos Microsoft. Active Directory TEMARIO OPOSICIONES COIICV | TEMA 27 3 resto de los equipos de la red se convertirán en lo s clientes que podrán consultar la información almacenada en el controlador. El uso de Active Directory ofrece las siguientes ve ntajas: • Asimilación e integración de DNS para resolución de nombres, con lo que se facilita la identificación de los equipos del dominio. • Potente motor de búsqueda de los objetos administra dos por el dominio gracias al catálogo global. • Extensible. Se pueden añadir objetos administrados según las necesidades lo requieran. • Uso de políticas (GPO’s, Group Policy Object ). Facilitan la gestión de permisos de usuarios y grupos sobre recursos. • Escalabilidad. La infraestructura se puede adaptar al crecimiento de la organización añadiendo dinámicamente nuevos controladores y/o do minios. • Reparcelación de información. Los controladores com partirán la información almacenada, reduciendo el tráfico de red debido a las consultas y reforzando la tolerancia a fallos. • Seguridad: AD centraliza la autenticación. La defin ición del acceso a la que puede tener un usuario y/o grupo es muy granular, se puede especif icar a nivel de atributo de objeto. • Interoperabilidad: El uso de estándares (como LDAP) le permite la conexión con otros sistemas. Para el diseño del dominio de Active Directory se d ebe partir de la estructura organizativa de la empresa, así como del conocimiento de las caracterí sticas físicas y lógicas de la red, con el fin de diseñar las dos estructuras que diferencia: las lóg icas y las físicas. El separar ambas estructuras permite que la gestión y consulta de los objetos de finidos sea independiente de los componentes elegidos para implementar la infraestructura que da soporte al dominio. 2.1. Estructuras físicas El diseño de las estructuras físicas tiene que ir e ncaminado a dimensionar los componentes que la integran para soportar el tráfico de red generado p or el uso del dominio: inicios y finales de sesión y replicaciones entre servidores son operaciones qu e requerirán de ancho de banda. Además, puede darse el caso que la organización cuente con oficinas o departamentos alejados físicamente, por lo que se deben ajustar los nodos que se ponen a disposición. A continuación, se detallan los elementos que confi guran la estructura física: sitios y controladores de dominio. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019