Qué construimos con él
Android es un destino para todo lo móvil que construimos, y tratarlo como «la otra plataforma» es la forma de acabar con productos rotos en él. Tiene sus propias reglas: límites de ejecución en segundo plano que matan trabajo que dabas por terminado, un modelo de permisos que cambia de forma relevante entre versiones, optimizaciones de batería específicas de cada fabricante y un abanico de dispositivos lo bastante amplio como para que las suposiciones de rendimiento de un buque insignia no se sostengan.
El trabajo de plataforma en sí se escribe en Kotlin detrás de platform channels y se compila con Gradle: servicios en primer plano, canales de notificación, NFC y acceso a hardware, la fontanería del install-referrer y SDKs de proveedores que solo existen para Android.
Dónde encaja
Bajo cada app Flutter de nuestro portfolio, todas ellas publicadas en Google Play. También es donde el trabajo de marca blanca se pone interesante: muchas apps de marca desde una base de código significa muchos application ID, identidades de firma y fichas de tienda, generadas en vez de mantenidas a mano.
Cuándo lo recomendamos
No es realmente una recomendación: si estás construyendo un producto móvil fuera de Estados Unidos, es probable que Android sea la mayoría de tus usuarios, y tratarlo como secundario es una decisión de negocio más que técnica.
Donde sí discutiríamos es en hacer Android completamente nativo para un producto que también necesita iOS, salvo que algo concreto lo obligue. Y en ignorar la gama baja: el dispositivo más barato de tu analítica es el que decide tus reseñas.
