SDK Platform: qué es, versiones y Android SDK Manager

Qué es SDK Platform

SDK Platform es un componente fundamental de Android SDK que representa un conjunto completo de bibliotecas y herramientas para desarrollar aplicaciones para una versión específica de Android. Cada plataforma se identifica por su API Level, un número entero que aumenta con las nuevas versiones del SO. Por ejemplo, Android 13 corresponde al API Level 33, Android 14 al API Level 34, Android 15 al API Level 35.

A diferencia de Android Studio (IDE), SDK Platform no contiene editor de código ni depurador. Es una capa del sistema que se conecta al compilador y al sistema de compilación. Cuando un desarrollador escribe import android.app.Activity, el compilador toma esta clase de android.jar de una SDK Platform específica. Sin una plataforma instalada con el API Level necesario, el código no se compilará.

Google publica una nueva SDK Platform para cada versión estable de Android. La historia incluye más de 35 API Levels — desde Android 1.0 (API 1) hasta Android 15 (API 35). Cada plataforma es retrocompatible: el código escrito para API Level 21 funcionará en API Level 35, pero no al revés.

Por qué se necesita una SDK Platform separada para cada versión

Android evoluciona rápidamente: cada versión añade nuevas API, cambia el comportamiento de las existentes e introduce restricciones. Por ejemplo, Android 10 (API 29) introdujo Scoped Storage, Android 12 (API 31) — SplashScreen API, Android 14 (API 34) — banderas obligatorias de BroadcastReceiver. El desarrollador debe compilar la aplicación contra la plataforma actual para utilizar estas capacidades.

Al mismo tiempo, la aplicación puede ejecutarse en versiones antiguas del SO. Para ello, en Gradle se especifica minSdk — el API Level mínimo en el que se ejecuta la aplicación. El código utiliza comprobaciones de versión y llamadas condicionales a la API. Este enfoque garantiza la compatibilidad sin perder nuevas funciones.

Composición de SDK Platform: componentes principales

SDK Platform no es un único archivo, sino un conjunto de componentes que juntos garantizan la compilación, construcción y prueba de la aplicación. El elemento principal es android.jar — un archivo con las clases de Android API incluidas en esta versión. Este archivo se conecta al compilador de Kotlin o Java y determina qué clases, métodos y anotaciones están disponibles para el desarrollador.

Imágenes del sistema y emulador

Cada SDK Platform incluye una System Image — una imagen del sistema operativo para el emulador Android Virtual Device. Sin la imagen correspondiente, el emulador no puede iniciar un dispositivo virtual con el API Level requerido. Las System Images son de diferentes tipos: Google APIs (con servicios de Google), Google Play (con Play Store) y AOSP (Android puro sin servicios de Google).

Herramientas de compilación y depuración

SDK Platform incluye una versión de Build-Tools y Platform-Tools optimizada para este API Level. Build-Tools contienen aapt2 (Android Asset Packaging Tool), dx/d8 (compilador Dalvik/ART) y ApkSigner. Platform-Tools proporcionan ADB (Android Debug Bridge), fastboot y SQLite. Estas herramientas se actualizan independientemente de SDK Platform a través de SDK Manager.

Recursos de la plataforma

Cada plataforma incluye recursos estándar de Android: temas del sistema, estilos, animaciones, colores y dimensiones. Estos recursos se utilizan durante la compilación: si un desarrollador hace referencia a @android:style/Theme.Material.Light, el sistema de compilación toma la definición de los recursos de SDK Platform. Esto garantiza una apariencia uniforme de los componentes del sistema en todos los dispositivos.

API Level y versiones de SDK Platform

API Level es un identificador entero de la versión de Android SDK. Cada lanzamiento de Android corresponde a un API Level que aumenta monótonamente. El desarrollador especifica el API Level en tres parámetros clave de build.gradle: compileSdk, minSdk y targetSdk. La elección de estos parámetros determina qué API están disponibles y cómo el sistema maneja la aplicación.

Google recomienda mantener minSdk en un nivel no inferior al umbral de distribución actual — según Android Studio Distribution Dashboard (2026), alrededor del 95% de los dispositivos ejecutan Android 8.0 (API 26) y superior. compileSdk debe ser la última versión estable — esto proporciona acceso a nuevas API y permite que las comprobaciones lint detecten métodos obsoletos.

Evolución del API Level: cambios clave

Con cada nuevo API Level, Google introduce cambios significativos. Android 6.0 (API 23) añadió permisos en tiempo de ejecución — la aplicación solicita permisos durante la ejecución, no en la instalación. Android 8.0 (API 26) introdujo el autocompletado de formularios y los canales de notificación. Android 12 (API 31) cambió radicalmente el enfoque de los intents — apareció SplashScreen API y la exportación de componentes mediante el atributo exported. Android 14 (API 34) hizo obligatorio especificar banderas para BroadcastReceiver e introdujo restricciones estrictas en los servicios en primer plano.

Comprender la historia de los API Levels ayuda al desarrollador a elegir la estrategia de compatibilidad correcta. Si la aplicación usa compileSdk 35 pero minSdk 26, el código puede llamar a métodos de API 35 solo después de verificar la versión mediante Build.VERSION.SDK_INT. Este enfoque se denomina desarrollo con bloqueo de versión y es un estándar de la industria.

SDK Manager: instalación y configuración

SDK Manager es una herramienta para gestionar los componentes de Android SDK: instalar nuevas SDK Platform, actualizar las existentes y eliminar las obsoletas. SDK Manager está disponible como interfaz gráfica en Android Studio y también como herramienta de línea de comandos a través de sdkmanager. La línea de comandos de SDK Manager es conveniente para usar en pipelines CI/CD donde no hay interfaz gráfica.

SDK Manager instala las plataformas en el directorio de Android SDK, que por defecto se encuentra en $HOME/Android/Sdk en Linux y macOS o %LOCALAPPDATA%\Android\Sdk en Windows. Dentro del directorio platforms hay carpetas con nombres como android-{API Level}, cada una contiene la SDK Platform completa.

Instalación de SDK Platform mediante sdkmanager

El comando sdkmanager acepta un identificador de paquete en el formato "platforms;android-{API}". Por ejemplo, para instalar SDK Platform 35 el comando es:

# Instalar SDK Platform para API Level 35
sdkmanager "platforms;android-35"

# Instalar varias plataformas con un solo comando
sdkmanager "platforms;android-34" "platforms;android-33" "platforms;android-31"

# Lista de plataformas instaladas
sdkmanager --list_installed | grep platforms

# Eliminar plataforma obsoleta
sdkmanager --uninstall "platforms;android-28"

Instalación automática mediante Gradle

Los proyectos modernos de Android usan Gradle Plugin, que puede instalar automáticamente SDK Platform en la primera compilación. Para ello, debe especificar compileSdk en build.gradle y añadir el directorio SDK en la configuración local. Android Studio también ofrece instalar la plataforma faltante al abrir un proyecto — solo hay que hacer clic en el botón "Install SDK Platform" en la ventana de sincronización de Gradle.

Es importante actualizar regularmente SDK Platform a través de SDK Manager — junto con la plataforma se actualizan Build-Tools y Platform-Tools, lo que afecta el rendimiento de la compilación y la estabilidad de la depuración. Google recomienda revisar las actualizaciones del SDK cada 2–3 semanas, especialmente antes de publicar una nueva versión de la aplicación en Google Play.

Configuración de una imagen del sistema para el emulador

Para ejecutar el emulador con un API Level específico, debe instalar una System Image de la misma versión. SDK Manager permite descargar imágenes de diferentes arquitecturas (x86_64, arm64-v8a) y tipos (Google APIs, Google Play, AOSP). Después de descargar la imagen, AVD Manager crea un dispositivo virtual basado en ella.

# Instalar System Image con Google APIs para API 35
sdkmanager "system-images;android-35;google_apis;x86_64"

# Crear AVD mediante línea de comandos
avdmanager create avd -n pixel8 -k "system-images;android-35;google_apis;x86_64"

# Lista de AVD creados
avdmanager list avd

compileSdk, targetSdk y minSdk en Gradle

Tres parámetros en build.gradle definen cómo funciona la aplicación con SDK Platform. compileSdk es el API Level utilizado para la compilación. Este parámetro especifica qué clases de Android API están disponibles en el código. compileSdk debe ser el más reciente de los tres y no afecta el comportamiento del runtime — la aplicación se compila pero solo usa las API disponibles en el dispositivo.

minSdk es el API Level mínimo en el que se puede instalar la aplicación. Google Play no permitirá instalar la aplicación en un dispositivo con una versión inferior a minSdk. Este parámetro define el umbral de compatibilidad y afecta la cobertura de audiencia. Cuanto menor sea minSdk, más dispositivos serán compatibles, pero menos API nuevas se pueden usar sin comprobaciones.

targetSdk es el API Level con el que se probó la aplicación. El sistema Android usa targetSdk para aplicar cambios de comportamiento: si la aplicación no se actualiza a un nuevo API Level, el sistema activa el modo de compatibilidad para versiones antiguas. Google Play requiere que targetSdk no sea inferior a un cierto nivel — en 2026 es API 34 (Android 14).

Ejemplo de configuración de Gradle

android {
    compileSdk 35

    defaultConfig {
        applicationId "com.example.app"
        minSdk 26
        targetSdk 35
        versionCode 1
        versionName "1.0"
    }

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_17
        targetCompatibility JavaVersion.VERSION_17
    }
}

// La versión de Android SDK debe estar instalada a través de SDK Manager
// sdkmanager "platforms;android-35"

Cómo elegir compileSdk, minSdk y targetSdk

La estrategia de selección depende de los objetivos del proyecto. Para una aplicación nueva: compileSdk — la última estable (35 a principios de 2026), minSdk — API 26 (Android 8.0, cubre el 95% de dispositivos), targetSdk — la última estable. Para actualizar una aplicación existente: aumente compileSdk inmediatamente, targetSdk — después de probar todos los cambios de comportamiento, minSdk — solo cuando sea necesario dejar de soportar dispositivos obsoletos.

Google exige que targetSdk se actualice dentro del año posterior al lanzamiento de una nueva versión de Android. Las aplicaciones que no cumplan este requisito no pueden publicar actualizaciones en Google Play. Para realizar un seguimiento de los plazos, utilice el calendario oficial de actualizaciones de Android OS.

Ejemplos de trabajo con SDK Platform en código

Al desarrollar para diferentes versiones de Android, es necesario considerar la disponibilidad de la API. Si la aplicación usa compileSdk 35 pero se ejecuta en un dispositivo con API 31, llamar a métodos añadidos en API 34 provocará NoSuchMethodError o AbstractMethodError. Para llamar de forma segura a las nuevas API, se utilizan comprobaciones de versión mediante Build.VERSION.SDK_INT.

Comprobación del API Level en runtime

class FeatureChecker {
    fun registerNotificationChannel(context: Context) {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            // Los canales de notificación están disponibles desde API 26
            val channel = NotificationChannel(
                "updates",
                "Actualizaciones",
                NotificationManager.IMPORTANCE_DEFAULT
            )
            val manager = context.getSystemService(NotificationManager::class.java)
            manager.createNotificationChannel(channel)
        }
    }
}

Uso de nuevas API con @RequiresApi

Para métodos que solo se llaman en versiones específicas, use la anotación @RequiresApi. Esto indica a las comprobaciones lint que el método es seguro y desactiva las advertencias. Combinada con la comprobación de SDK_INT, la anotación hace que el código sea más limpio y comprensible para los revisores.

@RequiresApi(Build.VERSION_CODES.UPSIDE_DOWN_CAKE)
fun scheduleExactAlarm(manager: AlarmManager, time: Long) {
    // API 34: scheduleExact con bandera SCHEDULE_EXACT_ALARM
    if (manager.canScheduleExactAlarms()) {
        manager.setExact(AlarmManager.RTC_WAKEUP, time, pendingIntent)
    } else {
        // Solicitar permiso SCHEDULE_EXACT_ALARM
        val intent = Intent(Settings.ACTION_REQUEST_SCHEDULE_EXACT_ALARM)
        context.startActivity(intent)
    }
}

fun safeScheduleAlarm(context: Context, triggerTime: Long) {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE) {
        scheduleExactAlarm(getAlarmManager(context), triggerTime)
    } else {
        // Método antiguo setExact sin verificación de permisos
        getAlarmManager(context).setExact(AlarmManager.RTC_WAKEUP, triggerTime, pendingIntent)
    }
}

Determinación de la SDK Platform instalada

A veces es necesario saber qué versión de SDK Platform está instalada en el dispositivo del desarrollador o en CI. Esto se puede hacer a través de ADB o mediante programación en el código de la aplicación. Conocer el API Level del dispositivo ayuda al probar comportamientos específicos de versión.

fun logDeviceInfo() {
    with (Build.VERSION) {
        Log.d("SDK_Demo", "SDK_INT: $SDK_INT")
        Log.d("SDK_Demo", "RELEASE: $RELEASE")
        Log.d("SDK_Demo", "CODENAME: $CODENAME")
        Log.d("SDK_Demo", "PREVIEW_SDK_INT: $PREVIEW_SDK_INT")
    }
    // Salida: SDK_INT: 35, RELEASE: 15, CODENAME: REL
}