API Android, Java

7/25/2019 API Android, Java

1/92

MEMORIA DEL TRABAJO DE FIN DE GRADO

INTERFAZ DE PROGRAMACIN DESOLUCIONES BIOMTRICAS BAJO BIOAPI 3.0

FRAMEWORK LESS EN PLATAFORMA

ANDROID

Rubn Romero Garca

Director: Ral Snchez Rello

Co-director: Ral Alonso Moreno


2/92

Memoria TFG Rubn Romero Garca

2

NDICE

ndice de figuras ........................................................................................................... 4

ndice de tablas ............................................................................................................. 6

ndice de acrnimos ...................................................................................................... 7

Agradecimientos ........................................................................................................... 8

Resumen ....................................................................................................................... 9

Abstract ...................................................................................................................... 10

1. Introduccin ........................................................................................................ 11

1.1. Motivacin.................................................................................................... 11

1.2. Objetivos ...................................................................................................... 12

1.3. Estructura ..................................................................................................... 13

2. Estado del arte ..................................................................................................... 14

2.1. Historia y evolucin de la telefona mvil ..................................................... 14

2.2. Sistemas Operativos ...................................................................................... 16

2.3. Historia de la biometra ................................................................................. 18

2.4. Elementos de un sistema biomtrico ............................................................. 20

2.5. Mtodos biomtricos ..................................................................................... 21

2.6. El problema de la estandarizacin ................................................................. 24

3. Tecnologas asociadas ......................................................................................... 26

3.1. Java .............................................................................................................. 26

3.2. Android ........................................................................................................ 26

3.2.1. Historia .................................................................................................. 26

3.2.2. El cdigo abierto .................................................................................... 27

3.2.3. Estructura .............................................................................................. 28

3.3. Eclipse .......................................................................................................... 29

3.4. BioAPI ......................................................................................................... 30

3.4.1. Historia .................................................................................................. 30

3.4.2. Arquitectura ........................................................................................... 31

3.4.3. BioAPI Java ........................................................................................... 35

3.5. BioAPI Framework Free ............................................................................... 35

3.5.1. Framework Free en BioAPI Java............................................................ 38


3/92


3

4. Diseo de la solucin .......................................................................................... 39

4.1. Planteamiento del problema .......................................................................... 39

4.2. Planteamiento de la solucin ......................................................................... 40

4.3. Diseo de la solucin .................................................................................... 41

4.3.1. Adaptacin del cdigo ........................................................................... 41

4.3.2. Aplicacin mvil ................................................................................... 43

4.3.1. Eliminacin del Framework ................................................................... 50

5. Desarrollo ........................................................................................................... 52

5.1. Introduccin .................................................................................................. 52

5.2. Desarrollo del portado del cdigo.................................................................. 54

5.3. Desarrollo de la aplicacin mvil .................................................................. 56

5.3.1. Clases heredadas de Java ....................................................................... 59

5.3.2. Creacin de la base de datos .................................................................. 61

5.3.3. Gestin de los datos introducidos ........................................................... 63

5.4. Desarrollo de la eliminacin del Framework ................................................. 70

5.4.1. Paquete bioapi ....................................................................................... 70

5.4.2. Paquete data ........................................................................................... 74

5.4.3. Resultado final ....................................................................................... 76

6. Pruebas .............................................................................................................. 77

6.1. Pruebas en emulador ..................................................................................... 77

6.1.1. Captura de datos .................................................................................... 77

6.1.2. Introduccin en la base de datos ............................................................. 78

6.1.3. Pruebas de la aplicacin final ................................................................. 79

6.1.4. Borrado de la base de datos .................................................................... 81

6.2. Pruebas en dispositivo mvil ......................................................................... 82

7. Conclusiones y lneas futuras de investigacin .................................................... 86

7.1. Conclusiones................................................................................................. 86

7.2. Lneas futuras de investigacin ..................................................................... 86

8. Referencias ......................................................................................................... 88

Anexo 1: Presupuesto.................................................................................................. 91


4/92


4

NDICE DE FIGURAS

Figura 1. Uso diario del smartphone segn sus aplicaciones (estudio por pases) ......... 11Figura 2. Handie Talkie H12-16 .................................................................................. 14

Figura 3. Motorola DynaTAC 8000X .......................................................................... 14Figura 4. Conexiones telefnicas en activo a nivel mundial ......................................... 16Figura 5. Comparativa entre sistemas operativos mviles (I) ....................................... 17Figura 6. Comparativa entre sistemas operativos mviles (II) ...................................... 17Figura 7. Comparativa entre sistemas operativos mviles (III) .................................... 18Figura 8. Comparativa entre sistemas operativos mviles (IV) .................................... 18Figura 9. Cruce de FAR y FRR. Localizacin del CER ............................................... 19Figura 10. Etapas de un sistema de identificacin biomtrica ...................................... 20Figura 11. Arquitectura de Android ............................................................................. 28Figura 12. Arquitectura de BioAPI .............................................................................. 31Figura 13. Estructura de un objeto CBEFF .................................................................. 33Figura 14. Estructura del BIR ...................................................................................... 34Figura 15. Arquitectura interna de un BSP .................................................................. 36 Figura 16. Pasos para la instalacin de una aplicacin biomtrica ................................ 37Figura 17. Estructura simplificada de BioAPI Framework Free ................................... 38Figura 19. Diagrama de flujo de la aplicacin de captura de fotos ............................... 45Figura 20. Diagrama de flujo de la aplicacin de captura de fotos sin comparacin ..... 46Figura 21. Diagrama de flujo de la aplicacin de usuario y contrasea ........................ 47Figura 22. Pantallas de la aplicacin de usuario y contrasea ...................................... 48

Figura 23. Pantallas finales de la aplicacin de usuario y contrasea ........................... 48Figura 24. Toast .......................................................................................................... 49Figura 25. Interfaz grfica final. Esquematizacin y simulacin en Eclipse ................. 49Figura 26. Ejemplo de equivalencias entre funciones de BioAPI C y BioAPI Java ...... 50Figura 28. Estructura del BioAPI Java en NetBeans .................................................... 53Figura 29. Seleccin de la versin Android ................................................................. 53Figura 30. Estructura inicial del BioAPI Android en Eclipse ....................................... 54Figura 31. Errores encontrados al portar el cdigo ....................................................... 55Figura 32. BioAPI en Android .................................................................................... 56

Figura 33. Aplicacin de AndroidHint ........................................................................ 58Figura 34. Interfaz final de la aplicacin Android ........................................................ 58Figura 35. BioAPI Framework Free en Android .......................................................... 76Figura 36. Prueba de captura de datos ......................................................................... 77Figura 37. Prueba de introduccin de datos en la base de datos ................................... 78Figura 38. Reclutamiento correcto en emulador .......................................................... 79 Figura 39. Reclutamiento errneo en emulador ........................................................... 79Figura 40. Verificacin correcta en emulador .............................................................. 80Figura 41. Verificacin errnea en emulador ............................................................... 80


5/92


5

Figura 42. Intento de verificacin previo a la introduccin de usuarios en emulador .... 81Figura 43. Borrado de la base de datos ........................................................................ 81Figura 44. Logo de BioAPI ......................................................................................... 82Figura 45. Icono de la aplicacin usando el logo de BioAPI ........................................ 82Figura 46. Inicio de la aplicacin en un dispositivo real............................................... 83Figura 47. Reclutamiento correcto en dispositivo real ................................................. 83Figura 48. Reclutamiento errneo en dispositivo real .................................................. 84Figura 49. Solicitud de verificacin sin usuarios en dispositivo real ............................ 84Figura 50. Verificacin correcta en dispositivo real ..................................................... 85Figura 51. Verificacin errnea en dispositivo real ...................................................... 85


6/92


6

NDICE DE TABLAS

Tabla 1. Costes desglosados de personal ..................................................................... 91Tabla 2. Costes desglosados de material ...................................................................... 92

Tabla 3. Costes desglosados totales ............................................................................. 92


7/92


7

NDICE DE ACRNIMOS

API: Application Programming Interface

BDB: Biometric Data Block

BFP: BioAPI Function Provider

BIR: Biometric Information Record

BSP: Biometric Service Provider

CBEFF: Common Biometric Exchange Formats Framework

CER: Cross-over Error Rate

FAR: False Acceptance Rate

FER: Failure-to-enroll Rate

FMR: False Match Rate

FRR: False Rejection Rate

FPI: Function Provider Interface

GUI: Graphical User Interface

ID: Identity/Identification/Identifier

IDE: Integrated Development Environment

IRI: Internationalized Resource Identifier

MAC: Message Authentication Code

NDK: Native Development Kit

SB: Security Block or Signature Block

SBH: Standard Biometric Header

SO: Sistema Operativo

SPI: Service Provider Interface

UUID: Universally Unique Identifier


8/92


8

AGRADECIMIENTOS

Quiero agradecerle este trabajo a la gente sin la cual sera imposible estar escribindolohoy: a mis padres, Javier y Yolanda, por su apoyo constante, y a mis hermanos Alberto

y Mario.

Tambin a todos mis amigos, sin nombres, porque seguro que me dejo alguno, porhaber estado ah siempre que lo he necesitado.


9/92


9

RESUMEN

La identificacin biomtrica es la identificacin basada en las caractersticas biolgicas,fsicas y de comportamiento de una persona. Desde hace ya varios aos es uno de los

mtodos ms usados para confirmar la identidad de una persona. Su excelente tasa dereconocimiento, sumado a su riesgo prcticamente nulo de falsificacin (si el sensordispone de mecanismos de deteccin de sujeto vivo), ha hecho que importantesorganismos como la polica o la banca lo consideren cada vez ms esencial a la hora dereconocer personas.

Por otro lado, los smartphones o telfonos inteligentes han obtenido en el ltimo

lustro una penetracin altsima en la sociedad, convirtindose en herramientasindispensables para la gran mayora de la poblacin. Sus potentes sistemas operativoslos convierten en poco menos que ordenadores de bolsillo, permitindoles realizar

acciones con un coste computacional inasumible hace poco tiempo. De entre ellos,destacan aquellos que tienen Android como Sistema Operativo (SO), al estardominando actualmente el mercado.

En este Trabajo de Fin de Grado (TFG) se ha portado el cdigo de BioAPI, uno de losestndares para aplicaciones biomtricas ms importantes, desde Java hacia Android.Adems se han realizado los cambios necesarios en el mismo para que cumpla lasespecificaciones de Framework Free, con el fin de poder usarlo sin problemas endispositivos con poca memoria como pueden ser los smartphones de baja gama. Porltimo se ha creado una aplicacin Android que utiliza el cdigo creado, sin otro

propsito que el de comprobar su funcionamiento.

El presente documento introduce al lector en la tecnologa empleada y describe elproceso de desarrollo de la plataforma BioAPI Framework Free y de la aplicacin.


10/92


10

ABSTRACT

Biometric identification, i.e, the identification that is based in biophysics and behavioralcharacteristics of a person, has been, for several years, one of the most used methods to

verify the identity of someone. It has an excellent ratio of correct recognition and it isvery hard to forge, and both points are making this science increasingly important for

police or banking to recognize people.

Furthermore, smartphones have become essential for most people since last five years.They have powerful operating systems (like Android, the dominant at the moment) thatallow them to make actions which computational cost was unacceptable a couple yearsago, becoming them in a sort of pocket computers.

In this paper it has been done the transcription of the BioAPIs code, one of the most

important standards for biometric applications, from Java to Android. Also, it has beenapplied the pertinent changes in that code to carry out the demanded requirements of theFramework Free version, for its use in low cost devices without large memory capacity.At last, an Android application has been created which implements that code, with the

purpose of checking it out.

This document introduces the reader in the used technology and describes thedevelopment process of the transcription and the creation process of the application.


11/92


11

1. INTRODUCCIN

A lo largo de esta memoria se va a presentar un TFG que tiene como finalidad laimplementacin del estndar BioAPI (ISO/IEC 19784-1) en su modalidad de

Framework Free, para la plataforma Android. Como mtodo de prueba de dichaimplementacin, se ha creado una aplicacin de identificacin mediante usuario ycontrasea que utiliza su cdigo. La utilidad de este trabajo es dar un paso ms en laimplantacin de la identificacin biomtrica en dispositivos mviles.

1.1. Motivacin

Desde la explosiva aparicin que protagonizaron los smartphones a mediados de ladcada pasada, han ido cobrando importancia paulatinamente hasta convertirse

actualmente en la herramienta ms usada por una gran cantidad de personas, por delantede otras ms potentes como pueden ser los ordenadores. Una de las posiblesexplicaciones para este fenmeno es la flexibilidad que proporcionan los dispositivosmviles: ya sea para conectarse a internet, usar una aplicacin concreta, comunicarseverbal o textualmente con alguien o simplemente para jugar, leer o escuchar msica,estos instrumentos eliminan la necesidad de estar anclado a un lugar fijo. La idea no esnueva: existen desde hace tiempo e-books, consolas porttiles, reproductores MP3 ymviles; sin embargo, los smartphones anan todas las funciones de esos dispositivosen uno solo, y los usuarios utilizan al mximo todas ellas, como puede verse en laFigura 1[1]. Desde un punto de vista tecnolgico, un smartphone no supera a un MP3 sise habla de reproduccin de msica, ni tiene las cualidades de pantalla que posee un e-

book. Pero puede realizar las funciones de ambos de una forma ms que correcta, lo queelimina la necesidad de tener que llevar un dispositivo para cada funcin.

Figura 1. Uso diario del smartphone segn sus aplicaciones (estudio por pases)


12/92


12

Un ordenador porttil sera capaz de realizar todas esas funciones con mayor eficacia,pero los smartphones tienen una enorme ventaja sobre ellos: el tamao. Caben en unbolsillo, frente a las quince pulgadas de pantalla y tres kilogramos de peso que puedetener un porttil, siendo de esta manera mucho ms cmodos de usar. Esta unin defuncionalidad, comodidad y flexibilidad que proporcionan los smartphones (y de formams reciente las tablets) los ha convertido en una tecnologa imprescindible para lasociedad actual.

Dentro de los diferentes sistemas operativos que existen para dispositivos mviles, hayque destacar Android, que a da de hoy domina el mercado. Esta plataforma ha ganadomucho peso en los ltimos aos y posee un potencial enorme con vistas al futuro. Tantoen el mbito laboral como en el personal, dominar los conceptos bsicos de este sistemaoperativo representa una gran ventaja, y observando el ndice de crecimiento que poseees lgico suponer que cada vez ser ms esencial para cualquier desarrollador. Por

tanto, introducirse en el mundo de la programacin para dispositivos mviles en elsistema operativo que ms presencia tiene actualmente es una de las motivaciones paraeste trabajo.

Por otro lado, la biometra es un campo que, si bien es cierto que lleva ms de un siglodesarrollndose, ha experimentado un gran salto en las ltimas dcadas. Mtodos

biomtricos como el reconocimiento facial, de geometra de mano, de iris o de voz handejado de ser parte de la literatura de ciencia ficcin para convertirse en una realidad. Amedida que el inters industrial por esta ciencia fue creciendo, surgi un grave problemaen lo referente al uso de tcnicas biomtricas en ambientes informticos. Al no existir

un estndar relativo a ello, cada proveedor suministraba su propia interfaz de softwarepara sus productos, lo que dificultaba o incluso imposibilitaba a las empresas el cambiode producto o de vendedor. Para tratar de solucionar este problema se fund BioAPIConsortium, un consorcio que desarroll un estndar para la conexin entre dispositivos

biomtricos y sus aplicaciones. Ms adelante se hablar con detalle de dicho estndar;de momento basta con decir que portarlo hacia una plataforma nueva, ayudando al pasode las tecnologas biomtricas a los dispositivos mviles, es otra de las motivaciones

principales del presente trabajo.

1.2.

Objetivos

Al hablar de los objetivos es conveniente separarlos en dos partes: los que forman eltrabajo en s, es decir, los requisitos y especificaciones que ha de cumplir la aplicacinfinal, y los que se persiguen en cuanto a lo que la realizacin del trabajo le aporta alalumno.

En el terreno tecnolgico, el primer objetivo es portar el cdigo de BioAPI desde Javahasta Android. La primera versin del estndar BioAPI que se hizo fue creada en C


13/92


13

(ISO/IEC 19784-1). Actualmente, es la nica versin comercializada y con una normapublicada. Existen otras dos versiones: una en C# (ISO/IEC 30106-3, en desarrollo) yotra, inacabada, en Java (ISO/IEC 30106-2), como las nicas versiones en programacinorientada a objetos. En este trabajo se pide crear una versin nueva escrita paraAndroid, a partir de la versin de Java. Adems, el cdigo debe cumplir los requisitosque exige la norma de la versin Framework Free del BioAPI C. Por tanto, el segundo y

principal objetivo es adaptar esos requisitos a la programacin orientada a objetos (yaque la versin Java actual no dispone de versin Framework Free) y aplicarlos a lanueva versin creada en Android.

Por ltimo, el tercer objetivo es crear una aplicacin que utilice la versin de BioAPIFramework Free que se habr creado en Android, con el fin de comprobar elfuncionamiento de la misma.

En cuanto al aprendizaje del alumno, el primer objetivo es la familiarizacin con unanueva plataforma, Android, y un nuevo entorno de desarrollo, Eclipse, completamentedistintos a los aprendidos durante los estudios del Grado. La obligacin de aprender atrabajar con estas herramientas desde cero es una de las mejores formas de asegurar queel estudiante domina las bases de las mismas, ya que sin ellas no se puede avanzar en un

proyecto nuevo.

Un segundo objetivo, menos evidente que el primero, es la introduccin del alumno enun tipo de trabajo similar al que se encuentra luego en el mundo laboral: los proyectos.Salvo pequeas imitaciones en ciertas asignaturas, no se realizan proyectos de

envergadura a lo largo de la carrera, y sta es, por tanto, la primera toma de contacto delalumno con lo que se le exigir cuando comience a trabajar.

1.3. Estructura

En el presente documento se realizar una breve introduccin a la tecnologa con elanlisis del estado del arte y las tecnologas asociadas. Este apartado incluye loslenguajes de programacin empleados: Java y su adaptacin a la plataforma Android; elentorno de desarrollo usado: Eclipse; y una breve exposicin de la historia del estndar

BioAPI y de su versin Framework Free. A continuacin se explicar cmo se hallegado a la solucin final entre los distintos planteamientos y alternativas que existan.Tras esto se expondr de forma precisa el desarrollo de dicha solucin, los problemasencontrados y la forma de resolverlos, as como las pruebas realizadas para asegurar sucorrecto funcionamiento. Por ltimo se puede encontrar una breve conclusin queincluye el peso que puede tener este proyecto en lneas de trabajo futuras.


14/92


14

2. ESTADO DEL ARTE

En este captulo se introducir al lector en la tecnologa. Se realizar un breve resumende la historia de la telefona mvil y se hablar de los diversos sistemas operativos para

dispositivos mviles existentes. A continuacin, se realizar una introduccin a labiometra, desde sus inicios hasta la actualidad, y se explicarn los diversos elementos ytcnicas que existen en este campo.

2.1. Historia y evolucin de la telefona mvil

La bsqueda de un sistema de comunicacin a distancia que funcionase de forma mvilha sido una constante desde los inicios de la Segunda Guerra Mundial. El considerado

por muchos como el primer telfono mvil de la historia, el Handie Talkie H12-16, que

puede verse en la Figura 2[2]

, fue lanzado por Motorola durante esta poca. Funcionabamediante ondas de radio y se usaba para mantener la informacin entre las tropasconstantemente actualizada.

Figura 2. Handie Talkie H12-16

Tras este prototipo, la comunicacin inalmbrica comenz un lento pero imparableascenso. Martn Cooper fabric el primer radio telfono entre 1970 y 1973 en EEUU,siendo imitado por la compaa NTT en el mercado japons (1979). En los aossucesivos se fueron introduciendo importantes modificaciones y mejoras, con el fin de

perfeccionar el sistema, y finalmente, en la dcada de los 80 nace la primera generacin

de telfonos mviles con la creacin del Motorola DynaTAC 8000X (verFigura 3[3]).

Figura 3. Motorola DynaTAC 8000X


15/92


15

Era un telfono caro, grande, pesado y antiesttico, pero tambin era el primer telfonomvil destinado al uso civil y supuso una revolucin para su poca. Aunque fueconcebido como un mtodo para mantener una comunicacin constante entre losdistintos sectores de una empresa, la idea cal en el pblico y pronto empezaron acomercializarse modelos destinados al pblico en general.

Aos ms tarde, en la dcada de los 90 y en plena evolucin desde la tecnologa mvilanalgica hacia la digital, se cre el estndar GSM (Sistema Global para lasComunicaciones Mviles, del francs Groupe Spcial Mobile) que, al ser digital,

permita ms enlaces simultneos en un mismo ancho de banda. Adems, integrabaotros servicios en la misma seal, como el envo y recepcin de mensajes de texto(SMS) o una elevada capacidad de envo y recepcin de datos desde dispositivos de faxy mdem: mediante una conexin con un ordenador era posible la navegacin porinternet o la recepcin y envo de correos electrnicos. Por si esto fuera poco, daba al

usuario la posibilidad de estar comunicado fuera del alcance de su red, utilizando la deotra compaa, mediante la itinerancia. Los operadores de red tambin acogieron conagrado este sistema, ya que con l podan elegir entre mltiples proveedores de sistemasGSM, al ser un estndar abierto que no necesitaba pago de licencias.

Este estndar fue el primer paso hacia la popularizacin actual de los telfonos mviles.Tras l, continuaron apareciendo mejoras, dirigidas principalmente hacia una mayorcapacidad de transmisin de datos, cuyo culmen lleg con el nacimiento de la tercerageneracin, basada en el protocolo UMTS (Servicio Universal de TelecomunicacionesMviles, del ingls Universal Mobile Telecommunications System). Los puntos fuertes

de este sistema eran sus capacidades multimedia, una transmisin de voz con calidadequiparable a la de las redes fijas y una elevada velocidad de acceso a Internet que

permita el envo de voz y datos simultneamente en forma de videollamada.

Sin embargo, a pesar de las continuas mejoras, la verdadera revolucin en el campo dela telefona mvil lleg de la mano de los telfonos inteligentes o smartphones. El

primer telfono catalogado como smartphone fue el GS88 de Ericsson de 1997. Apartir de ese momento, diversas compaas fueron desarrollando modelos similares:Microsoft en 2001 con su Windows CE Pocket PC OS, RIM en 2002 con BlackBerry,

Nokia en 2007 con el N95, Apple, tambin en 2007, con el iPhone, y finalmente

Google, en 2010, con el Nexus One, el primer smartphone basado en el sistemaoperativo Android.[4]

Estos dispositivos se construyen sobre una plataforma informtica mvil, aunando lascapacidades de un telfono convencional con otras propias de un ordenador personal.Entre las diferencias que existen con los mviles anteriores estn: la posibilidad deinstalar aplicaciones -incluso desde terceros- la funcin multitarea, el GPS o el acceso ainternet va WiFi o 3G. Aunque algunos telfonos 3G ya disponan de esta ltimacapacidad, la velocidad y la calidad de la transmisin de datos mejoran notablemente en


16/92


16

los smartphones. Por estos y otros motivos, desde la irrupcin de estos dispositivos, lacantidad de lneas telefnicas en activo ha aumentado notablemente, como puede verseen laFigura 4[5].

Figura 4. Conexiones telefnicas en activo a nivel mundial

2.2. Sistemas Operativos

Los sistemas operativos de los smartphones son el equivalente en dispositivos mviles asus homnimos en ordenadores personales. Al estar diseados para controlar unatecnologa menos potente son ms simples y sus funciones principales son laconectividad inalmbrica y la gestin del flujo de informacin y datos que entran ysalen del telfono.

Su programacin interna se estructura en capas. La bsica, el ncleo o kernel, es la quegestiona el acceso a los distintos elementos del hardware mediante drivers. Tambin seocupa de la gestin de procesos y de memoria y del sistema de archivos. Suele estar

basado en un SO para ordenadores, como puede ser Windows, Linux o Unix. Elsiguiente nivel es el middleware, un conjunto de mdulos que mueven las aplicaciones.

En esta capa se encuentran los cdecs multimedia, los intrpretes de pginas web o elmotor de mensajera y comunicaciones, entre otros. Un nivel ms arriba se encuentra elentorno de ejecucin de aplicaciones, que se ocupa de gestionarlas y consta de unconjunto de interfaces que pueden ser usadas por los desarrolladores para crear nuevosoftware. Por ltimo, en el nivel superior se encuentran las interfaces de usuario, que

permiten la interaccin persona-mquina por medio de componentes grficos, comobotones y campos de texto, y realizan la presentacin visual de las aplicaciones.

Adems de estas capas tambin existen una serie de aplicaciones nativas del telfono noeliminables, como los mens o el marcador de nmeros[6].


17/92


17

Hasta la llegada de Android, el primer SO de cdigo abierto, cada empresa tena supropio SO implantado en sus terminales. Por ello hay una gran variedad, siendo los msimportantes Windows Mobile, Palm OS, Symbian, iPhone OS, BlackBerry y Android.Cada uno tiene sus ventajas y sus inconvenientes, como se puede ver en la comparativarealizada en lasFigura 5, Figura 6,Figura 7 yFigura 8[7].

Figura 5. Comparativa entre sistemas operativos mviles (I)

Figura 6. Comparativa entre sistemas operativos mviles (II)


18/92


18

Figura 7. Comparativa entre sistemas operativos mviles (III)

Figura 8. Comparativa entre sistemas operativos mviles (IV)

Como se puede ver en la comparativa, todos tienen sus puntos fuertes, por lo que no

resulta apropiado hablar de un SO mejor que otro de forma general. Sin embargo, parael tema que se trata en este trabajo, Android es el SO ms apropiado, ya que

proporciona muchas facilidades a los desarrolladores y adems, al ser el que mayorcuota de mercado tiene, posibilita que ms personas tengan acceso a las aplicacionescreadas.

2.3. Historia de la biometra

La biometra es la ciencia que clasifica, registra e identifica a las personas mediante sus

caractersticas biolgicas, fsicas y/o de comportamiento. Se cree que los antiguosegipcios ya usaban mtodos biomtricos, concretamente la firma, para confirmar laidentidad de las personas, y se sabe con seguridad que los comerciantes chinosdistinguan a los nios mediante impresiones en papel de la huella de la palma de lamano ya desde el siglo XIV.

En Europa, la identificacin biomtrica comenz a utilizarse en el siglo XIX con finespoliciales. Originalmente la comparacin se haca de forma tosca, confiando en lamemoria visual; bsicamente consista en reconocer o no al sospechoso, basndose en


19/92


19

las caractersticas fsicas que el polica encargado consiguiera recordar, hasta que en1883 un miembro de la polica parisina, Alphonse Bertillon, desarroll el sistemaantropomtrico de clasificacin. Este mtodo funcionaba midiendo de forma precisaciertas longitudes y anchuras del cuerpo y la cabeza del individuo, y registrando marcas

personales indelebles como tatuajes, manchas o cicatrices. Fue usado ampliamente hastaque se descubrieron dos personas diferentes con el mismo conjunto de medidas. Estedescubrimiento releg la antropometra a la categora de pseudociencia, y oblig a

buscar una alternativa para la identificacin policial de sospechosos[8].

Fue en el ao 1892 cuando Francis Galton, un antroplogo ingls, realiz las primeraspruebas satisfactorias de identificacin de criminales mediante huella dactilar basndoseen los estudios de Henry Faulds sobre la unicidad y estabilidad de las mismas durantela vida de un individuo. Este nuevo mtodo se impuso rpidamente, convirtindose en

poco tiempo en la forma oficial de identificacin en diversos pases. Es tal su eficacia

que en la actualidad, aunque los mtodos de archivo y comparacin han mejoradonotablemente, an se usan los cuatro rasgos seleccionados por Galton para diferenciardos huellas entre s: arcos, presillas internas, presillas externas y verticilos.[9]

Aunque la huella dactilar sigue siendo el ms empleado, a lo largo del siglo XX se hanpropuesto y estudiado una gran cantidad de mtodos biomtricos nuevos. En 1936 elpatrn de iris fue sugerido como mtodo de identificacin por Frank Burch, idea que fuedesarrollada finalmente entre 1985 y 1994 por Leonard Flom y Aran Safir, usando losalgoritmos de reconocimiento de John Daugman. En el 2006 se evaluaron los mejoresalgoritmos de reconocimiento facial, resultando algunos tan exactos que distinguan

entre gemelos idnticos. Tambin se han propuesto y desarrollado mtodos deidentificacin que emplean la vascularizacin, la firma, la voz, el modo de andar

Prcticamente cualquier caracterstica biofsica tiene su propio estudio biomtrico, conmayor o menor eficacia.

La eficacia de un mtodo biomtrico depende de su tasa de falso positivo o FAR, de sutasa de falso negativo o FRR y de la de fallo de alistamiento o FMR. En los dispositivosreales se cruzan ambas tasas y el sistema se ajusta segn el punto de cruce, conocidocomo CER, como puede verse en la Figura 9[10]. Cuanto ms bajo es el CER, msexactitud proporciona el sistema.[11]

Figura 9. Cruce de FAR y FRR. Localizacin del CER
http://commons.wikimedia.org/wiki/File:Biometrics_error.jpg?uselang=es


20/92


20

2.4. Elementos de un sistema biomtrico

En todos estos sistemas se sigue un esquema predefinido de obtencin de datos que esindependiente del mtodo biomtrico utilizado y puede verse en la Figura 10. Esteesquema consta de dos fases: reclutamiento y verificacin. Ninguna de ellas tienesentido sin la otra, y ningn sistema biomtrico est completo si le falta alguna.

Figura 10. Etapas de un sistema de identificacin biomtrica

En el reclutamiento se toman una o varias muestras del usuario, se procesan (rotacin,ampliacin o reduccin, limpieza de ruido, etc.) y se extraen sus caractersticas para

extraer un patrn individual que se almacenar. Este proceso se lleva a cabo de formasupervisada por una segunda persona que compruebe en cada momento que el usuarioque est siendo reclutado es realmente quien dice ser.

Segn el tipo de mtodo biomtrico que se emplee en el sistema, las muestras puedenser tomadas en un mismo da (iris, huella dactilar) o en varios (voz, cara) para asegurarque el patrn toma en cuenta la variabilidad existente. Las caractersticas extradasdependen tanto del mtodo biomtrico como del algoritmo empleado, ya que existendistintas formas de comparar muestras incluso dentro del mismo mtodo (por ejemplo,comparar huellas mediante las cuatro marcas de Galton, o mediante un conjunto

diferente de caractersticas individuales).

En la verificacin, proceso en el que no es necesaria supervisin, se extrae una muestrabiomtrica del usuario. Se repiten los pasos del reclutamiento: se procesa la muestra yse extraen las caractersticas. A continuacin, se comparan con las que el sistemacontiene almacenadas, y se devuelve un resultado positivo o negativo.

La verificacin de la identidad de un usuario no es exacta. Las pequeas variaciones queexisten entre muestras del mismo usuario o el error que pueden tener los instrumentosde captura empleados hacen que sea inviable reducir la eleccin a un simple


21/92


21

verdadero/falso. Lo que se hace en su lugar es emplear un porcentaje umbral desemejanza, suponiendo que todo aquel individuo que lo supere en la comparacin entresu muestra y la almacenada est verificado. La eleccin de un umbral adecuado es

bsica para evaluar la fortaleza de un sistema biomtrico, ya que uno demasiado elevadodisparara la tasa de falsos negativos, mientras que un umbral muy bajo hara que la tasade falsos positivos fuese inaceptablemente alta.

Por ltimo hay que indicar que la identificacin puede ser de dos tipos. Con el primertipo, llamado reconocimiento, se compara al usuario introducido con todos losexistentes en el sistema, y en el caso de encontrar una coincidencia se comunica que laidentidad ha sido confirmada. El otro tipo es conocido como autenticacin, y sediferencia del reconocimiento en que el usuario introduce la muestra biomtrica y susupuesta identidad; tras ello, el sistema nicamente compara los datos introducidos conlos que posee correspondientes a la identidad introducida.

2.5. Mtodos biomtricos

Prcticamente cualquier caracterstica biolgica o de comportamiento de una personapuede ser usada para su identificacin. Normalmente las biolgicas se consideran msexactas, ya que cualquier caracterstica de comportamiento es potencialmente imitable,y por tanto, podra no garantizar la identificacin con un nivel de error losuficientemente bajo. Algunos de los parmetros a tener en cuenta al analizar la eficaciade una tcnica biomtrica son la universalidad, es decir, si las caractersticas se pueden

extraer de cualquier usuario, la unicidad, que es la probabilidad de que no existan dospersonas con las mismas caractersticas, la facilidad de captura, el rendimiento, laaceptacin por los usuarios, la estabilidad de la muestra, es decir, si permaneceinalterable durante la vida del usuario, la robustez frente al fraude o el coste.

A continuacin se presentan algunos de los mtodos que se estudian actualmente para laidentificacin biomtrica, incluyendo algunos cuya implantacin es ya una realidad,haciendo un breve repaso de sus pros y sus contras. Es conveniente empezar esta

presentacin haciendo hincapi en el hecho de que no existe la tcnica biomtricaperfecta: una que proporcione una fiabilidad casi absoluta pero que exija un t iempo de

proceso grande puede no ser la ms adecuada si el tiempo es un factor limitante.

Cada tcnica tiene sus ambientes de aplicacin destacados, y es necesario un estudioprevio del entorno antes de elegir una de ellas.

Huella dactilar: Es la que tiene una aceptacin mayor. Se usa desde el siglo XIXy existen numerosos estudios que prueban tanto la estabilidad de la huella a lolargo de la vida como su unicidad. La facilidad de extraccin y el escaso costede los dispositivos que emplean esta tcnica ha permitido que siga compitiendo


22/92


22

con otras biomtricamente ms exactas pero ms caras, como el iris, o deextraccin ms complicada, como el ADN.Como punto en contra, su uso por parte de la polica para identificar criminalesha hecho que la poblacin asocie este mtodo con actos delictivos, por lo quealgunas empresas prefieren invertir un poco ms en una tcnica ms cara que notenga implcita esa imagen policial.

ADN: Es la nica tcnica conocida que ha conseguido garantizar un cien porcien de xito. Mediante comparacin de ADN la identidad de una persona quedaconfirmada sin posibilidad de fallo, ya que no hay dos personas que compartanel mismo. Como contrapartida, existe una gran dificultad a la hora de procesarlos resultados en tiempo real, necesitndose mucho ms tiempo para realizar lacomparacin que con otros sistemas. Adems, las tcnicas de extraccin (saliva,sangre, sudor) son muy invasivas y el usuario tiende a rechazarlas.

Iris: Los sistemas que emplean esta tcnica parten de los algoritmos creados porJohn Daugman en 1993. Tiene unos resultados excelentes y de gran fortaleza, yhay estudios que confirman la inalterabilidad del iris a lo largo de la vida, ascomo su unicidad, siendo esta ltima muy superior a la de la huella dactilar.Adems, la tcnica de extraccin no es invasiva ni tiene connotaciones policialesnegativas. La nica razn por la que esta tecnologa no es la ms usada a nivelmundial es el elevado coste de los equipos.

Voz: Es una de las tcnicas ms estudiadas, ya que la creacin de un sistemafiable de reconocimiento biomtrico basado en la voz hara posible elreconocimiento de una persona de forma remota mediante algo tan sencillo,accesible y barato como un telfono. Sin embargo, y aunque existen algunossistemas que responden de forma bastante correcta, la voz est sujeta a mltiplesvariaciones, tales como la edad, las enfermedades o simples cambios en elestado de nimo. El umbral del sistema debe rebajarse de forma notable para

poder asimilar estos cambios, lo que lo convierte en menos fiable de lo preciso.Adems, es muy propenso al fraude, ya que al no necesitar presencia fsica basta

con una grabacin para burlarlo. Para solucionar este problema, algunossistemas obligan al usuario a repetir una locucin aleatoria determinada paraidentificarse.

Retina: La geometra vascular de la retina es uno de los mtodos ms seguros deidentificacin. La unicidad presentada supera incluso la del iris, y no necesitamtodos aadidos para detectar si el usuario est vivo. Sin embargo, para podertomar la muestra es necesario usar lser y la mayora de gente siente rechazohacia ello.


23/92


23

Vascular: Consiste en usar la geometra de las venas de la mano o del dedocomo mtodo de identificacin. Su uso est en estudio para ambientes donde laidentificacin digital externa (huella) sea difcil de extraer, ya sea por erosin dela misma o por suciedad.

Cara: Es una de las tecnologas que ms rpidamente est progresando. Amediados de 2006 se celebr la Face Recognition Grand Challenge, un congresodonde se presentaron nuevos algoritmos de reconocimiento facial. Se descubrique proporcionaban una fiabilidad 10 veces superior a los mejores de 2002, y100 veces superior a los de 1995. Como ventaja, el mtodo de captura es muysencillo y barato, y mtodos como la hiperresolucin del rostro hacen que lasfotos en baja calidad no sean ya un problema. La captura es tan sencilla que enocasiones el usuario no es consciente de que est siendo verificado, lo cual

puede llegar a ser potencialmente peligroso si se usa con fines poco ticos.

Como contra, es un mtodo muy sensible a variaciones muy habituales comogafas, peinado o vello facial.

Geometra de la mano: Es el mtodo biomtrico ms rpido. En un segundo escapaz de confirmar la identidad de una persona. Adems, los modelos msmodernos van actualizando su base de datos con cada introduccin, variandoalgunos detalles del usuario que pueden cambiar de una autenticacin a otra (porejemplo, adelgazamiento o cicatrizacin de heridas). Es un mtodo que estespecialmente indicado para ambientes con una gran afluencia de individuos,

donde la rapidez es un factor crtico y la seguridad puede ser ms laxa, ya que latasa de error es muy superior a otros sistemas.

Firma: Se utiliza desde antes que la huella dactilar y siempre se ha cuestionadosu fiabilidad, ya que la falsificacin es relativamente fcil. Desde hace unos aoslos mtodos no solo comprueban la firma sino tambin la dinmica de la misma:rapidez, paradas, presin sobre el papel De este modo se alcanza una

fiabilidad similar a la de un mtodo biomtrico, pero incluso de este modo suscrticos afirman que es potencialmente falsificable con el entrenamiento

adecuado.

Forma de andar: Su estudio se encuentra en desarrollo. De momento sufiabilidad es mnima, y presenta el mismo problema que el reconocimientofacial, el usuario podra no saber que est siendo analizado. De cualquier modo,como mtodo basado en el comportamiento, no hay expectativas de que supere ala firma a corto o medio plazo.[12]


24/92


24

2.6. El problema de la estandarizacin

Un estndar es algo que sirve de patrn o referencia. Aplicado al campo de lainformtica, es el conjunto de normas que debe cumplir un producto o procedimiento

para ser compatible con otro. Su finalidad principal es reducir las diferencias entreproductos y hacer ms sencilla la colaboracin y el crecimiento de las tecnologas, peroadems debe proporcionar un ambiente de estabilidad y madurez que repercuta en unmayor beneficio tanto de los consumidores como de los desarrolladores.

Histricamente, al ser la biometra un campo tan disperso, no han existido estndares enel mbito industrial. Cada fabricante desarrollaba sus propios sistemas y procedimientossegn sus normas, y cuando esta ciencia empez a expandirse la dispersin se revelcomo un importante problema. Al ser los sistemas tan diferentes entre s, los usuarios sevean obligados a redisear toda su estructura si queran cambiar de proveedor o, en

ocasiones, incluso de modelo. Invertir en tecnologa biomtrica era un negocio cuantomenos arriesgado, algo a lo que no todos los empresarios podan optar. Y por el lado delos desarrolladores, innovar resultaba una tarea casi imposible. Esto dificultaba tanto elcrecimiento del sector biomtrico como el desarrollo de numerosos sistemas

biomtricos que ofrecan resultados prometedores pero a precios elevados.

La industria biomtrica decidi solucionar el problema mediante el desarrollo de variosestndares que sirvieran de base para las futuras investigaciones reduciendo los riesgoseconmicos antes mencionados. En 2001 el ANSI (American National StandardsInstitute) desarroll el estndar ANSI X.9.84 para definir las condiciones de los

sistemas biomtricos para la industria de servicios financieros en todo lo referente a laseguridad en torno a la transmisin y almacenamiento de datos. En 2002, ANSI y elconsorcio BioAPI presentan el estndar ANSI / INCITS 358 para garantizar lainteroperabilidad entre sistemas. En 2006, el NIST, en cooperacin con el FBI, crean elestndar PIV-071006 que establece los criterios de calidad que deben cumplir losdispositivos de captura de huellas dactilares para poder ser usados en agencias federalesestadounidenses.

Internacionalmente se cre, a partir de 2003, el ISO/IEC JTC1/SC37, encargado denormalizar los distintos aspectos del Reconocimiento Biomtrico: desde la

terminologa, hasta los aspectos sociales y jurdicos, pasando por los formatos de datos,las metodologas de evaluacin y los interfaces de programacin de aplicaciones (APIs).Estructurado en 6 grupos de trabajos (working groups WG), es precisamente el WG3el que se encarg de internacionalizar el estndar BioAPI bajo el nmero ISO/IEC19784-1, el cual estuvo basado en la primera norma de ANSI, pero que evolucion en loque coloquialmente se conoci como BioAPI 2.0. Posteriormente esa norma se fueevolucionando aadiendo ms contenido a la norma, as como nuevas partes de lamisma. En la actualidad se est procediendo a unificar todo el trabajo previo, para crearel que en el futuro cercano sea conocido coloquialmente como BioAPI 3.0.


25/92


25

Dentro del mbito de dicho WG3, se plante la necesidad de tener una implementacinde BioAPI en lenguajes de orientacin a objetos, e incluso que pudiese admitir varioslenguajes. De ah surgi el proyecto de norma ISO/IEC 30106, que en la actualidad seencuentra en pleno desarrollo. Dicha norma est dividida en 3 partes, siendo la primerauna especificacin en lenguaje UML, la segunda la implementacin en lenguaje Java, yla tercera la implementacin en lenguaje C#. En el prximo captulo se profundizarms en esta temtica.

En definitiva, a lo largo de los aos surgen numerosos estndares con diversasfinalidades, buscando facilitar el crecimiento de la industria biomtrica y el desarrollode nuevos sistemas, mtodos y aplicaciones. Sin embargo, y a pesar de la buenaintencin, a da de hoy la estandarizacin biomtrica sigue siendo deficiente comparadacon la de otras tecnologas y es un campo de trabajo dentro del sector de la biometra enel que an queda mucho por avanzar.


26/92


26

3. TECNOLOGAS ASOCIADAS

En este apartado se va a realizar una introduccin a las tecnologas que han sidoempleadas en la realizacin de este trabajo. Primero se hablar del lenguaje de

programacin Java y su adaptacin para el entorno Android y del entorno de desarrolloEclipse. Tras esto, y usando de base los conceptos explicados en el apartado anteriorsobre biometra, sus tcnicas y el problema de la estandarizacin, se explicarn al lectorla importancia y las especificaciones tcnicas del estndar BioAPI, tanto en su versincompleta como en la de Framework Free.

3.1. Java

Java es un lenguaje de programacin desarrollado en 1995 por James Gosling. Es del

tipo de programacin orientada a objetos, es decir, aquella que usa interacciones entreentidades con un determinado estado, comportamiento e identidad, llamadas objetos,

para crear programas informticos.

Su sintaxis est basada en gran medida en C, Cobol y Visual Basic, pero eliminaherramientas de bajo nivel, como la manipulacin directa de punteros o la liberacin dememoria. Esto reduce muchos de los errores que tienen lugar en los lenguajes de los que

parte y lo hace ms simple y sencillo de usar.

Pero, independientemente de su sencillez, lo que hace especial al lenguaje Java es su

filosofa de independencia. Los creadores pretendan que un programa escrito en Javapudiera ejecutarse sin modificaciones en cualquier tipo de hardware, y as lo indicaroncon el axioma Write once, run anywhere. Para conseguirlo, el cdigo fuente secompila para obtener unas instrucciones simplificadas, conocidas como bytecode. Estasimplificacin se ejecuta en una mquina virtual, escrita en cdigo nativo de la

plataforma destino, que interpreta y ejecuta el cdigo. Como contrapartida, esta solucinaumenta el tiempo de reaccin, y aunque se ha mejorado mucho en este sentido desde la

primera implementacin, Java sigue siendo considerado un lenguaje ms lento queotros.

3.2. Android

3.2.1. Historia

La historia de Android comienza en 2005, ao en que Google compr la firma AndroidInc, una empresa que desarrollaba software para dispositivos mviles. A finales de 2007se anunci oficialmente la existencia de este SO, una plataforma para dispositivosmviles construida sobre la versin 2.6 del kernel de Linux. Este anuncio vino


27/92


27

acompaado de la creacin de la Open Handset Alliance (OHA), una alianza de 78compaas de software, hardware y telecomunicaciones, entre ellas autnticos gigantesen sus respectivos campos como Ebay o Google, que naci con el objetivo dedesarrollar estndares abiertos para dispositivos mviles.

3.2.2. El cdigo abierto

Desde antes de su primer lanzamiento Android levant una gran expectacin, debido alo innovador que era su proyecto y a la inmensa presencia de sus desarrolladores en elcampo de las nuevas tecnologas. Antes de profundizar en los aspectos tcnicos de esteSO, es recomendable explicar brevemente el motivo por el cual fue tan rompedor.

Los primeros telfonos mviles tenan la funcin de permitir la comunicacin entrecualquier punto del planeta, sin las limitaciones del cableado presentes en la telefona

fija. Con el tiempo, la evolucin de estos dispositivos hizo necesario el desarrollo desistemas operativos cada vez ms complejos y eficientes. BlackBerry, desarrollado porRIM, fue uno de los primeros SO que fue ms all de las funciones tpicas de SMS yllamadas de voz, revolucionando el mercado al implantar en un mvil funciones hastaentonces solo asociadas a las PDAs. Tras ste llegaron otros similares, como PalmOS oWindows, pero lo que realmente marc el punto de inflexin fue la llegada del iPhonede Apple, que funcionaba con el SO iOS y populariz, entre otras cosas, el uso de

pantallas tctiles en mviles. Todos estos SO eran similares en el hecho de que lasaplicaciones desarrolladas en ellos por personas ajenas a las compaas erandependientes de la firma del software para su implantacin. En este momento es cuando

Android, un SO libre y de cdigo abierto, irrumpe en el mercado de la mano de Google,permitiendo a terceros desarrollar sus propias aplicaciones y destruyendo con ello labarrera existente al respecto.

Es decir que, sin restar importancia a la fuerza que Google tena en esos momentos yque transmita a todos sus productos, el detalle que llamaba la atencin de Android erala facilidad que daba a cualquier persona para aprender, idear y desarrollar sus propiasaplicaciones, sin tener que salvar los mltiples inconvenientes que proporcionaban otrasfirmas. Aunque esta filosofa ya exista previamente, por ejemplo con el SO Linux,

nunca haba sido aplicada a dispositivos mviles.Para responder a la inevitable pregunta de por qu es tan sencillo programar en Android,ser necesario hacer una breve exposicin de lo que representa el cdigo abierto.

Como ya se ha comentado antes Android es un SO abierto desarrollado por unacompaa que pretende crear estndares abiertos. Tras cada actualizacin, el cdigo esliberado por la empresa desarrolladora. Dicha liberacin se realiza bajo licencia Apache,lo que permite a los desarrolladores la libertad de usarlo para cualquier propsito,distribuirlo, modificarlo y lanzar versiones modificadas de ese software. Este hecho por


28/92


28

s solo ya represent una revolucin, pero hay que tener en cuenta que, adems, Androidtiene disponibles herramientas para la programacin en los tres principales sistemasoperativos para ordenadores -Windows, MacOS y Linux- que pueden descargarsegratuitamente desde la pgina oficial. Por otro lado, la creacin de aplicaciones se haceutilizando un entorno de programacin libre (Eclipse) y mediante el uso de un lenguajecomn y extendido de programacin (Java). Como comparacin, su principalcompetidor, iOS, utiliza un lenguaje de programacin y un entorno de desarrollo propio

para sus aplicaciones, y solo facilita herramientas para su sistema operativo, MacOS,aunque actualmente existen mquinas virtuales que permiten el desarrollo en otras

plataformas, pero que suponen una ralentizacin tan grande del proceso de trabajo, quelo hace inviable.

No es de extraar que en poco tiempo Android se haya convertido en uno de los SOpara dispositivos mviles preferidos por los desarrolladores, ni que haya conseguido

una enorme cantidad de aplicaciones, muchas de las cuales son gratuitas.

3.2.3. Estructura

La estructura de Android se compone de aplicaciones ejecutadas en un framework Java,orientadas a objetos sobre el ncleo de las bibliotecas de Java en una mquina virtualDalvik con compilacin en tiempo de ejecucin. El cdigo, de ms de 12 millones delneas, contiene partes en Java, en XML, en C y en C++.

Los componentes principales de Android se pueden ver en laFigura 11[13].

Figura 11. Arquitectura de Android


29/92


30/92


30

Eclipse, en su condicin de IDE multiplataforma, proporciona soporte para diversoslenguajes de programacin, como C, C++, Cobol, Fortran, PHP o Python, pero su usoms extendido es con Java. Una caracterstica de este entorno es que las funcionalidadesno estn implantadas de forma fija, se van aadiendo mediante mdulos (plugins) segnlas necesidades del usuario, mtodo que previene una posible sobrecarga en exceso y sinnecesidad del entorno de desarrollo, o de los recursos del ordenador

En el presente trabajo se ha utilizado Eclipse en su versin de IDE Android. Para poderhacer esto, ha sido necesario integrar el plugin ADT (Android Development Tools), que

permite el uso de las herramientas y mtodos bsicos para el desarrollo de aplicacionesAndroid.

3.4. BioAPI

BioAPI es un estndar para aplicaciones biomtricas que define una Interfaz deProgramacin de Aplicaciones o API (Application Programming Interface) y unaInterfaz de Proveedores de Servicios o SPI (Service Provider Interface) a travs de lascuales puedan comunicarse dispositivos de diferentes proveedores, permitiendo de estemodo la creacin de sistemas biomtricos ms complejos mediante la interconexin dediferentes componentes.

3.4.1. Historia

El consorcio BioAPI se crea en 1998 formado por las empresas Bioscrypt, Compaq,Iridiam, Infineon, NIST, Saflink y Unisis, y contando con el apoyo de algunas de lascompaas informticas de ms peso como Hewlett-Packard o IBM. Su finalidad escrear un estndar biomtrico que solucione el problema de la estandarizacin (verapartado2.6).

El propsito de cualquier estndar es crear una base comn a partir de la cual se puedancrear distintas entidades que puedan operar entre s y que sean intercambiables, sinsufrir problemas de conexiones defectuosas. Esto incrementa la competicin entre

proveedores a la vez que reduce el riesgo para el consumidor. En el caso de BioAPI, el

objetivo principal es crear una API (Interfaz de Programacin de Aplicaciones) y unaSPI (Interfaz de Proveedores de Servicios) comunes que definan el modo en el que los

programadores de aplicaciones y los proveedores de soluciones biomtricas debendisear sus programas.

Su primera especificacin vio la luz en el ao 2000. Proporcionaba compatibilidad conotros estndares que estaban surgiendo en el momento, como Human AuthenticationAPI (HA-API), ya que todas las compaas trabajaban con el inters comn de facilitarla implementacin, adopcin y compatibilidad de las tecnologas biomtricas. Era


31/92


31

completamente independiente del sistema operativo usado y de los datos biomtricosque se tomaban de muestra.

Entre sus diversos beneficios, BioAPI permite el rpido desarrollo de aplicaciones queusen la biometra, ya que para disearlas solo hay que seguir la estructura

predeterminada, sin necesidad de idear una propia. Adems, la posibilidad deimplementacin en todos los sistemas operativos y en mltiples plataformas biomtricas

permite una mayor variedad de alternativas y mtodos. Proporciona interfaces sencillaspara las aplicaciones y mtodos estndar tanto de acceso a funciones, algoritmosbiomtricos y dispositivos, como de gestin de los datos obtenidos y de los tipos detecnologa. Tambin da acceso a los desarrolladores a mtodos slidos y seguros dealmacenamiento de datos y apoyo para la verificacin e identificacin biomtricas enentornos de computacin distribuida. Por su parte, el framework de BioAPI permite quelas aplicaciones operen interconectadas con varios mtodos biomtricos, pudiendo

elegir en cada momento cul de ellos usar.

3.4.2.Arquitectura

Un sistema BioAPI completo est estructurado por capas siguiendo un modelo API/SPI,como puede verse en laFigura 12[15]. El nivel inferior est formado por los dispositivos

biomtricos. En el siguiente escaln estn situados los Proveedores de ServiciosBiomtricos o BSPs (Biometric Service Providers), que proporcionan dichos servicios alas aplicaciones a travs de unas determinadas interfaces (SPI y API), bien mediante lagestin directa de una Unidad de BioAPI o bien mediante Proveedores de Funciones de

BioAPI o BFPs (BioAPI Function Providers). En el siguiente nivel se encuentra elFramework, que se encarga de la comunicacin entre las aplicaciones biomtricas y losBSPs. El Framework se comunica con los BSPs, situados un nivel ms abajo, mediantela interfaz SPI y con las aplicaciones, situadas un nivel ms arriba, mediante la interfazAPI.

Figura 12. Arquitectura de BioAPI


32/92


32

Las aplicaciones, situadas en el nivel ms alto de la arquitectura, estn escritas de modoque invoquen las funciones a travs del API, funciones a las que el Framework

proporciona soporte. A continuacin, el Framework invoca las funciones a travs de laespecificacin SPI y el BSP proporciona soporte a las mismas.

BFPs y Unidades

Las Unidades de BioAPI son los bloques de construccin bsicos que presentan losBSPs a las aplicaciones. Son, por decirlo de alguna manera, la idea abstracta de losdispositivos biomtricos. Se encargan de encapsular y ocultar recursos de software yhardware, como sensores o archivos.

Cada Unidad de BioAPI modela o encapsula como mximo una pieza del hardware consu software correspondiente. Se clasifican en cuatro categoras, a saber:

Unidad de sensor (Sensor Unit) Unidad de archivo (Archive Unit)

Unidad de algoritmo de equiparacin (Matching algorithm Unit)

Unidad de algoritmo de procesamiento (Processing algorithm Unit)

Una Unidad de BioAPI puede ser gestionada directamente por un BSP o, de formaindirecta, a travs de un BFP asociado a dicha Unidad. Cuando un BFP est creando laasociacin temporal entre un conjunto de Unidades y un BSP (lo que se conoce comoattach session) no puede asociar ms de una Unidad de cada categora. La clasificacinde los BFP se realiza en funcin de las Unidades que pueden gestionar, siendo las

categoras las siguientes:

BFP de sensor (Sensor BFP)

BFP de archivo (Archive BFP)

BFP de algoritmo de equiparacin (Matching algorithm BFP)

BFP de algoritmo de procesamiento (Processing algorithm BFP)

La comunicacin entre los BFPs y las Unidades durante la attach session se realizamediante una interfaz adicional (que no se encuentra representada en laFigura 12)quese conoce como Interfaz de Provisin de Funciones o FPI (Function Provider Interface).

BIR

El Registro de Identificacin Biomtrica o BIR (Biometric Identification Record) es unaestructura de datos que hace referencia a cualquier dato biomtrico que es devuelto a laaplicacin, ya sea crudo (en formato original), intermedio (pre-procesado) o

procesado. Este elemento se crea con varias finalidades: facilitar el intercambiobiomtrico de datos entre diferentes componentes o sistemas, simplificar el software yel proceso de integracin del mismo en el hardware, promover la interoperabilidad delos programas biomtricos y garantizar la compatibilidad hacia delante de los sistemas


33/92


33

biomtricos con los futuros adelantos tecnolgicos, siempre que estos tambincontinen respetando el estndar.

El BIR es una instanciacin de un objeto CBEFF (Common Biometric ExchangeFormats Framework), cuya estructura (verFigura 13) consta de una cabecera, la SBH

(Standard Biometric Header), un bloque de datos o BDB (Biometric Data Block) y porltimo, de modo opcional, un bloque de seguridad o SB (Security Block). Cada una deestas partes contiene campos con informacin detallada sobre el archivo CBEFF,aunque solo algunos de ellos son obligatorios.

Figura 13. Estructura de un objeto CBEFF

El SBH contiene informacin que describe el contenido del BDB, y consta de trescampos obligatorios (SBH Security Options, BDB Format Owner y BDB Format Type)y diecisiete opcionales, entre los que se encuentran el Patron Header Version, elBiometric Type o el Biometric Data Quality, entre otros.

Por su parte, el BDB contiene las muestras biomtricas e identifica detalladamente suformato segn el campo Format ID del SBH y teniendo en cuenta los siguientes

parmetros:

Si es estndar o de propietario.

Si es publicado o no publicado.

Si es un dato crudo (directamente obtenido del sensor), intermedio (dato

obtenido del procesamiento de un dato crudo, pero an no dispuesto para lacomparacin) o procesado (dato ya completamente procesado, que puedecompararse con la plantilla del usuario).

Si es para reclutamiento, verificacin o identificacin.

Si contiene una o ms muestras.

Si pertenece a un nico tipo biomtrico o a varios. Si es directo o encriptado, y si es con o sin signo.

Por ltimo, el bloque SB contiene parmetros asociados con la firma y/o encriptacindel BIR. Dentro de la arquitectura de BioAPI hay varias formas de garantizar laseguridad de los datos, siendo la original situarlos dentro de la propia estructuraCBEFF, en el mdulo de SB. Este campo contiene un algoritmo de identificacin contodos los parmetros necesarios para crear un mecanismo de autenticacin conocidocomo MAC (Message authentication code function). Este mtodo solo asegura laintegridad de los datos, pero el BDB puede ser encriptado para proporcionar adems la


34/92


34

privacidad adecuada. En la versin 2.0 de BioAPI el Signature Block evoluciona aSecurity Block (manteniendo las siglas SB) y adquiere la capacidad de dirigir tanto laintegridad como la privacidad de los datos.

El BIR hereda la estructura estndar del objeto CBEFF e inserta informacin dentro del

SBH que har posible que los dispositivos que implementan BioAPI sean capaces deinterpretarlo. Su estructura se puede ver en laFigura 14[16]:

Figura 14. Estructura del BIR

Los campos format owner y format type contienen informacin nica basada en una

caracterstica especfica. El primero denota el proveedor, industria, grupo de trabajo oconsorcio que define el formato del dato biomtrico que contiene el BDB. Por otro lado,el valor del segundo campo indica el formato del BDB segn lo especificado por elformat owner. Mientras que el format owner debe respetar los estndares biomtricos, elformat type puede ser un formato de dato no publicado, propiedad de un proveedordeterminado, u otro que s siga los estndares de la industria.

Cuando un BSP crea un nuevo BIR, devuelve un parmetro que lo identifica, llamadocontrolador o handle. La mayora de lasoperaciones biomtricas pueden realizarse sinextraer el BIR del BSP, lo cual favorece la rapidez ya que suele ser de gran tamao.Pero si en algn caso es necesario gestionar el BIR independientemente (ya sea paraalmacenarlo en una base de datos, moverlo a otro BSP o enviarlo a un servidor paraidentificacin o verificacin) puede hacerse a travs de dicho controlador.[17][18]


35/92


35

3.4.3. BioAPI Java

La arquitectura explicada en el apartado anterior es la aplicada en la nica versin deBioAPI que se comercializa actualmente, la correspondiente al lenguaje de

programacin C. En este trabajo, el objetivo es crear una nueva versin de BioAPI para

Android, y para ello se ha partido de una versin alternativa en Java y que, por tanto,ofrece ms facilidades para el porte.

Sin embargo, la versin Java de este estndar biomtrico no es una versin como tal. Esuna primera aproximacin, realizada por la Universidad de Purdue, que no estfinalizada y cuya norma se encuentra actualmente en desarrollo (ISO/IEC 30106-2). A

pesar de que su funcionamiento es correcto a un nivel bsico, tiene una dificultadaadida, y es que no respeta la estructura por capas del BioAPI original.

El cdigo del BioAPI C especifica, para cada funcin empleada y para cada porcin del

mismo, la capa a la que pertenece. El cdigo del BioAPI Java no lo hace, eliminamuchas funciones por ser innecesarias en programacin orientada a objetos y combinaotras. Debido a ello, y al no haber una normativa regulada donde se especifiquen lasasignaciones, es muy complicado reconocer a primera vista las correspondencias entrefunciones de C y Java, lo cual, como se ver ms adelante, representa un importanteinconveniente a la hora de implementar la arquitectura Framework Free.

El BioAPI Java est estructurado en cuatro grandes paquetes, a saber:

Paquete org.bioapi: Contiene todas las funciones necesarias para fijar, gestionar

y procesar los componentes y Unidades que interactan con el Framework deBioAPI.

Paquete org.bioapi.data: Contiene todas las estructuras de datos y modelos quedescriben interfaces para el paquete org.bioapi.

Paquete org.bioapi.net: Contiene las interfaces que se usan en las operaciones decreacin de redes.

Paquete org.bioapi.template: Este paquete se crea para reducir la redundancia decdigo al escribir las aplicaciones. Ofrece a los desarrolladores un punto deinicio desde el que escribir su cdigo, proporcionndoles directamente muchas

de las interfaces que suelen ser implementadas de forma prcticamente idnticaen la mayora de aplicaciones biomtricas.[19]

3.5. BioAPI Framework Free

La arquitectura BioAPI Framework Free se crea a partir de la eliminacin delFramework desde la arquitectura original de BioAPI. Este modelo permite laintegracin de BSPs que siguen la norma de BioAPI dentro de sistemas cuyo resto decomponentes no estn estandarizados, proporcionando la interfaz SPI (ya que, al no


36/92


36

haber dos niveles de comunicacin, la API deja de ser necesaria). Los requisitos en estecaso determinado se reducen a los mnimos imprescindibles para que el BSP tenga unfuncionamiento fiable y el resto de componentes no necesitan cumplirlos. Laarquitectura interna de los BSP que puede verse en la Figura 15[20]no cambia, aunquehay que tener en cuenta que la mayora de BSPs destinados a un uso en sistemas con elmodelo Framework Free son aplicaciones monolticas de un solo proveedor.

Figura 15. Arquitectura interna de un BSP

Para comprender bien las consecuencias de eliminar el Framework, hay que entendercul es su funcin dentro de la arquitectura de BioAPI. En el apartado anterior se haefectuado una aproximacin, indicando que el Framework es la capa de BioAPI que

permite la comunicacin entre la aplicacin biomtrica y el BSP, mediante las interfaces

API y SPI, respectivamente. Pero, yendo un poco ms all, se van a explicar acontinuacin algunas de las responsabilidades del Framework en un sistema biomtrico:el registro de componentes y la carga de los BSP y asociacin de los mismos con lasUnidades de BioAPI.

El registro de componentes contiene informacin acerca de los BFPs y los BSPsinstalados. En el modelo BioAPI hay un nico Framework con un nico registro decomponentes asociado en cada sistema biomtrico. En un sistema computacional realexistirn mltiples registros de componentes apoyados en el mismo Framework. Parahacer esto posible, cada uno de ellos se modela como un sistema biomtrico

independiente dentro del sistema general.

Mediante el uso de unas determinadas funciones internas del Framework, una aplicacinpuede obtener informacin desde el registro de componentes acerca de los BSPsinstalados, de los BFPs o del propio Framework. Tambin puede preguntar a travs deun SPI hacia un BSP concreto, en cuyo caso la informacin recibida es acerca de losBFPs instalados a los que proporciona soporte dicho BSP o de las Unidades de BioAPIque son accesibles desde el mismo.


37/92


37

La carga de los BSP y su posterior asociacin con las Unidades de BioAPI es necesariapara que una aplicacin pueda ejecutar operaciones biomtricas y consta de una serie depasos que estn esquematizados en la Figura 16[21]. Para empezar, debe acceder alFramework y, a continuacin, identificar y cargar uno o varios BSPs. Tras esto asocialos BSPs seleccionados con una o varias Unidades de BioAPI y establece una attachsessionpara ese BSP teniendo en cuenta que puede haber como mximo una Unidadde BioAPI de cada categora. Tras la asociacin el resto de funciones pueden llamarsemediante una simple referencia al BSP usado, ya que las Unidades de BioAPI seencargarn de realizar la conexin necesaria para su funcionamiento.

Figura 16. Pasos para la instalacin de una aplicacin biomtrica

Estas dos son solo un ejemplo de las funcionalidades que pierde BioAPI eliminando suFramework; hay ms, como por ejemplo la instalacin y desinstalacin de BFPs oBSPs. Dado que la arquitectura Framework Free est pensada para los sistemas

biomtricos ms sencillos, muchas de estas funcionalidades pueden ser eliminadasdirectamente, ya que su ausencia no representar un problema al ejecutar la aplicacin.Sin embargo, es posible que haya otras que deban ser implementadas en otras partes delcdigo para evitar fallos.

En laFigura 17 se puede ver una idealizacin de la estructura que se intenta conseguir,organizada por capas. Aunque realmente el cdigo no sigue esa estructura, es la formams efectiva de comprender el significado de Framework Free.


38/92


38

Figura 17. Estructura simplificada de BioAPI Framework Free

Como se ve, se ha eliminada la capa del Framework y por lo tanto una de las dosinterfaces originales de BioAPI deja de ser necesaria, concretamente la API,realizndose todas las comunicaciones entre la aplicacin y el BSP a travs de lainterfaz SPI. A niveles inferiores la arquitectura permanece igual que en la versincompleta, y las comunicaciones entre BSP y dispositivo no se ven afectadas. Adiferencia de la arquitectura general (verFigura 12)slo se ha representado un BSP yun dispositivo. Esto es debido a que BioAPI Framework Free est especialmentediseado para sistemas sencillos, de un nico componente, que necesitan un programaligero para funcionar correctamente.[17]

3.5.1.

Framework Free en BioAPI Java

Al no respetar la estructura por capas y no disponer de una normativa regulada queespecifique qu funciones de BioAPI Java se corresponden con las de BioAPI C, esmuy difcil saber qu partes del cdigo conforman el Framework. Mirando en lanormativa al respecto, aparece que el paquete org.bioapi contiene todas las funcionesnecesarias para fijar, gestionar y procesar los componentes y Unidades que interactancon el Framework de BioAPI, mientras que el paquete org.bioapi.data contiene todas lasestructuras de datos y modelos que describen interfaces para el paquete org.bioapi. En

principio se podra pensar que hay que eliminar esos dos paquetes completos, pero esuna simplificacin de la realidad, ya que muchas de esas funciones no forman parte delFramework.

Localizar dichas funciones y eliminarlas, probando en cada momento las consecuenciasque su desaparicin provocaba en el funcionamiento del programa, ha sido el mayorinconveniente a la hora de realizar el presente trabajo, y se le dedicar una atencinespecial en los apartados posteriores.


39/92


39

4. DISEO DE LA SOLUCIN

En este apartado se va a analizar detalladamente el problema planteado, considerandolas diversas soluciones que existen al mismo. Se indicar la solucin escogida, haciendo

un razonamiento de sus ventajas e inconvenientes frente a otras opciones de resolucin.Finalmente, se describir el diseo de dicha solucin, tanto el cdigo, mediantediagramas de flujo, como la interfaz grfica.

4.1. Planteamiento del problema

La finalidad de este trabajo es adaptar el estndar BioAPI a plataformas Android, parapoder disear sistemas biomtricos en dispositivos mviles.

El hecho de proporcionar una plataforma mvil para sistemas biomtricos podrasuponer una mejora en muchas situaciones, sobre todo en lo referente a seguridad eidentificacin de personas por medio de organismos gubernamentales o privados.

Sin embargo habra que estudiar a fondo el marco legal existente, y en caso de que fueranecesario, aadirle las mejoras pertinentes, para evitar abusos legales cometidosmediante el uso de este sistema. En la Ley Orgnica 1/1992, de Proteccin Ciudadana,se regulan las condiciones en que los agentes de las Fuerzas y Cuerpos de Seguridad,

siempre que ello fuese necesario para el ejercicio de las funciones de proteccin de la

seguridad que les corresponden. El artculo 20 dice:

1. Los agentes de las Fuerzas y Cuerpos de Seguridad podrn requerir, en el

ejercicio de sus funciones de indagacin o prevencin, la identificacin de las

personas y realizar las comprobaciones pertinentes en la va pblica o en el

lugar donde se hubiere hecho el requerimiento, siempre que el conocimiento de

la identidad de las personas requeridas fuere necesario para el ejercicio de las

funciones de proteccin de la seguridad que a los agentes encomiendan la

presente Ley y la Ley Orgnica de Fuerzas y Cuerpos de Seguridad.

2. De no lograrse la identificacin por cualquier medio, y cuando resulte

necesario a los mismos fines del apartado anterior, los agentes, para impedir lacomisin de un delito o falta, o al objeto de sancionar una infraccin, podrn

requerir a quienes no pudieran ser identificados a que les acompaen a

dependencias prximas y que cuenten con medios adecuados para realizar las

diligencias de identificacin, a estos solos efectos y por el tiempo

imprescindible.

()


40/92


40

4. En los casos de resistencia o negativa infundada a identificarse o a realizar

voluntariamente las comprobaciones o prcticas de identificacin, se estar a lo

dispuesto en el Cdigo Penal y en la Ley de Enjuiciamiento Criminal.[22].

Actualmente el Documento Nacional de Identidad (DNI) se considera identificacin

suficiente para una persona. La identificacin biomtrica sera un mtodo mucho mspreciso y seguro, pero al tener unas connotaciones mucho ms agresivas que la entregadel DNI, su uso debera quedar restringido para la aplicacin en los casos ms extremos,y no todos aquellos a los que hace referencia el apartado primero del artculo 20. Porotro lado, hay que tener en cuenta que slo los agentes de los Cuerpos y Fuerzas deSeguridad del Estado tienen el derecho a exigir a una persona que se identifique, segnla Ley Orgnica 15/1999, de 13 de diciembre, de Proteccin de Datos de CarcterPersonal:

Artculo 6. Consentimiento del afectado.

1. El tratamiento de los datos de carcter personal requerir el consentimiento

inequvoco del afectado, salvo que la ley disponga otra cosa.

Artculo 44. Tipos de infracciones.

Tratar datos de carcter personal sin recabar el consentimiento de las personas

afectadas, cuando el mismo sea necesario conforme a lo dispuesto en esta Ley y

sus disposiciones de desarrollo. (Infraccin grave)

Artculo 45. Tipo de sanciones.

()

2. Las infracciones graves sern sancionadas con multa de 40.001 a 300.000

euros[22].

Por lo que el uso de mtodos biomtricos para la identificacin por parte de unaempresa privada sin consentimiento previo del usuario pasara a ser un delito grave.

4.2.

Planteamiento de la solucinPara llevar a cabo la adaptacin de BioAPI en plataforma Android, lo primero que hayque hacer es redactar una nueva versin del cdigo en ese sistema operativo, lo que seconoce en trminos informticos como portar el cdigo.

A continuacin hay dos caminos. Se puede eliminar el Framework del cdigo parafinalmente crear una aplicacin que haga uso del mismo, lo que sera el mtodo mstradicional, o se puede hacer a la inversa: crear la aplicacin tras realizar la adaptacindel cdigo, y una vez comprobado que dicha aplicacin funciona, eliminar el


41/92


41

Framework y se observa si la aplicacin contina funcionando. La principal ventaja deesta segunda estrategia es que permite la localizacin de errores a medida que seeliminan las funciones del Framework, que es la parte del trabajo ms innovadora ycomplicada de implementar. De seguir el mtodo tradicional, hasta no eliminarcompletamente la capa Framework no se comprobara el funcionamiento, y en caso deque ste no fuera correcto habra que localizar los errores entre todo el cdigo nuevo.

Por lo tanto, se debe crear una aplicacin que haga uso de algunas de lasfuncionalidades del cdigo portado, y tras ello, aplicarle los requisitos de la versin deFramework Free. Como dichos requisitos solo estn indicados en la versin programadaen lenguaje C, hay que encontrar la equivalencia de los mismos en Java.Simplificndolo hasta la mnima expresin, hay que quitarle a BioAPI la capaFramework, haciendo que la aplicacin interacte directamente con el BSP.

4.3.

Diseo de la solucin

Antes de comenzar con el desarrollo, es necesario disear la solucin del problema.Mediante un anlisis del diseo de la solucin se busca llegar a aquella que es la ptimaentre todas las posibles, buscando la que ms eficientemente cumpla todos los requisitose intentando que los alcance de una forma sencilla. Para ello, hay que valorar lasventajas y desventajas de cada una de las soluciones que se podran llevar a cabo,escogiendo despus la que mejor se adapte a los objetivos que se buscan.

Como se ha dicho en el apartado 4.2, el trabajo se puede diferenciar en tres grandesbloques: la adaptacin del cdigo de BioAPI de Java hacia Android, la creacin de unaaplicacin en Android que haga uso del cdigo adaptado y la eliminacin de la capa delFramework de BioAPI. Para facilitar la lectura, se ha dividido el diseo de la solucinen tres sub-apartados, siguiendo esa estructura.

4.3.1.Adaptacin del cdigo

No existe un mtodo determinado para adaptar un cdigo de un lenguaje deprogramacin a otro. Al igual que ocurre con la traduccin de textos, un porte depende

del lenguaje inicial y del final, del tipo de programacin que implementan (no es lomismo hacerlo entre dos lenguajes de programacin funcional, que entre un lenguaje de

programacin funcional y otro de programacin lgica) y del tipo de cdigo del que sequiere realizar la adaptacin.

Cuando se quiere portar un cdigo entre dos tipos diferentes de lenguaje deprogramacin (por ejemplo al realizar la versin en Java de BioAPI desde el original enC, convirtiendo un programa escrito segn el paradigma de la programacin imperativaa la programacin orientada a objetos) lo ms habitual suele ser reescribir el cdigocompletamente. Se analizan sus funciones, sus mtodos y sus capacidades y se estudia


42/92


42

el mtodo ms eficiente de imitar su comportamiento en la plataforma de destino. Sepuede ver que es un mtodo que deja muchos aspectos a la interpretacin delprogramador que realiza el porte, y resulta en muchos casos largo y complicado, peroeficaz.

Algunas plataformas proporcionan otro mtodo para realizar este tipo de conversiones,que es la posibilidad de implementar cdigo nativo, escrito en el lenguaje de partida,directamente en la plataforma de destino. Por ejemplo, Android tiene el Kit deDesarrollo Nativo o NDK (Native Development Kit) que permite desarrollaraplicaciones en C o C++. Aunque el cdigo usado sea diferente, las aplicaciones secompilan y ejecutan del mismo modo que al usar el SDK, por lo que el rendimiento nose ve afectado. Sin embargo, para la mayora de aplicaciones el uso de esta herramientano representa una ventaja, y desde la propia gua de desarrolladores de Android serecomienda evitar su empleo salvo que sea necesario utilizar alguna herramienta no

incluida en el framework. Por lo tanto, este segundo mtodo solo se usa para casos muyespecficos, y la inmensa mayora de desarrolladores optan por portar manualmente elcdigo, ya que los beneficios que proporciona en materia de seguridad y robustezsuperan las desventajas de su complejidad[23].

Cuando lo que se quiere es portar un cdigo entre lenguajes de programacin que siguenel mismo paradigma, se usan mtodos similares, pero mucho ms simples. Lareescritura del cdigo se puede realizar manteniendo la misma estructura, sencillamentesolucionando los errores de sintaxis que puedan aparecer y cambiando los apartados delcdigo inicial que empleen herramientas inexistentes en la plataforma final. En

ocasiones, cuando los lenguajes de programacin inicial y final tienen la misma base,pueden no existir errores de sintaxis, con lo que el cdigo funcionara sinmodificaciones. En cuanto a la conversin automtica, existen muchos programas queconvierten cdigo de un lenguaje a otro, pero la dificultad de localizar los posibleserrores usando este mtodo, sumado a que entre lenguajes que comparten paradigma laconversin manual no es excesivamente complicada, hacen que, de nuevo, el primermtodo sea el ms usado, dejando el segundo para casos con cdigos simples y brevesen los que la rapidez de la adaptacin es un factor crtico.

En este trabajo se quiere portar un extenso cdigo desde un lenguaje de programacin

orientada a objetos, Java, al SO Android, que est basado en Java. Esto hace que loserrores de sintaxis que puedan surgir sean mnimos, ya que ambos lenguajes lacomparten, aunque el hecho de que el cdigo no es ni breve ni simple ya sera suficiente

para desaconsejar el uso de cualquier programa automtico.

Por tanto, la solucin ptima es realizar una conversin manual, copiando el cdigo sinmodificaciones desde el original en Java y solucionando los errores producidos por eluso de herramientas Java inexistentes en Android.


43/92


43

4.3.2.Aplicacin mvil

El primer paso para la creacin de una aplicacin Android, antes incluso de comenzar apensar en cm

API Android, Java

Documents

Transcript of API Android, Java