Los servicios de Google Play interrumpen las actualizaciones de Jelly Bean (niveles de API 16, 17 y 18)


Publicado por Vikas Kansal, gerente de productos, servicios de Google Play

La plataforma Android Jelly Bean (JB) se lanzó por primera vez hace 9 años y, en julio de 2021, el recuento de dispositivos activos es inferior al 1%. Desde entonces, Android ha lanzado una gran cantidad de mejoras y funciones que no están todas respaldadas por Jelly Bean. Esto da como resultado un aumento en el tiempo dedicado por los desarrolladores y el control de calidad para nuevas funciones que requieren un manejo especial. Como resultado, retiraremos el soporte para JB en futuras versiones de los servicios de Google Play. Para los dispositivos que ejecutan JB, Google ya no actualizará la Servicios de juego APK más allá de la versión 21.30.99, programada para finales de agosto de 2021.

¿Qué significa esto como desarrollador de aplicaciones?

Los SDK de Google Play Services contienen interfaces para la funcionalidad proporcionada por Servicios APK de Google Play, que se ejecuta como servicios en segundo plano. La funcionalidad requerida por las versiones actuales del SDK ya está presente en los dispositivos JB con servicios de Google Play y seguirá funcionando sin modificaciones.

Cada SDK se puede lanzar de forma independiente y puede actualizar su propia minSdkVersion. No es necesario que las bibliotecas individuales cambien en función de esta desaprobación. Es posible que los componentes del SDK más nuevos sigan admitiendo los niveles de API del 16 al 18, pero muchos se actualizarán para requerir niveles de API más altos. Para las aplicaciones que admiten niveles de API 19 o superiores, no necesitará realizar ningún cambio de compilación. Para las aplicaciones que admiten los niveles de API 16 a 18, puede continuar compilando y publicando su aplicación en dispositivos que ejecutan JB, pero puede encontrar errores de compilación al actualizar a versiones más recientes del SDK. El error se verá así:

Error:Execution failed for task ':app:processDebugManifest'.
> Manifest merger failed : uses-sdk:minSdkVersion 16 cannot be smaller than version 19 declared in library [com.google.android.gms:play-services-FOO:19.X.YY]
        Suggestion: use tools:overrideLibrary="com.google.android.gms:play_services" to force usage

Desafortunadamente, el consejo dado no lo ayudará a entregar actualizaciones de aplicaciones a dispositivos que ejecutan JB o versiones anteriores. Para utilizar el último SDK, deberá utilizar una de las siguientes opciones:

1. Utilice el nivel de API 19 como nivel mínimo de API admitido.

Este es el curso de acción recomendado. Para detener la compatibilidad con los niveles de API que ya no recibirán actualizaciones del servicio de Google Play, simplemente aumente el valor de minSdkVersion en build.gradle de su aplicación a al menos 19. Si actualiza su aplicación de esta manera y la publica en Play Store, los usuarios de dispositivos con un nivel de soporte por debajo de ese nivel no podrá ver ni descargar la actualización. Sin embargo, aún podrán descargar y usar la versión publicada más recientemente de la aplicación destinada a su dispositivo.

Un porcentaje muy pequeño de todos los dispositivos Android utiliza niveles de API inferiores a 19. Creemos que muchos de estos dispositivos más antiguos no se pueden utilizar de forma activa. Si su aplicación aún tiene una cantidad significativa de usuarios en dispositivos más antiguos, puede usar la compatibilidad con varios APK en Google Play para proporcionar un APK que use los servicios de Google Play 21.30.99. Esto se describe a continuación.

2. Cree varios APK para admitir dispositivos con un nivel de API inferior a 19.

Junto con algunas configuraciones y administración de código, puede crear varios APK que admiten diferentes niveles mínimos de API, con diferentes versiones de los servicios de Google Play. Puedes hacer esto con construir variantes en Grado. Primero, defina los modelos de compilación para las versiones más antiguas y más nuevas de su aplicación. Por ejemplo, en su build.gradle, define dos versiones de producto diferentes, con dos dependencias de compilación diferentes para los componentes de Play Services que está utilizando.

productFlavors {
    legacy {
        minSdkVersion 16
        versionCode 101  // Min API level 16, v01
    }
    current {
        minSdkVersion 19
        versionCode 1901  // Min API level 19, v01
    }
}

dependencies {
    legacyCompile 'com.google.android.gms:play-services:16.0.0'
    currentCompile 'com.google.android.gms:play-services:17.0.0'
}

En la situación anterior, se están construyendo dos tipos de productos frente a dos versiones diferentes de play-services-FOO. Esto funcionará correctamente si solo se llaman las API disponibles en la biblioteca 16.0.0. Si necesita llamar a las últimas API disponibles con 17.0.0, deberá crear su biblioteca de compatibilidad para las últimas llamadas API para que solo se integren en la versión de la aplicación que puede usarlas:

  1. Declara una interfaz Java que expone la funcionalidad de nivel superior que desea realizar y que solo está disponible en las versiones actuales de los servicios de reproducción.
  2. Cree dos bibliotecas de Android que implementen esa interfaz. La implementación “actual” debería llamar a las últimas API según lo desee. La implementación “heredada” no debe estar operativa ni actuar como se desea con las versiones anteriores de los servicios de Play. La interfaz debe agregarse a ambas bibliotecas.
  3. Compile condicionalmente cada biblioteca en la aplicación usando las dependencias “legacyCompile” y “currentCompile” como se muestra arriba para play-services-FOO.
  4. En el código de la aplicación, llame a la biblioteca de compatibilidad siempre que se necesiten nuevas API de Play.

Una vez que haya creado un APK de lanzamiento para cada versión, publíquelos en Play Store y el dispositivo se actualizará con la versión más apropiada para ese dispositivo. Leer más sobre soporte para múltiples APK en Play Store.

Compruebe también

La actualización de CameraX hace que las cámaras duales simultáneas sean aún más fáciles

Publicado por Donovan McMurray – Ingeniero de relaciones con desarrolladores CámaraXLa biblioteca de cámaras Jetpack …

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *