R3. Requisitos específicos Android

INDEX
R3.1. Compatibilidad
R3.2. Metainformación del proyecto Android Studio
R3.3. Estándares de desarrollo
R3.4. Seguridad de los datos

R3.1. Compatibilidad

Se entiende por compatibilidad no sólo que la aplicación se pueda instalar, sino que las funcionalidades principales de la aplicación se ejecutan correctamente y sin presentar errores. En caso de que una funcionalidad secundaria no funcione correctamente en un conjunto de dispositivos, esta funcionalidad no deberá mostrarse en estos dispositivos.

  • R3.1.1. Las aplicaciones Android para móvil deben ser compatibles con la mayoría de dispositivos Android presentes en el mercado. Además, las apps tendrán que ser compiladas con el último SDK estable de Android Studio. En concreto, se deben cumplir los siguientes requisitos:
    • Las versiones Android de las aplicaciones deben ser, obligatoriamente, compatibles con la versión 8.0 (API 26) y superiores del sistema operativo. En caso de existir algún impedimento para ser así, hay que comunicarlo y justificarlo a la OSAM antes de comenzar el desarrollo y será necesaria su autorización para incumplir esta norma.
    • Las nuevas apps tendrán que estar orientadas como mínimo a Android 14 (API 34). A partir de mayo este requisito también se aplica a las actualizaciones de apps.
    • Las apps existentes deberán estar orientadas a un nivel de API en el plazo de dos años desde el lanzamiento de la última versión principal de Android.
    • El código fuente debe ser diseñado para ser compatible con todas las dimensiones y densidades de pantalla de los dispositivos Android, tanto para Smartphone como para Tablet, en su caso.
  • R3.1.2. Es necesario que las aplicaciones y las actualizaciones que incluyan código nativo tienen que proporcionar versiones para 64 bits, además de para 32 bits.
  • R3.1.3. Las nuevas aplicaciones se deberán entregar con .aab (Android App Bundle), por ser un requisito obligatorio de Google. Las nuevas versiones de aplicaciones ya publicadas pueden continuar siendo .apk.

R3.2. Metainformación del proyecto Android Studio

  • En Android el nombre del paquete deberá ser: cat.bcn.nombre-aplicación
  • Como nomenclatura del campo Version Code incluido en el build.gradle o el AndroidManifest.xml se debe generar automáticamente tal y como se explica en el manual de integración continua: Manual Integración Continua para Proveedores
  • Si la aplicación gestiona imágenes en la memoria del dispositivo, se deberá indicar en el código de la app que éstas no se visualicen en la galería de imágenes.

R3.3. Estándares de desarrollo

  • R3.3.1. Se debe garantizar las guidelines de desarrollo y calidad especificadas para la Play Store vigentes en el momento de publicación. A destacar:
  • Además, la OSAM expone los siguientes requisitos:
    • Los .aab no no tienen un tamaño máximo (el apk generado tiene un tamaño máximo de 200 MB) y los .apk de 100 MB (límite de Google para subir una aplicación al Google Play).
    • Si se supera los 150 MB del .aab se puede usar Play Asset Delivery o Play Feature Delivery, y si se supera los 100 MB del .apk se pueden usar Expansion Files. Se debe consensuar previamente con la OSAM el uso de estos recursos.
  • R3.3.2. También se deben seguir los estándares de desarrollo expuestos por la OSAM:
    • Por motivos de seguridad, se tiene que evitar el uso de código que acepte todos los certificados, tanto en el caso de WebViews como en el caso de acceder a servidores remotos a través de una petición REST. Solo se podría utilizar durante la fase de desarrollo.
    • Si el código del proyecto tiene dependencias con otros proyectos, es necesario que estos otros estén incluidos dentro del proyecto principal como librerías. De esta manera evitamos posibles errores en acciones manuales de compilación y referencia. Siempre que sea posible, se recomienda la utilización de un gestor de dependencias en las aplicaciones como Gradle, que se deberá utilizar en su última versión estable.
    • Si se utiliza la librería de google play services (para mapas, notificaciones, etc.) se tiene que utilizar sólo la parte/módulo que vamos a necesitar para optimizar el tamaño del código de la aplicación. Por ejemplo, en vez de usar ‘compile com.google.android.gms:play-services:9.6.1’ se debería utilizar sólo ‘compile com.google.android.gms:play-services-maps:9.6.1’ en caso de necesitar los mapas.

R3.4. Seguridad de los datos

Según las políticas sobre datos de Google, destinadas a proporcionar más transparencia a los usuarios y a informarlos de cómo sus datos son recogidos, protegidos y usados, todas las nuevas apps y actualizaciones de apps existentes no se publicarán a menos que se complete un formulario de seguridad de los datos donde se define que datos personales se recogen y que uso se hace de éstos. Este formulario debe completarse una sola vez por cada app y se deberá contactar con la OSAM para hacerlo. Para cada tipo de dato que se seleccione se debe indicar como se usan los datos obtenidos por esta app.

Para consultar los diferentes tipos de datos que hay que declarar y otras consideraciones se puede consultar el siguiente enlace: https://support.google.com/googleplay/android-developer/answer/10787469?hl=es