Cumple con los requisitos de nivel de API objetivo de Google Play

Cuando subes un APK, este debe cumplir con los requisitos de Google Play sobre el nivel de API objetivo.

A partir del 31 de agosto de 2024, ocurrirá lo siguiente:

• Las apps nuevas y las actualizaciones deben orientarse a Android 14 (nivel de API 34) o versiones posteriores para que se envíen a Google Play, excepto las apps para Wear OS y Android TV, que deben orientarse a Android 13 (nivel de API 33) o versiones posteriores.
• Las apps existentes deben orientarse a Android 13 (nivel de API 33) o versiones posteriores a fin de permanecer disponibles para los usuarios nuevos en dispositivos con un SO Android superior al nivel de API objetivo de tu app. Las apps orientadas a Android 12 (nivel de API 31) o versiones anteriores (Android 10 [nivel de API 29) o versiones anteriores para Wear OS y Android 11 (nivel de API 30) o versiones anteriores para Android TV) solo estarán disponibles en dispositivos con SO Android igual o inferior al nivel de API objetivo de la app.

Si necesitas más tiempo para actualizar la app, podrás solicitar una extensión hasta el 1 de noviembre de 2024. Podrás acceder a los formularios de extensión de tu app en Play Console más adelante, este año.

Entre las excepciones a estos requisitos, se incluyen las siguientes:

• Apps que son privadas de forma permanente y que están restringidas a los usuarios de una organización específica y destinadas solo a la distribución interna
• Apps orientadas al SO Android Automotive o empaquetadas con APKs orientados al SO Android Automotive

Nota: Las apps desactualizadas no están disponibles para los usuarios nuevos de dispositivos que ejecutan versiones más recientes de Android. Para obtener más información, consulta la sección "Requisitos de disponibilidad de las apps" en el artículo Requisitos de nivel de API objetivo para apps de Google Play en la Ayuda de Play Console.

¿Por qué conviene segmentarse a los SDK más nuevos?

Cada versión nueva de Android incluye cambios que mejoran la seguridad y el rendimiento, y optimizan la experiencia del usuario de Android. Algunos de estos cambios solo se aplican a las apps que declaran su compatibilidad de forma explícita a través del atributo de manifiesto targetSdkVersion (el nivel de API al que está orientada la app).

Si configuras la app para que tenga como objetivo un nivel de API reciente, eso garantiza que los usuarios puedan beneficiarse de estas mejoras y que la app pueda seguir ejecutándose en versiones anteriores de Android. Orientar tu app a un nivel de API reciente también permite que esta aproveche las funciones más recientes de la plataforma para el deleite de tus usuarios. Además, a partir de Android 10 (nivel de API 29), los usuarios ven una advertencia cuando inician una app por primera vez, si esta se orienta a Android 5.1 (nivel de API 22) o versiones anteriores.

Este documento resalta los puntos importantes que debes tener en cuenta cuando actualices el nivel de API objetivo con el fin de cumplir con los requisitos de Google Play. Consulta las instrucciones de las siguientes secciones, según la versión a la que migres.

Nota: Si tu archivo de Gradle contiene entradas del manifiesto, puedes confirmar o cambiar el valor actual de targetSdkVersion en ese archivo, según se describe en la sección Cómo configurar tu compilación. Como alternativa, puedes usar el atributo android:targetSdkVersion en el archivo de manifiesto, como se describe en la documentación del elemento de manifiesto <uses-sdk>.

Migra desde Android 12 y versiones posteriores (nivel de API 31) a una versión más reciente.

Si deseas actualizar tu app para que se oriente a una versión más reciente de Android, sigue la lista de cambios de comportamiento relevantes:

• Cambios en el comportamiento de Android 13
• Cambios en el comportamiento de Android 14

Migra de Android 11 (nivel de API 30) a Android 12 (nivel de API 31)

Seguridad y permisos

• Bluetooth: Debes reemplazar las declaraciones de los permisos BLUETOOTH y BLUETOOTH_ADMIN por los permisos BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE o BLUETOOTH_CONNECT. Ya no necesitas realizar solicitudes de permisos de tiempo de ejecución LOCATION para las operaciones de Bluetooth.
• Ubicación: Los usuarios pueden solicitar a las apps que recuperen solo información de la ubicación aproximada. Debes solicitar el permiso ACCESS_COARSE_LOCATION cada vez que solicites ACCESS_FINE_LOCATION.
  • Filtros de intents: Si la app contiene actividades, servicios o receptores de emisión que usan filtros de intents, debes declarar explícitamente el atributo android:exported para esos componentes.
• Hibernación: Es posible que las apps se pongan en modo de hibernación si no se usan durante un período. En el modo de hibernación, se restablecen los permisos de tiempo de ejecución y la caché de tu app, y no puedes ejecutar trabajos ni alertas. Puedes verificar el estado de hibernación de tu app.
• Mutabilidad de intents pendientes: Debes especificar la mutabilidad de cada objeto PendingIntent que crea tu app.

Experiencia del usuario

• Notificaciones personalizadas: Las notificaciones con vistas de contenido personalizado ya no usarán el área de notificaciones completa. En su lugar, el sistema aplicará una plantilla estándar. Esta plantilla garantiza que las notificaciones personalizadas tengan la misma decoración que otras notificaciones en todos los estados. Este comportamiento es casi idéntico al comportamiento de Notification.DecoratedCustomViewStyle.
• Cambios en la verificación de Android App Links: Cuando uses la verificación de Android App Link, asegúrate de que los filtros de intents incluyan la categoría BROWSABLE y admitan el esquema HTTPS.

Rendimiento

• Restricciones para el inicio del servicio en primer plano: Para orientar a Android 12 o versiones posteriores, la app no puede iniciar servicios en primer plano mientras se ejecuta en segundo plano, excepto en algunos casos especiales. Si una app intenta iniciar un servicio en primer plano mientras se ejecuta en segundo plano, se produce una excepción (excepto en algunos casos especiales).

  Procura usar WorkManager para programar y comenzar trabajos acelerados mientras la app se ejecuta en segundo plano. Para completar acciones urgentes que solicita el usuario, inicia los servicios en primer plano dentro de una alarma exacta.

• Restricciones del trampolín de notificaciones: Cuando los usuarios presionan las notificaciones, algunas apps inician un componente de app que inicia la actividad que el usuario ve y con la que interactúa. Este componente de la app se conoce como trampolín de notificaciones.

  Las apps no deben iniciar actividades de servicios o receptores de emisión que se usen como trampolines de notificaciones. Después de que un usuario presiona una notificación o un botón de acción dentro de la notificación, tu app no puede llamar a startActivity() dentro de un servicio o receptor de emisión.

Consulta el conjunto completo de cambios que afectan a las apps orientadas a Android 12 (nivel de API 31).

Migra desde una versión anterior a Android 11 (nivel de API 30)

Selecciona la versión de Android desde la que harás la migración:

Realiza la migración a Android 5 (nivel de API 21)

Consulta la página sobre cambios de comportamiento de cada una de las versiones subsiguientes de tu app para garantizar que se hayan considerado los cambios que se implementaron en ellas:

• Android 5.0 (nivel de API 21)
• Android 4.4 (nivel de API 19)
• Android 4.1.x (nivel de API 16)

Para continuar, sigue las instrucciones que se describen en la próxima sección.

Realiza la migración a Android 6 (nivel de API 23)

Las siguientes consideraciones se aplican a las apps que se segmentan a Android 6.0 y versiones posteriores de la plataforma:

• Permisos de tiempo de ejecución

  • Los permisos peligrosos solo se otorgan durante el tiempo de ejecución. Los flujos de la IU deben proporcionar las condiciones para que se otorguen estos permisos.

  • En la medida de lo posible, asegúrate de que la app esté preparada para manejar el rechazo de las solicitudes de permisos. Por ejemplo, si el usuario rechaza otorgar acceso al GPS del dispositivo, la app debería tener otra manera de proceder.

Para ver una lista detallada de los cambios que se implementaron en Android 6.0 (nivel de API 23), consulta la página Cambios en el comportamiento de esa versión de la plataforma.

Para continuar, sigue las instrucciones que se describen en la próxima sección.

Realiza la migración a Android 7 (nivel de API 24)

Las siguientes consideraciones se aplican a las apps que se orientan a Android 7.0 y versiones posteriores de la plataforma:

• Descanso y App Standby

  Cuando diseñes la app, ten en cuenta los comportamientos que se describen en la sección Cómo optimizar tu app para Descanso y App Standby, que engloba los cambios progresivos que se implementaron en diferentes versiones de la plataforma.

  Cuando un dispositivo se encuentra en modo de Descanso y App Standby, el sistema se comporta de la siguiente manera:

  • Restringe el acceso a la red.
  • Pospone alarmas, sincronizaciones y tareas.
  • Restringe el GPS y el escaneo de redes Wi-Fi.
  • Restringe los mensajes de Firebase Cloud Messaging de prioridad normal.

• Cambios de permisos

  • El sistema restringe el acceso a los directorios privados de la app.
  • Si expones un URI de tipo file:// fuera de la app, se activa FileUriExposedException. Si necesitas compartir archivos fuera de la app, implementa FileProvider

• El sistema prohíbe los vínculos a bibliotecas que no sean de NDK.

Para ver una lista detallada de los cambios que se implementaron en Android 7.0 (nivel de API 24), consulta la página Cambios en el comportamiento de esa versión de la plataforma.

Para continuar, sigue las instrucciones que se describen en la próxima sección.

Realiza la migración a Android 8 (nivel de API 26)

Las siguientes consideraciones se aplican a las apps que se segmentan a Android 8.0 y versiones posteriores de la plataforma:

• Límites de ejecución en segundo plano
  • El sistema restringe los servicios a las apps que no se ejecutan en primer plano.
    • Ahora, cuando una app intenta invocar la acción startService() mientras startService() está prohibida, se genera una excepción.
    • Para iniciar servicios en primer plano, la app debe usar startForeground() y startForegroundService().
    • Revisa en detalle los cambios que se implementaron en la API de JobScheduler, según se documentó en la página sobre cambios de comportamiento de Android 8.0 (nivel de API 26).
    • Firebase Cloud Messaging requiere la versión 10.2.1 del SDK de Servicios de Google Play o una posterior.
    • Cuando se usa Firebase Cloud Messaging, el envío de mensajes queda sujeto a los límites de ejecución en segundo plano. Cuando se deben realizar tareas en segundo plano al recibir un mensaje, como la sincronización de datos en segundo plano, la app debe programar las tareas mediante Firebase Job Dispatcher o, en su lugar, JobIntentService. Para obtener más información, consulta la documentación de Firebase Cloud Messaging.
  • Transmisiones implícitas
    • Las transmisiones implícitas están restringidas. Para obtener información a fin de administrar eventos en segundo plano, consulta la documentación de la API de JobScheduler.
  • Límites de ubicación en segundo plano
    • Las apps que se ejecutan en segundo plano tienen acceso limitado a los datos de ubicación.
      • En los dispositivos que cuentan con Servicios de Google Play, puedes usar el proveedor de ubicaciones combinadas para recibir actualizaciones periódicas de la ubicación.
• Canales de notificaciones
  • Se recomienda definir propiedades de interrupción de notificaciones para cada canal.
  • Para que aparezcan las notificaciones, debes asignarlas a un canal.
  • Esta versión de la plataforma admite NotificationCompat.Builder.
• Privacidad
  • El alcance del ANDROID_ID se delimita para cada clave de firma de la app.

Para ver una lista detallada de los cambios que se implementaron en Android 8.0 (nivel de API 26), consulta la página Cambios en el comportamiento de esa versión de la plataforma.

Migra desde Android 8 (nivel de API 26) a Android 9 (nivel de API 28)

• Administración de energía
  • Los Intervalos de App Standby aportan nuevas restricciones en segundo plano en función de la participación de la app, como los trabajos diferidos, las alarmas y las cuotas de mensajes de alta prioridad
  • Las mejoras en el Ahorro de batería aumentan las limitaciones de las apps con App Standby
• Permiso de servicio en primer plano
  • Se debe solicitar el permiso normal FOREGROUND_SERVICE (no el permiso de tiempo de ejecución)
• Cambios en la privacidad
  • Acceso limitado a los sensores en segundo plano
  • Acceso restringido a los registros de llamadas, que ahora están en el grupo de permisos CALL_LOG
  • Acceso restringido a los números de teléfono, que requieren el permiso de READ_CALL_LOG
  • Acceso restringido a la información de Wi-Fi

Para ver una lista detallada de los cambios que se implementaron en Android 9.0 (nivel de API 28), consulta la sección Cambios en el comportamiento.

Migra desde Android 9 (nivel de API 28) a Android 10 (nivel de API 29)

• Notificaciones con un intent de pantalla completa
  • Se debe solicitar el permiso normal USE_FULL_SCREEN_INTENT (no el permiso de tiempo de ejecución)
• Compatibilidad con dispositivos plegables y con pantalla grande
  • Ahora, varias actividades pueden tener el estado "reanudada" al mismo tiempo, pero se centra el enfoque en una sola
    • Este cambio afecta el comportamiento de onResume() y onPause().
    • Nuevo concepto de ciclo de vida de "más reanudada", que se puede detectar mediante la suscripción a onTopResumedActivityChanged().
      • Solo se puede etiquetar una actividad como la "más reanudada"
  • Cuando resizeableActivity se establece en false, las apps también pueden especificar una minAspectRatio, que aplica automáticamente el formato letterbox a relaciones de aspecto más estrechas.
• Cambios en la privacidad
  • Almacenamiento específico
    • El acceso al almacenamiento externo se limita solo a un directorio específico de la app y a determinados tipos de contenido multimedia que esta haya creado.
  • Acceso restringido a la ubicación mientras la app está en segundo plano, lo que requiere el permiso ACCESS_BACKGROUND_LOCATION
  • Acceso restringido a identificadores que no se pueden restablecer, como el IMEI y el número de serie
  • Acceso restringido a la información de actividad física, como el recuento de pasos del usuario, lo cual requiere el permiso ACTIVITY_RECOGNITION
  • Acceso restringido a algunas APIs de telefonía, Bluetooth y Wi-Fi, lo que requiere el permiso ACCESS_FINE_LOCATION
  • Acceso restringido a la configuración de Wi-Fi
    • Las apps ya no pueden habilitar ni inhabilitar directamente la conexión Wi-Fi y deben hacerlo mediante paneles de configuración.
    • Restricciones sobre el inicio de una conexión a una red Wi-Fi, lo que requiere el uso de WifiNetworkSpecifier o WifiNetworkSuggestion

Migra de Android 10 (nivel de API 29) a Android 11 (nivel de API 30)

• Privacidad
  • Aplicación de almacenamiento específico: Las apps deben adoptar el modelo de almacenamiento específico, en el que los tipos de archivo específicos de la app, de contenido multimedia y de otros tipos se guardan y se accede a ellos por ubicaciones exclusivas.
  • Restablecimiento automático de permisos: Si los usuarios no interactúan con una app durante algunos meses, el sistema restablecerá automáticamente los permisos sensibles de la app. La mayoría de las apps no deberían verse afectadas por esto. Si tu app funciona principalmente en segundo plano sin interacciones del usuario, puedes considerar la opción de solicitar a los usuarios que inhabiliten el restablecimiento automático.
  • Acceso a la ubicación en segundo plano: Las apps deben solicitar los permisos de ubicación en primer y segundo plano por separado. La concesión de acceso a la ubicación en segundo plano solo se puede realizar en la configuración de la app, en lugar de en los diálogos del permiso de tiempo de ejecución.
  • Visibilidad del paquete: Cuando una app busca la lista de apps y servicios instalados en el dispositivo, se filtra la lista que se muestra.
    • Si usas los servicios de Texto a voz o Reconocimiento de voz, deberás agregar elementos de consulta correspondientes al archivo de manifiesto.
• Seguridad
  • Ya no se admiten los archivos comprimidos "resource.arsc".
  • Ahora se requiere el esquema de firma de APK v2. Por razones de retrocompatibilidad, los desarrolladores también deben seguir aplicando las firmas con el esquema de firma de APK v1.
  • Se aplican restricciones de interfaces que no pertenecen al SDK. No se recomienda usar interfaces que no pertenezcan al SDK para las apps que se orientan al nivel de API 30, ya que algunas de ellas ahora están bloqueadas. Consulta Interfaces que no pertenecen al SDK y que ahora están bloqueadas en Android 11 para obtener una lista completa de esas interfaces.

Para ver una lista detallada de los cambios que se implementaron en Android 11 (nivel de API 30), consulta la página Cambios en el comportamiento.

Para continuar, sigue las instrucciones que se describen en la sección anterior a fin de actualizar la versión al nivel de API 31.

Moderniza tus apps

Cuando actualices el nivel de API objetivo, considera adoptar funciones recientes de la plataforma que te permitan modernizar tus apps y mejorar la experiencia de tus usuarios.

• Para aprovechar al máximo la cámara, considera la opción de usar CameraX, que está en versión beta.
• Usa los componentes de Jetpack para seguir prácticas recomendadas, liberarte de escribir código estándar y simplificar tareas complejas para que puedas enfocarte en el código que realmente te interesa.
• Usa Kotlin para escribir mejores apps más rápido y con menos código.
• Asegúrate de cumplir con los requisitos y las prácticas recomendadas de privacidad.
• Agrega compatibilidad con temas oscuros a tus apps.
• Agrega compatibilidad con la navegación por gestos a las apps.
• Migra tu app de Google Cloud Messaging (GCM) a la versión más reciente de Firebase Cloud Messaging.
• Aprovecha la función avanzada de administración de ventanas.
  • Admite relaciones de aspecto más grandes (más de 16:9) y aprovecha los avances recientes en hardware. Asegúrate de que la app cambie de tamaño y ocupe el espacio disponible en la pantalla. Declara una relación de aspecto máxima solo como un último recurso. Para obtener más información sobre las relaciones de aspecto máximas, consulta Cómo declarar una compatibilidad de pantalla restringida.
  • Para ayudar a que tu app aumente la productividad y administres varias pantallas, agrega compatibilidad con la función Multiventana.
  • Si la experiencia del usuario mejora con la opción de minimizar la app, agrega compatibilidad con la función Pantalla en pantalla.
    • Optimiza tu app para dispositivos con corte de pantalla.
    • No supongas la altura de la barra de estado. En su lugar, usa WindowInsets y View.OnApplyWindowInsetsListener. Para obtener más información, mira el video droidcon NYC 2017.
    • No supongas que la app tiene toda la ventana. En cambio, confirma la ubicación con View.getLocationInWindow() y no con View.getLocationOnScreen(). * Cuando manejes MotionEvent, usa MotionEvent.getX() y MotionEvent.getY(), no MotionEvent.getRawX() ni MotionEvent.getRawY().

Consulta y actualiza tus bibliotecas y SDK

Asegúrate de que tus dependencias a SDK de terceros sean compatibles con la API 31. Algunos proveedores de SDK lo publican en el manifiesto y otros requerirán una investigación adicional. Si usas un SDK que no es compatible con la API 31, prioriza trabajar con el proveedor del SDK para resolver el problema.

Ten en cuenta que la targetSdkVersion de tu app o juego podría restringir el acceso a bibliotecas privadas de la plataforma de Android. Para obtener más información, consulta Cómo vincular apps NDK a bibliotecas de la plataforma.

También debes verificar las restricciones que existan en la versión de la biblioteca de compatibilidad de Android que estés usando. Como siempre, debes garantizar la compatibilidad entre la versión principal de la biblioteca de compatibilidad de Android y la compileSdkVersion de tu app.

Te recomendamos que elijas una targetSdkVersion menor o igual que la versión más reciente de la biblioteca de compatibilidad. También se recomienda que actualices la biblioteca de compatibilidad a una versión actualizada y compatible para aprovechar las funciones de compatibilidad y correcciones de errores más recientes.

Prueba tu app

Después de actualizar el nivel de API de tu app y las funciones correspondientes, deberías probar algunos de los principales casos de uso. Las siguientes sugerencias no son exhaustivas, pero están diseñadas para guiarte en el proceso de prueba. Se recomienda que pruebes lo siguiente:

• Que tu app se compile a la API 29 sin errores ni advertencias

• Que tu app cuente con una estrategia para casos en los que los usuarios rechacen solicitudes de permisos, y los solicite Para ello, sigue estos pasos:

  • Inhabilita cada uno de los permisos en la pantalla "Información de apps" de tu app.
  • Abre la app y asegúrate de que no tenga fallas.
    • Realiza pruebas de los casos de uso principales y asegúrate de que se vuelvan a solicitar los permisos.

• Que maneje la función de Descanso con los resultados esperados y sin errores.

  • Con el adb, activa la función de Descanso del dispositivo de prueba mientras tu app está en ejecución.
    • Prueba todos los casos prácticos que desencadenen mensajes de Firebase Cloud Messaging.
    • Prueba todos los casos prácticos que usen alarmas o tareas.
    • Elimina todas las dependencias a servicios en segundo plano.
  • Activa el modo App Standby de la app
    • Prueba todos los casos prácticos que desencadenen mensajes de Firebase Cloud Messaging.
    • Prueba todos los casos prácticos que usen alarmas.

• Que administre correctamente las fotos y los videos nuevos que se tomen

  • Verifica que la app controle las transmisiones restringidas ACTION_NEW_PICTURE y ACTION_NEW_VIDEO correctamente (es decir, que las mueva a las tareas de JobScheduler).
  • Asegúrate de que aún funcionen todos los casos de uso importantes que dependan de estos eventos.

• Que sea capaz de compartir archivos con otras apps: Prueba cualquier caso de uso en el que se compartan datos de archivos con cualquier otra app (incluso otra app del mismo desarrollador).

  • Comprueba que el contenido sea visible en la otra app y no desencadene fallas.

Más información

Acepta recibir correos electrónicos en Google Play Console para que te enviemos anuncios y actualizaciones importantes de Android y Google Play, incluido el boletín informativo mensual para socios.