¿Qué debe incluir una especificación de configuración de dispositivo Android?

La respuesta corta

Una especificación de configuración de dispositivo Android es un registro de proyecto con control de versiones que declara el estado exacto del dispositivo que un lote debe reproducir: qué dispositivo físico, qué compilación de firmware, qué versiones de aplicación, qué política, qué vía de aprovisionamiento, qué supuestos de mercado, qué accesorios y qué embalaje, y quién es responsable de cada una de esas decisiones cuando alguna se mueve. Se redacta como borrador durante la viabilidad, se ajusta a una revisión candidata a muestra antes de configurar una unidad y se congela como referencia de producción aceptada una vez que la muestra ha sido revisada y aprobada. Dos cosas la hacen útil en lugar de decorativa. La primera es que cada campo relevante lleva un valor aprobado, una referencia de evidencia, un responsable designado y una regla de cambio, de modo que nadie tenga que adivinar si un valor se decidió o solo se escribió. La segunda es que va emparejada con una muestra con control de versiones: la especificación dice cuál debe ser el estado, el registro de la muestra dice cuál se observó que era una unidad real, y la aceptación es el momento en que se declara que ambos coinciden dentro de un alcance establecido. Los programas que Vantora cotiza a partir de unas 500 unidades dependen de ese emparejamiento, porque la consistencia de producción solo tiene sentido cuando existe una referencia con la que ser consistente.

La especificación de configuración es un registro de proyecto controlado

Una especificación de configuración de dispositivo Android no es una ficha técnica de consumo, ni un archivo de compilación de una aplicación Android, ni la prueba de que el dispositivo superó la aceptación. Es un registro de proyecto con control de versiones que define el estado de entrega previsto. «Especificación de configuración de dispositivo Android» es lenguaje de proyecto de Vantora y no un tipo de documento oficial de Android, así que cada campo relevante debe identificar un estado, enlazar a evidencia, designar un responsable y definir qué ocurre cuando ese estado cambia. La disciplina la impone la plataforma, no se inventó para ella: casi todos los valores que un comprador trata como uno solo son varios. Android expone el modelo, el producto, el hardware, el SKU y los identificadores de compilación como campos distintos; la etiqueta de versión, el nivel de API, el identificador de compilación y el nivel de parche de seguridad se mueven de forma independiente entre sí; una aplicación lleva un nombre de paquete, un código de versión, un nombre de versión y una identidad de firma que no son intercambiables. Una especificación que colapse cualquiera de esos valores en una única frase amable ya ha perdido la capacidad de decir si dos unidades son iguales, que es la única pregunta a la que una comprobación de lote puede responder de verdad. El corolario importa igual: los resultados de compatibilidad, las licencias, la aprobación de mercado y la evidencia de aceptación siguen siendo registros separados con sus propios titulares, porque una especificación que los absorbe se convierte en el documento que todos citan y que nadie puede verificar.

Qué es una muestra de dispositivo Android con control de versiones

Una especificación de configuración describe una intención. Una muestra con control de versiones es su contraparte física: una unidad configurada cuya identidad completa se ha capturado, anotado y sometido a control de cambios, de modo que cualquier afirmación posterior sobre la flota pueda rastrearse hasta algo que existió realmente sobre un banco de trabajo en una fecha conocida. La expresión importa porque «la muestra que enviamos» no es un registro: nombra un objeto, no un estado. Tres meses después nadie puede decir con seguridad qué compilación de firmware llevaba esa unidad, qué código de versión de la aplicación estaba instalado, si el launcher se había actualizado entre la demostración y la aprobación, o qué revisión de la política se aplicó cuando la persona que probó ejecutó los escenarios de quiosco. Una muestra con control de versiones responde a todo eso a partir de un registro escrito y no de la memoria, y lo hace porque la identidad se capturó en el momento de la configuración en lugar de reconstruirse después. La identidad que lleva una muestra tiene tres capas y cada una existe por un motivo distinto. La identidad de compra —fabricante, modelo exacto, SKU regional, variante de memoria y almacenamiento, vía de suministro— responde a «¿se puede volver a comprar esta unidad en el mercado de destino?», que es la pregunta en la que una muestra prometedora falla con más frecuencia meses después. La identidad en tiempo de ejecución —número de serie, IMEI, versión de Android y nivel de API, nivel de parche de seguridad, ID o huella de compilación del firmware, estado GMS o AOSP— responde a «¿es una unidad de producción realmente la misma plataforma de software?», y se captura del dispositivo y no de la ficha técnica porque ambos discrepan más a menudo de lo que los compradores esperan. La identidad de configuración —nombres de paquete de las aplicaciones con código y nombre de versión, firma y vía de distribución, paquete y versión del launcher, versión del DPC o del agente de gestión, revisión del perfil de políticas, modo de propiedad y vía de aprovisionamiento— responde a «¿qué se aplicó realmente a esta unidad?». Por encima de esas capas están los campos de proceso que hacen que el registro sea defendible y no solo detallado: la fecha de configuración, la persona designada que realizó las pruebas, la revisión de la matriz de aceptación con la que se probó la unidad, las limitaciones conocidas aceptadas junto con ella, y la fecha de aprobación del cliente y quién aprobó. Sin ese último grupo el registro es una instantánea técnica; con él, el registro es una decisión. El control de versiones añade tres propiedades que una instantánea no tiene. Los estados anteriores se conservan en lugar de sobrescribirse, así que una pregunta sobre una unidad entregada en marzo puede responderse contra la revisión que regía en marzo. Cada revisión tiene un alcance que indica qué lotes o tramos rige, que es lo que permite que una fase piloto de veinte a cien unidades se ejecute contra una revisión mientras las unidades restantes del programa esperan la siguiente. Y todo cambio es atribuible —alguien lo planteó, alguien lo aprobó y ambos quedan registrados—, que es la diferencia entre una enmienda y una discusión. La mecánica de reproducir un estado aprobado en las unidades de producción corresponde a la preparación de lotes Android; lo que importa aquí es que la preparación tiene una referencia fija que reproducir y una regla de detención que se activa cuando una unidad se desvía de ella.

Cómo se referencian entre sí el registro de la muestra y la especificación de configuración

Los dos registros responden a preguntas distintas y no deben repetirse el uno al otro. La especificación de configuración es prescriptiva: indica el valor previsto de cada campo relevante, la tolerancia o la variación permitida a su alrededor, el responsable y la regla de cambio. El registro de la muestra es descriptivo: indica lo que se observó que era una unidad real, en una fecha, probada por una persona designada. La aceptación es el momento en que ambos se comparan y se declara que coinciden dentro de un alcance establecido, y esa comparación solo es posible porque los dos registros usan los mismos nombres de campo en el mismo orden. El vínculo debe ser explícito y estrecho. La especificación lleva el identificador de la muestra y la revisión de la muestra con la que se aceptó; el registro de la muestra lleva la revisión de la especificación desde la que se configuró y la revisión de la matriz de aceptación con la que se probó. No se copia nada más de un documento al otro. Cuando un valor se duplica en ambos documentos, tarde o temprano se actualizará en uno y no en el otro, y el proyecto pasa a tener dos verdades y ninguna forma de saber cuál regía un lote ya enviado. Cuando un valor tiene que aparecer de verdad en ambos —el ID de compilación del firmware es el caso habitual—, un documento es su propietario y el otro lo referencia, y la referencia indica qué documento es el autoritativo. Las brechas residuales van a otro sitio distinto: una limitación que se aceptó en lugar de corregirse pertenece a la biblioteca de limitaciones conocidas, con un responsable y un disparador de revalidación, y no enterrada como salvedad dentro de un campo de la especificación, porque un campo que se lee como aprobado lo tratan como aprobado todos los que vienen después.

Use siete secciones y cuatro controles de campo

Para cada campo relevante, registre un valor aprobado o un rango acotado, una referencia de evidencia, el responsable que lo confirma y la regla de variación o de cambio. Un campo sin resolver permanece abierto con un responsable y un punto de decisión; no debe rellenarse con una conjetura plausible. Esos cuatro controles son los que separan una especificación de una lista de deseos, y aplicarlos suele ser más revelador que los propios valores: un campo del que nadie quiere hacerse responsable es un campo que nadie ha decidido. Estructure el registro de modo que un revisor pueda establecer en una sola pasada si el dispositivo físico, la plataforma de software, el estado de la aplicación, el diseño de gestión, el mercado y el kit, y el rastro de evidencia han sido resueltos por alguien con autoridad para resolverlos. Lo que la mayoría de las especificaciones se salta es el límite —declarar qué queda deliberadamente fuera de cada sección—, y saltárselo es la vía por la que las conclusiones de certificación y las condiciones comerciales se cuelan en una línea base de entrega. Mantenga los secretos completamente fuera: los tokens de inscripción, las credenciales de administrador y el material de firma se referencian por ubicación y custodio, nunca se pegan en un registro que va a circular como archivo adjunto.

Sustituya las etiquetas vagas por cláusulas controladas

El objetivo no son más palabras, sino menos interpretaciones. Use marcadores de posición mientras la especificación es un borrador, pero no permita que una referencia de producción aceptada oculte una incógnita relevante detrás de un «por definir», una captura de pantalla sin etiquetar o un enlace inaccesible. El patrón que separa una etiqueta vaga de una cláusula digna de una especificación es constante: la etiqueta nombra un resultado, la cláusula nombra el valor, el mecanismo, el responsable y la variación permitida. «El firmware más reciente» es el ejemplo más claro, porque no es un estado en absoluto: es un objetivo móvil que se resuelve de forma distinta el día en que se prepara cada unidad, que es exactamente cómo dos tramos del mismo pedido acaban con compilaciones diferentes. «Igual que la muestra aceptada» es el más peligroso, porque suena como el compromiso más firme posible mientras delega toda la definición en un registro que quizá no esté bajo control de versiones. Para cada uno de estos casos existe además evidencia que corresponde a otro sitio, y arrastrarla a la especificación es la vía por la que una línea base de entrega se convierte en un documento irrevisable que nadie confía lo suficiente como para actualizar.

Mantenga separados los registros del despliegue

La especificación de configuración define el estado objetivo. Los registros adyacentes definen la necesidad, la prueba y la ejecución por unidad. Mantenerlos separados preserva la trazabilidad e impide que un solo documento pretenda responder a todas las preguntas del despliegue. La prueba práctica es preguntarse contra qué registro debe resolverse un desacuerdo. Si la discusión es sobre si un requisito llegó a acordarse, eso es la ficha de requisitos. Si es sobre cuál se suponía que era el estado entregado, eso es la especificación de configuración. Si es sobre si se demostró que el estado funcionaba, eso es la matriz de aceptación, que recoge el escenario, el comportamiento esperado, el comportamiento observado, el veredicto y el responsable. Si es sobre qué unidades recibieron qué estado, eso es el registro de preparación o del lote. Fusionar dos cualesquiera de estos produce un documento que no puede responder con claridad a ninguna de las dos preguntas: una especificación que carga resultados de pruebas queda obsoleta en cuanto se vuelve a ejecutar un escenario, y una matriz de aceptación que carga definiciones de campos se convierte en el lugar al que la gente acude a consultar valores de producción que allí nunca se mantuvieron. La separación también decide quién puede cambiar qué, y la única regla que merece enunciarse de forma explícita es que un registro de preparación nunca autoriza un cambio del estado aprobado. Registra que el estado se aplicó, o que una unidad se desvió y fue detenida.

Congele la referencia y después controle el cambio

Un SKU de dispositivo, una revisión de hardware, una huella de firmware, una línea base de parches, un artefacto de aplicación, una vía de firma, una política, una vía de aprovisionamiento, un supuesto de mercado, un accesorio, un recurso de marca o un embalaje pueden cambiar todos la configuración. Abra una revisión controlada, compárela con la referencia vigente, identifique la evidencia y las filas de aceptación afectadas, asigne responsables y obtenga la decisión requerida antes de usar el nuevo estado. Vale la pena nombrar de forma explícita los cuatro estados siguientes en el propio documento, porque buena parte de la confusión en un proyecto de dispositivos viene de que se lee un borrador como si fuera una aprobación. Un borrador invita a la objeción; una revisión candidata a muestra es un compromiso de configurar una unidad de una manera concreta; una referencia de producción aceptada es una autorización con un alcance y una fecha; una revisión sustituida es evidencia conservada, no un error que haya que borrar. Dónde se sitúan esos puntos de control dentro de la secuencia más amplia —viabilidad, muestra, aceptación, preparación, traspaso— se expone en cómo funciona un despliegue validado de dispositivos Android.

1. 1Borrador de viabilidad: requisitos confirmados, candidatos, incógnitas y responsables, sin implicar aceptación.
2. 2Revisión candidata a muestra: la configuración exacta que la muestra debe representar.
3. 3Referencia de producción aceptada: decisión de muestra autorizada, limitaciones y evidencia para un alcance definido.
4. 4Revisión sustituida: se conserva después de que entre en vigor una revisión aprobada más reciente.

Revisión o enmienda: qué desencadena cada cambio

Una vez aceptada una referencia, cada cambio propuesto necesita una vía, y solo hay tres. Una enmienda corrige el documento sin alterar el estado del dispositivo: un nombre de responsable corregido, una tolerancia aclarada, un enlace que había caducado. Se registra, se fecha y se atribuye, pero no toca la aceptación ni exige que quien aprueba vuelva a mirar el dispositivo. Una revisión cambia el estado previsto, lo que significa un nuevo número de revisión, un diff contra la referencia anterior, una evaluación de qué filas de aceptación quedan afectadas y una decisión de la persona aprobadora designada en el documento antes de preparar ninguna unidad con ese estado. Una sustitución o un cambio de modo de propiedad es un tercer caso: produce una muestra nueva en lugar de una revisión, porque lo que se valida ya no es lo que se validó. La línea divisoria no es el tamaño del cambio, sino si la evidencia sigue aplicando. Un inserto de embalaje cosmético puede ser una enmienda; un cambio de cargador no, porque la evidencia eléctrica y de mercado va unida a un número de pieza. Un cambio de política de totalmente administrado a una configuración dedicada es una revisión, dado que el uso dedicado es un subconjunto del modelo totalmente administrado y el cambio se aplica como política sobre un dispositivo ya aprovisionado. Un cambio de perfil de trabajo a gestión como device owner no es una revisión en absoluto, porque la propiedad queda fijada en el aprovisionamiento y no puede conmutarse desde una consola: el dispositivo se vuelve a aprovisionar desde un estado limpio, y se configura y se acepta una muestra nueva. Esa asimetría es lo más útil que conviene saber antes de escribir un modo en una especificación de compra, y los modos en sí se comparan en dispositivos Android dedicados frente a totalmente administrados. La autoridad de aprobación debe escribirse en la especificación en lugar de darse por supuesta. En la mayoría de los programas, el responsable técnico evalúa el impacto, la persona aprobadora del cliente autoriza todo lo que cambie el comportamiento aceptado o el costo, y la preparación se detiene hasta que exista esa autorización. El sentido de designarlos es que el fallo caro no es una mala decisión: es un cambio que llegó a producción porque nadie era claramente responsable de decir que no.

Cuando el OEM publica una nueva compilación de firmware después de la aceptación

Esta es la forma más habitual en que una muestra aprobada deja de representar en silencio a la flota, y merece una regla escrita en lugar de una respuesta improvisada. Una especificación de configuración puede congelar el valor que registra; no puede congelar lo que publica un fabricante o un operador. Los dispositivos comprados semanas después de la aceptación pueden salir de fábrica con una compilación más reciente, y un dispositivo que llega al campo puede actualizarse solo salvo que se controle la vía de actualización. Android expone una política de actualizaciones del sistema que un controlador de políticas del dispositivo que actúe como device owner puede usar para posponer la instalación o encuadrarla en una ventana cuando el OEM lo admite, y vale la pena aplicarla, pero rige el momento de la instalación en un dispositivo administrado, no lo que llega precargado en un lote entrante, y su comportamiento depende del OEM y de la plataforma. La respuesta viable tiene cuatro partes. Detectarlo: las unidades entrantes se contrastan con el ID o la huella de compilación registrados durante la preparación, de modo que una discrepancia se descubre en el banco de trabajo y no en las instalaciones del cliente. Clasificarlo: un movimiento de nivel de parche dentro de la misma rama de firmware suele ser más acotado que un nuevo ID de compilación, y una especificación que indique un rango de parches de forma explícita evita reabrir la referencia con cada boletín mensual. Acotar la reprueba: en lugar de volver a ejecutar toda la matriz, vuelva a ejecutar las filas de aceptación que dependan de forma plausible de la plataforma: la inscripción desde un estado limpio, la aplicación de políticas, el comportamiento de lock task, los controladores de periféricos, y el primer arranque y la vía de permisos de la aplicación. Decidir y registrar: la nueva compilación pasa a ser una revisión de la referencia aceptada, o las unidades afectadas se retienen y la diferencia se escala. Se resuelva como se resuelva, el resultado se escribe en la especificación y, cuando una diferencia se acepta en lugar de corregirse, también en el registro de limitaciones conocidas con un responsable. El modo de fallo contra el que hay que diseñar es el silencioso: unidades enviadas con una compilación que nadie comparó, descubierto solo cuando una parte de la flota se comporta de otra manera y no hay registro de qué cambió. La regla anterior es la respuesta del lado de la especificación: qué dice la referencia y qué autoridad la mueve. La respuesta del lado del banco de trabajo —cómo se comprueba realmente un lote entrante, cómo es una reverificación de minipiloto en un pedido repetido y cómo se apartan del flujo de entrega las unidades discrepantes— corresponde a la preparación de lotes de dispositivos Android.

Cómo se evalúa una solicitud de sustitución

Las solicitudes de sustitución llegan por motivos ordinarios: una variante llega al final de su vida, un nivel de memoria escasea, un accesorio se descontinúa, un plazo de entrega se sale de la ventana comprometida. Son legítimas, y rechazarlas de plano no es una política; pero aceptar una por la sola fuerza de una ficha técnica parecida es la vía por la que un programa adquiere un defecto que luego no sabe explicar. Una evaluación útil sigue un orden fijo. Primero, identifique qué difiere realmente: no el nombre comercial del modelo, sino los campos que la especificación controla —SKU, radios y bandas admitidas, memoria y almacenamiento, rama de firmware, estado GMS o AOSP, número de pieza del periférico o del accesorio, aprobaciones de mercado—. Segundo, asigne cada diferencia a la matriz de aceptación y marque las filas a las que podría afectar; si una diferencia no toca ninguna fila, es probable que la especificación no esté controlando algo que debería. Tercero, decida la vía con la regla anterior: un SKU regional o una revisión de hardware distintos son una muestra nueva; un cambio de accesorio es normalmente una revisión con una pieza designada y una regla de sustitución. Cuarto, valore el costo de la evaluación con honestidad, tanto en tiempo como en dinero, porque una sustitución que llega tarde en un programa compite directamente con la fecha de entrega que pretendía proteger. Quinto, registre la decisión —incluida una negativa— para que la misma solicitud no vuelva sin información nueva. Hay dos salvaguardas que conviene escribir en la especificación por adelantado. Designe qué campos son sustituibles siquiera, para que compras lo sepa antes de preguntar; e indique que cualquier variante sustituida entra en el programa por la misma vía de muestra y aceptación que la original, confirmada normalmente en un tramo reducido antes de preparar las unidades restantes de un programa. Ese acuerdo previo es lo que mantiene una sustitución como problema de calendario en lugar de como una renegociación.

Descargue la plantilla de especificación de configuración del dispositivo

Use la plantilla para capturar la plataforma prevista del dispositivo, el estado del software y de las aplicaciones, la política, el embalaje, los accesorios, la evidencia y las referencias de preparación. Mantenga los secretos y las condiciones comerciales en sus sistemas controlados, y conecte la revisión final con la muestra y la evidencia de aceptación que la respaldan. Si un proyecto ya tiene una especificación en otro formato, el ejercicio útil no es reescribirla, sino someterla a los cuatro controles de campo: ¿lleva cada campo relevante un valor aprobado, una referencia de evidencia, un responsable designado y una regla de cambio? Los campos que no superan esa prueba son donde un despliegue suele torcerse, y son baratos de corregir mientras la especificación sigue siendo un borrador. Cuando la pregunta más amplia sobre la preparación sigue abierta —si un dispositivo que se inscribe correctamente está de verdad listo para un lote—, empiece por dispositivos Android preparados para MDM frente a preparados para el despliegue y traiga después el modelo objetivo, la aplicación, la plataforma de gestión, los mercados y el rango de cantidades, para que la especificación pueda construirse frente a restricciones reales.