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 al que se orientará la app.

A partir del 31 de agosto de 2023, se aplicará lo siguiente:

• Las apps nuevas se deben orientar a Android 13 (nivel de API 33) o versiones posteriores, excepto las que son para Wear OS, que deben orientarse a una versión entre Android 11 (nivel de API 30) y Android 13 (nivel de API 33), inclusive.

• Las actualizaciones de apps deben orientarse a Android 13 o versiones posteriores y ajustarse a los cambios de comportamiento en Android 13, excepto las que son para Wear OS, que deben orientarse a Android 11.

Las 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 no necesitan cumplir con los requisitos de nivel de API objetivo.

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 la app" en el artículo Requisitos de nivel de API objetivo para las 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 esos 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 objetivo).

Si configuras la app para que se oriente a un nivel de API reciente, eso garantiza que los usuarios puedan beneficiarse de estas mejoras, mientras que la app puede 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 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 una versión anterior.

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.

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 Cómo configurar tu compilación. Como alternativa, puedes usar el atributo android:targetSdkVersion en el archivo de manifiesto, según se describe en la documentación del elemento <uses-sdk> del manifiesto.

Migra desde Android 12 (nivel de API 31) a Android 13 (nivel de API 33)

Si deseas actualizar tu app para que se oriente a Android 13, sigue la lista de cambios de comportamiento.

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 con 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 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 este modo, 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: Con el objetivo de orientarla 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 e iniciar 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 notificaciones, algunas apps responden con el inicio de 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, startService() arroja una excepción cuando una app intenta invocarla mientras startService() está prohibido.
    • 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 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 de Android 8 (API 26) a Android 9 (API 28)

• Administración de energía
  • Los buckets 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 de 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 con 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 un minAspectRatio que aplica automáticamente el formato letterbox en 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 tipos específicos 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 con 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 interactuaron 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. Solo se puede otorgar acceso a la ubicación en segundo plano 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 servicios y apps instalados en el dispositivo, se filtra la lista que se muestra.
    • Si usas los servicios de texto a voz o de reconocimiento de voz, deberás agregar elementos de consulta para los servicios al archivo de manifiesto.
• Seguridad
  • Ya no se admiten los archivos “resource.arsc” comprimidos
  • 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 estas interfaces 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 a la cámara, considera la opción de usar CameraX, que está disponible 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 el tema oscuro a las 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) para aprovechar los avances recientes de hardware. Asegúrate de que tu 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 ayudar a que tu app aumente la productividad y administrar varias pantallas, agrega compatibilidad con el modo 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. Si quieres obtener más información, mira el video sobre droidcon NYC 2017.
    • No supongas que la app tiene toda la ventana. En cambio, confirma su ubicación mediante View.getLocationInWindow(), no 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 el nivel de 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 solucionar el problema con el proveedor del SDK.

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 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.

Se recomienda que elijas una targetSdkVersion menor o igual que la versión principal 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 y las funciones de tu app según corresponda, debes probar algunos de los casos de uso principales. Las siguientes sugerencias no son exhaustivas, pero apuntan a guiar tu 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 tenga una estrategia para casos en los que el usuario rechace las solicitudes de permisos y le solicite los permisos 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 necesarios.

• 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 tu app controle las transmisiones restringidas ACTION_NEW_PICTURE y ACTION_NEW_VIDEO de forma correcta (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 que comparta datos de archivos con cualquier otra app (incluso otra del mismo desarrollador).

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

Más información

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