Tabla de contenido
2.2.1 Inspección de la instalación
2.2.2 Disponibilidad de API/detección de compatibilidad
Para un proyecto de Android, los tres atributos MinSdkVersion, CompileSdkVersion y TargetSdkVersion son esenciales a lo largo de todo el desarrollo de la aplicación, y sus funciones también son muy importantes. Solo descubriendo el significado interno y la relación lógica entre ellos se puede "corregir" " Establecer o modifique sus valores para asegurarse de que la aplicación se ejecuta normalmente en diferentes versiones del sistema Android.
La siguiente es la configuración del nuevo proyecto del autor (entorno de desarrollo: Android Studio Dolphin | 2021.3.1 Patch 1 MacOS), donde se debe seleccionar minSdk en la lista de versiones del SDK durante el proceso de creación de un nuevo proyecto, compileSdk y targetSdk son asignado por el sistema de forma predeterminada, automáticamente se mantiene consistente con la última versión del SDK.
android {
namespace 'com.example.myapplication'
compileSdk 32
defaultConfig {
applicationId "com.example.myapplication"
minSdk 26
targetSdk 32
versionCode 1
versionName "1.0"
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
}
}1. ¿Cuál es el nivel de API?
Los valores enteros establecidos por MinSdkVersion, CompileSdkVersion y TargetSdkVersion corresponden a un nivel de API de manera única, por lo que para comprenderlos, es mejor comprender primero qué es un nivel de API.
El nivel de API es un valor entero que identifica de forma única la revisión de la API del marco proporcionada por la versión de la plataforma Android. La plataforma Android proporciona un conjunto de API de marco que las aplicaciones pueden usar para interactuar con el sistema Android subyacente. La API del marco consta de las siguientes partes:
- Un conjunto de paquetes y clases principales.
- Un conjunto de elementos y atributos XML para declarar archivos de manifiesto
- Un conjunto de elementos y atributos XML para declarar y acceder a recursos
- conjunto de intenciones
- Un conjunto de permisos que una aplicación puede solicitar y la aplicación de permisos incluida en el sistema
Cada versión posterior de la plataforma Android puede incluir actualizaciones de las API del Marco de aplicaciones de Android que proporciona.
Las actualizaciones de Framework API se realizan para mantener las nuevas API compatibles con versiones anteriores de la API . En otras palabras, la mayoría de los cambios de API son adiciones de funciones e introducen funciones nuevas o de reemplazo. Cuando se actualizan partes de la API, el sistema reemplaza partes de la versión anterior de la API, pero no las elimina para que las aplicaciones existentes puedan seguir utilizándolas. En casos excepcionales, es posible que se modifiquen o eliminen partes de la API, pero, por lo general, dichos cambios solo son necesarios para garantizar la solidez de la API y la seguridad de la aplicación o el sistema. Todas las demás revisiones anteriores de la API continuarán sin modificaciones.
Las API de Framework proporcionadas por la plataforma Android se especifican mediante identificadores enteros llamados "Niveles de API". Cada versión de la plataforma Android admite exactamente un nivel de API, pero admite implícitamente todos los niveles de API anteriores (hasta el nivel de API 1). La versión inicial de la plataforma Android proporciona el nivel de API 1 y el nivel de API de las versiones posteriores aumenta de forma secuencial.
El valor de API LEVEL continúa aumentando, mostrando un proceso de "optimización continua" y manteniendo la "compatibilidad hacia adelante". MinSdkVersion, CompileSdkVersion y TargetSdkVersion pueden ayudarnos a equilibrar mejor la "actualización" y la "compatibilidad" en el proceso de desarrollo del proyecto.
Referencia: Diferentes niveles de API
Ejemplo, MySdkVersion
2.1 Resumen
Un número entero que define la versión mínima de API admitida por la aplicación o el nivel mínimo de API requerido para que la aplicación funcione. Si el nivel de la API del sistema es inferior al valor especificado en esta propiedad, el sistema Android impedirá que el usuario instale la aplicación.
Nota : si no se declara este atributo, el sistema asumirá un valor predeterminado de "1", lo que significa que la aplicación es compatible con todas las versiones de Android. Si la aplicación no es compatible con todas las versiones (por ejemplo, el programa utiliza una API introducida en el nivel 3 de API), pero no declara la correcta, minSdkVersioncuando la aplicación está instalada en un sistema con un nivel de API inferior a 3, la aplicación intentará acceder en tiempo de ejecución Se produce un bloqueo cuando una API no está disponible. Para dar un ejemplo específico: checkSelfPermission (método de verificación de permiso) solo se agrega en API 23, y el teléfono móvil con sistema Android 6.0 (API 23) funcionará normalmente. Si está en un teléfono móvil con sistema Android 5.0, pero es no disponible cuando se llama en minSdkVersion 设为22，程序可以正常安装到 tiempo de ejecución La API se bloqueará e informará un error: Método no encontrado.
2.2 Función:
2.2.1 Inspección de la instalación
Para Google Play y los mercados de aplicaciones nacionales, determinarán si la aplicación (paquete APK) cargada por el desarrollador es visible para los usuarios finales que han instalado diferentes versiones del sistema según el valor de minSdkVersion.
2.2.2 Disponibilidad de API/detección de compatibilidad
minSdkVersion también puede ayudarlo durante el desarrollo: si la API a la que llama (determinada por el valor de CompileSdkVersion ) no existe en el SDK al que apunta minSdkVersion, el IDE generará un error, por ejemplo:
Si en nuestro proyecto, compileSdkVersion es mayor o igual a 23 (Android 6.0 necesita solicitar permisos especiales de forma dinámica), minSdkVersion es igual a 21, si se llama en el código al método API que no existe en minSdkVersion: checkSelfPermission(" "), se producirá un error de código. Si el cursor permanece en este método, aparecerá el siguiente error:
Call requires API level 23 (current min is 21): android.content.ContextWrapper#checkSelfPermissionHaga clic en el signo de exclamación a la izquierda y se le solicitará la solución (como se muestra en la figura a continuación - 1), lo que puede ayudarlo a evitar el problema de llamar a API inexistentes cuando la aplicación se está ejecutando. Nota: aunque se informa un error, no afecta la compilación y el empaquetado de APK.
Solución :
- 1. Siguiente @RequiresApi(api = Build.VERSION_CODES.M)
- 2. Agregar @TargetApi(Build.VERSION_CODES.M)
- 3. Agregar @SuppressLint("NuevaApi")
- 4. Agregue la evaluación de la versión del SDK en tiempo de ejecución
Los métodos primero, segundo y tercero solo se pueden compilar y pasar, y causarán java.lang.NoSuchMethodError cuando se ejecute en un sistema inferior a API23. La forma correcta es agregar el juicio de versión del SDK en tiempo de ejecución y agregar otros métodos para realizar esta función cuando se considera que es una versión baja. El método para usar el tiempo de ejecución para verificar la versión del sistema es el siguiente:
private void checkPermission() {
//VERSION_CODES_M = 23
if(Build.VERSION.SDK_INT>=23){
checkSelfPermission("");
}else {
... do something ...
}
}Nota: las bibliotecas que usa en su proyecto, como la biblioteca de soporte o los servicios de Google Play , pueden tener su propia minSdkVersion. La minSdkVersion establecida por su aplicación debe ser mayor o igual que la minSdkVersion de estas bibliotecas. Por ejemplo, hay tres bibliotecas cuya minSdkVersion es 4, 7 y 9 respectivamente, entonces su minSdkVersion debe ser al menos 9 para usarlas.
2.3 Cómo elegir una versión
Cuando decida qué minSdkVersion usar, debe consultar las estadísticas de distribución de Android actuales , que muestran todos los dispositivos que han accedido a Google Play en los últimos 7 días, y son usuarios potenciales cuando publica su aplicación en Google Play. Por lo tanto, es una cuestión de " decisión comercial " dependiendo de si vale la pena los costos de desarrollo y prueba para admitir un 3 % adicional de dispositivos y garantizar la mejor experiencia posible, debe estar entre la "participación de mercado" potencial y los " costos de mantenimiento " . -offs. De todos modos, minSdkVersion cuanto menor sea, más tiempo se tardará en resolver errores antiguos, y puede ser necesario agregar métodos alternativos en la APP (las API que se han implementado en la versión alta SDK aún no se han implementado en la baja versión).
Ejemplo, CompileSdkVersion
3.1 Resumen
CompileSdkVersion especifica la versión de la API de Android utilizada por Gradle para compilar su aplicación, y su aplicación puede usar funciones de API de esta versión o anterior. En pocas palabras, si su aplicación necesita usar algunas funciones de API relativamente nuevas durante el desarrollo, entonces su valor de compileSdkVersion debe ser mayor o igual que el nivel de API correspondiente.
Debe enfatizarse que el valor de compileSdkVersion no se empaquetará en el APK (mientras que minSdkVersin y targetSdkVersion sí lo harán), solo funciona en el momento de la compilación, por lo que CompileSdkVersion no determinará el comportamiento del tiempo de ejecución de la aplicación. Cuando modifica compileSdkVersion, pueden aparecer nuevas advertencias de compilación y errores de compilación.
Nota : si usa la biblioteca de soporte , debe compilar con el SDK más reciente para usar la biblioteca de soporte más reciente. Por ejemplo, para usar la versión 23.1.1 de la biblioteca de soporte, compileSdkVersion debe ser al menos 23 (¡los números de la versión principal deben ser coherentes!). Por lo general, se lanza una nueva versión de la Biblioteca de soporte junto con la nueva versión del sistema, que brinda soporte de compatibilidad para las API recién agregadas y las nuevas características del sistema.
3.2 Función
Beneficios de usar nuevas comprobaciones de compilación en el código existente: cuanto mayor sea esta propiedad, más métodos obsoletos, lo que puede ayudarnos a manejar correctamente las API obsoletas y prepararnos para usar nuevas API, por lo que durante el desarrollo, se recomienda compilar siempre con la última SDK.
Pregunta : compileSdkVersion permite que nuestra aplicación llame a la API más reciente durante la compilación, pero si la aplicación no encuentra la API correspondiente cuando el sistema se ejecuta en una versión inferior, definitivamente se bloqueará, entonces, ¿cómo implementar el método API de una versión superior? de Android en un sistema de versión inferior ¿Qué pasa con la compatibilidad?
Referencia : MinSdkVersion - Sección 2.2.2 Verificación de compatibilidad/disponibilidad de la API. En realidad, esto está determinado por CompileSdkVersion y MinSdkVersion.
Puede establecer con seguridad el valor de CompileSdkVersion en el último valor de NIVEL API, siempre y cuando realice el procesamiento correcto cuando aparezca un mensaje de error en el IDE (como: Android studio - ventana de programas) (como se muestra en la Figura-2), puedes ser bien compatible Un sistema de versión baja también puede aplicar la API más reciente en lugar de una API obsoleta a un sistema de versión alta.
3.3 Cómo elegir una versión
Para nuevas aplicaciones, elija la última versión disponible. Para las aplicaciones existentes, actualícelas a la última versión cuando le resulte conveniente.
四、TargetSdkVersion
4.1 Resumen
TargetSdkVersion es literalmente la SdkVersion de destino. Si no se establece, el valor predeterminado es minSdkVersion. TargetSdkVersion es el medio principal para que el sistema Android logre la "compatibilidad con versiones posteriores" . Cuando configura targetSdkVersion, significa que ha probado completamente el funcionamiento de su aplicación en la versión de destino (con precisión, debe ser desde minSdkVersion hasta targetSdkVersion Todas las versiones del sistema ), a menos que se actualice targetSdkVersion, el comportamiento de la aplicación no cambiará. Esta frase no es fácil de entender, después de leer el análisis de su "función" más adelante, lo entenderás.
4.2 Función
TargetSdkVersion es el principal medio para que el sistema Android proporcione compatibilidad con versiones posteriores. ¿Qué significa? Si el usuario instaló la APLICACIÓN, pero el sistema Android del usuario continuará actualizándose, correspondiente a la misma API (método), la lógica de implementación interna ha cambiado y la nueva lógica puede afectar la APLICACIÓN que llamó a esta API antes. para ser compatible con este problema, introduzca targetSdkVersion . Cuando targetSdkVersion >= API LEVEL (una determinada versión del sistema), la nueva lógica tendrá efecto; de lo contrario, se seguirá utilizando la lógica anterior. Entonces, desde este punto de vista, si modifica el targetSdkVersion aumentando el valor, debe hacer suficientes pruebas antes de liberarlo, porque aunque la API llamada no ha cambiado, la lógica interna ha cambiado.
Por ejemplo :
El cliente de la aplicación llama a la interfaz API proporcionada por el servidor. Por lo general, el número de versión del cliente (equivalente a targetSdkVersion) se incluye en el parámetro de solicitud. Cuando cambia la lógica del método API en segundo plano (equivalente a una versión del sistema Android actualización), si el contenido y el formato de los datos han cambiado (el comportamiento ha cambiado), y nuestra interfaz API también debe ser compatible con la versión anterior de la aplicación del cliente. La práctica habitual es hacer juicios en el lado del servidor en función de la versión. número del cliente, y devolver diferentes datos a diferentes versiones de la aplicación.cliente.
Ahora el número de versión de la versión anterior de la APLICACIÓN se eleva al último número de versión (equivalente al último NIVEL API), luego los datos devueltos por la API no son los mismos, por lo que es necesario volver a publicar el nuevo cambio después de la prueba es correcta, y así sucesivamente.
Ejemplo 1:
Después de Android 4.4 (API 19), el comportamiento de las dos API set() y setRepeat() de AlarmManager ha cambiado.
- Antes de Android 4.4, estas dos API establecen la hora precisa y el sistema puede garantizar que active la alarma a la hora establecida por la API.
- En Android 4.4, debido a razones de ahorro de energía, se realiza la activación de alineación de AlarmManager. La hora de activación establecida por estas dos API es tratada como una hora inexacta por el sistema. El sistema solo puede garantizar que se activará en un momento determinado después del punto de tiempo. configura.
Parte del código fuente de AlarmManger en Android 4.4:
private final boolean mAlwaysExact;
AlarmManager(IAlarmManager service, Context ctx) {
mService = service;
final int sdkVersion = ctx.getApplicationInfo().targetSdkVersion;
mAlwaysExact = (sdkVersion < Build.VERSION_CODES.KITKAT);
}set() Cuando el APK llama al AlarmManager del sistema setRepeat() , el sistema primero verificará la información de targetSdkVersion del APK llamado. Si es menor a 19, seguirá el comportamiento anterior, es decir, establecerá la hora de activación con precisión, de lo contrario ejecutar el nuevo comportamiento.
Ejemplo 2:
Para una aplicación que se ejecuta en el sistema Andorid 6.0 (API = 23), las llamadas a algunas API especiales deben solicitar permisos de forma dinámica durante la operación. Si el valor de targetSdkVersion de su aplicación es menor o igual a 22, incluso si se actualiza a 6.0 o superior, su aplicación aún puede ejecutarse normalmente sin solicitar permiso. Por lo tanto, Google Play y los mercados de aplicaciones nacionales generalmente requieren que el valor targetSdkVersion de la aplicación enviada sea mayor que 22. Para pasar la revisión normalmente, se debe modificar targetSdkVersion, pero tenga cuidado: después de modificar targetSdkVersion, debe probarse, porque cambiar este valor activará nuevas funciones del sistema, como aplicaciones de permiso de tiempo de ejecución, etc.
4.3 Cómo elegir una versión
Para nuevas aplicaciones, elija la última versión disponible. Para las aplicaciones existentes, actualícelas a la última versión cuando le resulte conveniente.
V. Resumen
De hecho, la razón por la que la comprensión de estos tres atributos es algo difícil es que no los entendemos desde la perspectiva del diseño de la API del sistema Android. Si desea lidiar con la compatibilidad de la versión del sistema, debe considerar los siguientes problemas:
- ¿Qué versión del sistema es la adaptación mínima de su aplicación? -minSdkVersion _
- API de versión alta (diferentes métodos: la versión alta tiene, la versión baja no), ¿cómo se ejecuta normalmente en el sistema de versión baja? - minSdkVersion y compileSdkVersion
- Después de actualizar la versión del sistema (el mismo método, la lógica cambia), ¿cómo garantizar que la aplicación publicada siga siendo coherente con el comportamiento previamente verificado? - targetSdkVersion
Cuando tome la iniciativa de pensar en estos temas, lo más probable es que diseñe tres atributos similares para satisfacer nuestras necesidades, por lo que será más fácil de entender.
Volviendo al principio, cuando creamos un nuevo proyecto, los valores predeterminados de compileSdkVersion y targetSdkVersion son el último nivel de API recomendado por Google, pero nosotros elegimos minSdkVersion Análisis exhaustivo, generalmente cumplen la siguiente relación:
minSdkVersion (la más baja posible) <= targetSdkVersion <= compileSdkVersion (SDK más reciente)
Imagine que creamos un nuevo proyecto de Android ahora. Tanto targetSdkVersion como compileSdkVersion usan el último NIVEL DE API SDK, como 32, pero después de un tiempo, la nueva API oficial se actualiza a 35. La práctica habitual es después de la evaluación (ver ¿Cuáles son los aspectos más destacados del nuevo NIVEL API y qué impacto tendrá en los proyectos existentes), y luego, en un momento determinado del ciclo de desarrollo del proyecto, modifique los valores de compileSdkVersion y targetSdkVersion para que sean tan grandes como el último NIVEL API, después de un riguroso pruebas y para garantizar que APP La nueva versión de la APP se lanzará oficialmente solo después de que se hayan realizado las adaptaciones correspondientes a los cambios lógicos de la API.
Es decir: use un minSdkVersion más bajo para cubrir la audiencia más grande y use el SDK más reciente para configurar targetSdkVersion y compileVersion para obtener la mejor apariencia y comportamiento.
Referencia del documento oficial:
1. https://developer.android.com/ndk/guides/sdk-versions
2. https://developer.android.com/guide/topics/manifest/uses-sdk-element