Se usó la API de Cloud Translation para traducir esta página.

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:

Para que se envíen a Google Play, las apps nuevas y las actualizaciones deben segmentarse para Android 14 (nivel de API 34) o versiones posteriores, excepto las apps para Wear OS y Android TV, que deben segmentarse para 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 que se segmenten para 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 que ejecuten un SO Android igual o inferior al nivel de API objetivo de tu app.

Podrás solicitar una extensión hasta el 1 de noviembre de 2024 si necesitas más tiempo para actualizar la app. 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

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

Todas las versiones nuevas de Android incluyen cambios que implican mejoras significativas de seguridad y rendimiento, y optimizan la experiencia del usuario de Android. Algunos de esos cambios solo se aplican a las apps que declaran su compatibilidad de forma explícita a través del atributo del manifiesto targetSdkVersion (el nivel de API al que está orientada la app).

Si configuras la app para que se segmente a un nivel de API reciente, eso garantiza que los usuarios puedan beneficiarse de mejoras importantes, mientras permite que la app aún pueda ejecutarse 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 que los usuarios disfruten de ella. 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 en las siguientes secciones, según la versión a la que realices la migración.

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

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

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 es necesario enviar solicitudes de permisos de tiempo de ejecución LOCATION para las operaciones de Bluetooth.
Ubicación: Los usuarios pueden solicitar que las apps 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 usan el área de notificaciones completa. En su lugar, el sistema aplica 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 Links, 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 (salvo en algunos casos especiales).

Considera usar WorkManager para programar y comenzar a realizar trabajos acelerados mientras tu 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 notificaciones, algunas apps inician, como respuesta, un componente de app que da comienzo a la actividad que ve el usuario 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 ni 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:

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 sobre cambios de 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 con 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 sobre cambios de 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 de acciones 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 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 página sobre cambios de 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 de 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 con la suscripción a onTopResumedActivityChanged()
    - Solo se puede etiquetar una actividad como la "más reanudada"
- Cuando se establece resizeableActivity como false, las apps también pueden especificar una minAspectRatio que establece automáticamente un formato letterbox con relaciones de aspecto más angostas
Cambios en la privacidad
- Almacenamiento específico
  - El acceso al almacenamiento externo se limita únicamente a un directorio específico de la app y a determinados tipos de archivos multimedia que esta haya creado
- Acceso restringido a la ubicación mientras la app está en segundo plano, lo cual 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 cual 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 con paneles de configuración.
  - Restricciones sobre el inicio de una conexión a una red Wi-Fi, lo cual 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 acción de otorgar acceso a la ubicación en segundo plano solo se puede llevar a cabo 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 sacar el mayor provecho de la cámara, considera la opción de usar CameraX, que está en fase 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 el tema oscuro 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 las ventajas de los adelantos de hardware más recientes. Asegúrate de que la app cambie de tamaño y llene 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 mejorar la productividad de tu app y administrar 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, consulta el video de droidcon NYC 2017.
  - No supongas que la app tiene toda la ventana. En cambio, confirma su ubicación con View.getLocationInWindow(), no con View.getLocationOnScreen(). * Cuando controles 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 exigen investigación adicional. Si usas un SDK que no es compatible con la API 31, establece como prioridad trabajar con el proveedor del SDK para resolver el problema.

Además, 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 del NDK a bibliotecas de la plataforma.

También debes verificar las restricciones que puedan existir en la versión de la biblioteca de compatibilidad de Android que estés usando. Al igual que siempre, debes asegurarte de que la compileSdkVersion de tu app sea compatible con la versión más reciente de la biblioteca de compatibilidad de Android.

Se recomienda 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

Luego de actualizar el nivel de API de tu app y las funciones correspondientes, se recomienda que pruebes algunos de los casos prácticos más importantes. Las siguientes sugerencias no son exhaustivas, pero te pueden servir como guía 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 la app cuente con una estrategia para casos en los que los usuarios rechacen solicitudes de permisos, y los solicite de manera directa 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 más importantes 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 tu 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 administre correctamente las transmisiones restringidas ACTION_NEW_PICTURE y ACTION_NEW_VIDEO (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.