LaunchLint Academy
La respuesta breve
- Data Safety describe qué datos recoge o comparte la app publicada, para qué y con qué seguridad y borrado. Incluso una app sin recogida completa el formulario y enlaza una política de privacidad.
- package.json, configuración y permisos son señales, no una declaración terminada. SDKs, backend, consentimiento y transmisiones reales también deben revisarse.
- Crea una ficha por SDK y endpoint, clasifica collected y shared con las definiciones de Google y revisa Play Console ante cualquier cambio relevante.
1. Qué versión y datos cubre el formulario
Google exige el formulario para apps publicadas en closed, open y production; internal testing exclusivo queda exento. La declaración vive a nivel de package y debe representar artefactos activos. No basta mirar el último branch si versiones antiguas distribuidas incluyen otros SDKs.
La recogida suele implicar transmisión fuera del dispositivo. El procesamiento únicamente local puede quedar fuera. Un permiso no prueba recogida y la ausencia de permisos sensibles no prueba que no haya telemetría, IP, identificadores o interacciones.
3. Inventariar SDKs Expo y dependencias nativas
Expo abstrae el proyecto nativo, pero no la responsabilidad. Analytics, crash, push, auth, maps, ads, pagos y social login pueden transmitir datos. Revisa dependencias directas y transitivas, configuración production, módulos opcionales e inicialización antes del consentimiento.
Google responsabiliza al developer del código tercero. La documentación del proveedor y Play SDK Index ayudan, pero tu configuración determina el comportamiento activo.
{
"sdk": "example-analytics",
"enabledInProduction": true,
"dataTypes": ["Device identifiers", "App interactions"],
"transmittedOffDevice": true,
"purpose": ["Analytics"],
"requiredOrOptional": "optional after consent",
"encryptedInTransit": true,
"deletionPath": "privacy@example.com"
}- package.json y lockfile
- Plugins de app config
- Manifest y permisos
- Inicialización y consent
- Endpoints y uploads
- Borrado y opt-out
- Variables de release
4. Finalidad, opcionalidad, cifrado y borrado
Selecciona solo finalidades usadas, no todas las que menciona el proveedor. Optional exige que el usuario pueda evitar la recogida. Un toggle posterior a la inicialización no elimina la transferencia anterior.
Declara cifrado solo si cubre todos los datos transmitidos. Revisa endpoints antiguos, uploads, WebViews y SDKs. Para borrado distingue cuenta, perfil, backups, retención legal y copias de terceros.
- Finalidad por tipo y receptor
- Required u optional probado
- TLS en todas las transferencias
- Retención en la política de privacidad
- Borrado in-app y web
- Suscripciones y retención explicadas
5. La eliminación de cuenta también es evidencia
Si la app crea cuentas, Google exige una ruta in-app y un recurso web para solicitar eliminación de cuenta y datos asociados. El enlace puede mostrarse públicamente y debe llevar a un proceso útil, no a la homepage.
Prueba identificación, confirmación, plazo, estado y solicitudes incompletas sin sesión de developer. Indica datos retenidos legítimamente y duración. Desactivar o desinstalar no equivale a eliminar.
6. Validar contra build y runtime
El análisis estático prioriza preguntas, pero no sustituye observar runtime. Instala el artefacto production en un dispositivo limpio y prueba primer inicio, consent, login, función principal, upload, compra, push y borrado. Registra servicios y destinos de red.
Compara cada tipo entre archivos del proyecto, transmisión, backend, docs del SDK, política de privacidad y formulario. No adivines: pregunta al proveedor o responsable y documenta la decisión.
- Inventario production cerrado
- Consent antes del SDK opcional
- Tipos y fines alineados
- Excepciones documentadas
- Cifrado y borrado probados
- política de privacidad actualizada
- Draft revisado
- Responsable y fecha
7. Mantener Data Safety con cada release
Nuevo analytics, auth, ads, uploads o finalidad backend puede cambiar respuestas. Incluye la revisión en Definition of Done y release checklist antes del despliegue amplio. El diff de package.json es un disparador útil, pero también cuentan cambios server-side que no aparecen en el repositorio móvil.
LaunchLint encuentra SDKs, plugins, permisos, endpoints y señales de borrado con pruebas de archivo, pero no ejecuta código ni observa transmisiones. La declaración final combina archivos del proyecto, runtime, backend y consola. Guarda la versión del formulario, el build comprobado, fecha y responsable para entender en el siguiente release qué supuesto ha cambiado.
Control de cambios:
- SDK añadido, eliminado o actualizado
- Nueva finalidad de un dato existente
- Nuevo endpoint o proveedor
- Consentimiento movido o rediseñado
- Cambio en retención o borrado
- Nuevo país, edad o audiencia
- Nueva función de upload
- Revisión y aprobación del draft
Preguntas frecuentes
¿Una app sin recogida debe completar Data Safety?
Sí en los tracks relevantes. También enlaza una política de privacidad y verifica los SDKs.
¿package.json puede generar el formulario?
No. No conoce runtime, backend, fines, consentimiento, retención ni borrado completos.
¿Un proveedor de servicio siempre cuenta como sharing?
No necesariamente; Google contempla excepciones según relación y uso real. Documenta la decisión.
¿Cuándo se actualiza?
Al cambiar tipos, fines, receptores, SDKs, consentimiento, seguridad o borrado.