Políticas y obligaciones: targetSdk, rechazos y la cuenta de desarrollador

Publicar una app no es un acto puntual sino la firma de una obligación recurrente. Hay un calendario anual que te obliga a subir el nivel de API objetivo aunque tu app funcione perfectamente; hay un catálogo de políticas que crece cada año y se aplica retroactivamente a lo ya publicado; hay una verificación de identidad que puede dejar tu cuenta sin visibilidad si no la completas a tiempo; y hay una regla de mantenimiento que retira apps que llevan años sin actualizarse. Ninguna de esas cosas está en tu código. Todas pueden dejarte fuera de la tienda. Y a diferencia de un error de programación, que rompe algo concreto y avisa, un incumplimiento de política se manifiesta como un correo, una fecha límite y una app que deja de ser instalable.

El calendario de targetSdk y sus dos umbrales

El nivel de API objetivo declara contra qué comportamiento del sistema se escribió la app, y el sistema aplica compatibilidad retroactiva a quien declara un nivel antiguo. Como esa compatibilidad tiene coste en seguridad y en privacidad, la tienda impone un calendario: cada año, alrededor del final del verano, sube el nivel mínimo exigido, que suele situarse un escalón por debajo de la versión más reciente publicada.

Hay dos umbrales y confundirlos es un error común. El primero afecta a lo que puedes subir: a partir de la fecha, cualquier versión nueva debe declarar al menos el nivel exigido, y una subida con nivel menor se rechaza sin discusión. El segundo afecta a lo que ya está publicado: las apps existentes que no alcanzan un nivel más antiguo dejan de ser visibles e instalables para usuarios con sistemas recientes, aunque quienes ya la tienen puedan seguir usándola.

android {
    compileSdk = 36          // contra que APIs compilas: siempre lo mas reciente

    defaultConfig {
        minSdk = 26          // el suelo de dispositivos que soportas
        targetSdk = 36       // el comportamiento del sistema que aceptas
    }
}

Merece la pena separar bien los tres números del bloque anterior porque el calendario solo habla de uno. El compileSdk determina contra qué APIs compilas y conviene tenerlo siempre en lo más reciente, porque subirlo no cambia el comportamiento en ejecución: solo te deja ver las novedades y los avisos de obsolescencia. El minSdk fija el suelo de dispositivos compatibles y es una decisión de producto con impacto en alcance. El targetSdk es el único que declara qué reglas del sistema aceptas, y por eso es el que la tienda regula.

Subir el nivel objetivo nunca es cambiar un número. Cada salto activa un paquete de cambios de comportamiento que solo se aplican a quien declara ese nivel: restricciones nuevas de acceso a almacenamiento, tipos obligatorios en servicios en primer plano, permisos que pasan a requerir justificación, límites de inicio desde segundo plano, cambios en la exportación de componentes. Ese es el motivo real por el que el calendario duele: no obliga a actualizar un valor, obliga a auditar toda la app contra un conjunto de reglas nuevas cada año.

Las políticas que más rechazos causan

El catálogo de políticas es largo, pero los rechazos se concentran en unas pocas familias. Conocerlas por adelantado evita la mayor parte de los ciclos de revisión perdidos.

Antes del detalle conviene fijar la escala de sanciones, porque no todas las infracciones se pagan igual y confundirlas lleva a asignar mal el esfuerzo.

Rechazo de version        la version no sale, la publicada sigue viva
Aviso con plazo           debes corregir antes de una fecha o la app se retira
Retirada de la app        deja de ser instalable, quien la tiene la conserva
Suspension de la app      retirada mas sancion sobre el historial de la cuenta
Cierre de cuenta          todas tus apps caen y la identidad queda vetada

La familia de los permisos delicados merece detalle porque su lógica es sistemática. La tienda aplica el mismo razonamiento a todos: el permiso solo se concede si es necesario para la funcionalidad principal que el usuario ve y elige, no para una funcionalidad secundaria ni para analítica. Pedir ubicación en segundo plano porque “quizá haga falta luego” es rechazo garantizado. Usar el servicio de accesibilidad para automatizar algo que no es accesibilidad es rechazo y a menudo suspensión. Consultar la lista completa de apps instaladas requiere pertenecer a una de las pocas categorías autorizadas.

<!-- Declaraciones que disparan escrutinio adicional en revision -->
<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
<uses-permission android:name="android.permission.QUERY_ALL_PACKAGES" />
<uses-permission android:name="android.permission.MANAGE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" />

<!-- Los servicios en primer plano exigen tipo declarado y justificacion -->
<service
    android:name=".SeguimientoService"
    android:foregroundServiceType="location"
    android:exported="false" />

Un patrón de diseño evita la mayoría de estos rechazos: preferir siempre la alternativa que no requiere permiso. El selector de documentos del sistema devuelve un archivo elegido por el usuario sin que pidas acceso al almacenamiento; el selector de fotos entrega imágenes sin permiso de galería; una intención hacia la cámara del sistema devuelve una foto sin permiso de cámara. Cada permiso que eliminas con este enfoque es un motivo de rechazo menos, una pantalla de solicitud menos que el usuario puede denegar y una rama de error menos que mantener.

Hay dos obligaciones transversales que se han vuelto causa habitual de bloqueo y que no son permisos. La primera es ofrecer eliminación de cuenta y datos desde dentro de la app y desde una URL pública, para cualquier app que permita crear cuenta. La segunda es que las apps que se dirigen a menores, o que declaran público mixto, deben cumplir un régimen adicional sobre publicidad, identificadores y consentimiento, y ese régimen se verifica.

flowchart TD
SUB[Subes una version] --> AUTO[Analisis automatico del paquete]
AUTO --> PERM[Permisos frente a funcionalidad declarada]
AUTO --> DATOS[Coherencia con el formulario de datos]
AUTO --> SDKS[Librerias con vulnerabilidades conocidas]
PERM --> HUM[Revision humana si algo se marca]
DATOS --> HUM
SDKS --> HUM
HUM --> OK[Aprobada]
HUM --> RECH[Rechazo con motivo y plazo]
RECH --> APEL[Correccion o apelacion]

La cuenta de desarrollador como sujeto verificado

El desplazamiento normativo de los últimos años ha trasladado el foco desde la app hacia quien la publica. Una cuenta de desarrollador ya no es un correo con una tarjeta: es una identidad verificada con obligaciones propias.

Toda cuenta debe completar una verificación que incluye datos de contacto comprobables y, en el caso de organizaciones, un identificador de empresa reconocido internacionalmente. Esos datos se muestran públicamente en la ficha, porque la normativa europea exige que el usuario sepa con quién contrata. No completar la verificación en plazo lleva a la pérdida de visibilidad y eventualmente al cierre.

Las cuentas personales creadas recientemente tienen además una obligación de prueba cerrada previa: deben ejecutar una prueba con un número mínimo de participantes reales durante un periodo continuado antes de poder solicitar acceso a producción. No se satisface con cuentas propias ni con participación simbólica, y no hay atajo, así que hay que incluir esas semanas en la planificación del lanzamiento desde el principio.

Verificacion de identidad          obligatoria, con plazo y perdida de visibilidad si vence
Identificador de organizacion      exigido a cuentas de empresa
Datos de contacto publicos         visibles en la ficha por normativa
Prueba cerrada previa              obligatoria para cuentas personales nuevas
Cumplimiento por cuenta            un incumplimiento grave afecta a todas tus apps

El proceso de apelación existe y funciona, pero conviene entender su economía antes de necesitarlo. Una apelación bien construida cita la política concreta, explica por qué la funcionalidad señalada no la incumple y aporta evidencia verificable —una grabación del flujo, credenciales de prueba, la ruta exacta hasta la pantalla en cuestión—. Una apelación que se limita a decir que la decisión es injusta consume un ciclo entero sin cambiar nada. Y como cada ciclo cuesta días, la diferencia entre ambas formas de escribir puede ser semanas de producto parado.

La última línea es la más importante y la que menos se interioriza: las sanciones se aplican a la cuenta, no a la app. Una app suspendida por suplantación puede arrastrar a las otras de la misma cuenta, y una cuenta cerrada no se recupera creando otra, porque la verificación de identidad detecta la reincidencia. Repartir apps de riesgos muy distintos en una sola cuenta es concentrar un riesgo que no se puede diversificar después.

Mantener es una obligación, no una virtud

La lección de fondo del apartado anterior es que el sujeto regulado se ha desplazado. Hace diez años la unidad de cumplimiento era la app y bastaba con que cada versión pasara su revisión; hoy la unidad es la cuenta, con identidad verificada, historial acumulado y responsabilidad transitiva sobre todo lo que publica. Eso convierte decisiones que parecían administrativas —bajo qué cuenta publicamos, quién figura como titular, cómo separamos productos de riesgo distinto— en decisiones de arquitectura de riesgo con consecuencias irreversibles.

Existe una regla de retirada por inactividad: las apps que llevan un tiempo largo sin recibir actualización dejan de ser detectables e instalables para nuevos usuarios, aunque sigan funcionando en quien las tenga. La justificación es de seguridad, porque una app antigua acumula librerías con vulnerabilidades conocidas y no ha visto ninguno de los cambios de comportamiento de los últimos sistemas.

La consecuencia de gestión es que una app publicada nunca está terminada. Incluso un producto congelado, sin funcionalidad nueva prevista, necesita una versión periódica que suba el nivel objetivo, actualice dependencias y renueve las declaraciones. Presupuestar ese trabajo como una tarea recurrente pequeña cuesta poco; descubrirlo tres años después, cuando hay que saltar varios niveles de API a la vez y media docena de librerías han cambiado de arquitectura, cuesta un proyecto entero.

A eso se suma una vigilancia continua sobre las dependencias. Cuando una librería que incluyes tiene una vulnerabilidad conocida grave, la tienda puede fijar una fecha límite tras la cual las versiones que la contengan dejan de aceptarse, y eso incluye las ya publicadas. Un equipo sin inventario de dependencias descubre esto por correo, con plazo corto y sin conocer siquiera qué parte de su código arrastra la librería afectada.