Developer Hub / Base de compatibilité

Liste de contrôle de préparation de l'appareil

Transformez une affirmation vague comme « appareil Android pris en charge » en un enregistrement de configuration qu’un autre ingénieur peut reproduire.

Norme de publicationDéveloppeurs

Connectez et validez votre application sur le matériel cible.

Une référence de périphérique avec suffisamment de portée pour approuver, retester ou rejeter une configuration de déploiement.

Développeurs, ingénieurs assurance qualité et architectes de solutions préparant un déploiement pilote ou de flotte.

Les ressources publiques ciblent des modèles reproductibles. SDK, firmware et documents fabricant restreints restent dans leurs canaux approuvés.

Des preuves comparables avec méthode, version et limites.

Ressources développeursBase de compatibilité
Laboratoire RuggedLayerDébutant
Guides, notes SDK, exemples et compatibilité pour terminaux code-barres et RFID.Développeurs, ingénieurs assurance qualité et architectes de solutions préparant un déploiement pilote ou de flotte.
  • Un modèle exact et une variante régionale, pas seulement un nom de famille de produits.
  • Le canal de création et de déploiement de l’application cible.
  • Un endroit pour stocker les preuves de test sans placer les données client dans le contrôle de source.

Norme de publication

Intégrer Android en entreprise avec des preuves versionnées.

Les ressources publiques ciblent des modèles reproductibles. SDK, firmware et documents fabricant restreints restent dans leurs canaux approuvés.

  1. 01

    Geler l'identité de l'appareil

    Notez le modèle exact, l'option de scanner ou de périphérique, la variante régionale, les accessoires et la configuration indépendante de la série. «Même série» n'est pas le même contrat matériel.

  2. 02

    Geler la pile logicielle

    Capturez la version Android, le correctif de sécurité, le micrologiciel, la version approuvée de SDK, la version de l'application et le profil MDM. Notez si un paramètre est persistant, de session uniquement ou géré par la couche de déploiement.

  3. 03

    Décrire les conditions de fonctionnement

    Incluez le mode de déclenchement, l'étiquette ou le jeu d'étiquettes, le réseau, les gants, l'éclairage, la température, la durée du décalage et tout support, imprimante ou accessoire de paiement impliqué dans le flux de travail.

  4. 04

    Attribuer une conclusion limitée

    Utilisez des produits pris en charge par le fabricant, testés par nos soins, validés par le client, partiellement pris en charge, non testés ou non pris en charge. Chaque conclusion a besoin d’une date et d’une limite.

Applications exemples / Kotlin

Modèles SDK et API

Conservez ce dossier avec les preuves de test. Ne placez pas de numéros de série, d'informations d'identification ou de données client dans un exemple public.

device-baseline.kt

data class DeviceBaseline(
  val model: String,
  val region: String,
  val android: String,
  val firmware: String,
  val sdk: String,
  val appBuild: String,
  val peripherals: List<String>,
  val verifiedAt: LocalDate,
)

fun DeviceBaseline.isScoped(): Boolean =
  model.isNotBlank() &&
    android.isNotBlank() &&
    firmware.isNotBlank() &&
    sdk.isNotBlank() &&
    appBuild.isNotBlank() &&
    peripherals.isNotEmpty()
Aucun binaire fournisseur, référence d'API, firmware ou exemple de code source n'est publié sans autorisation de redistribution et périmètre pris en charge enregistrés.

Distribution des SDK

Contrôle de publication

Aucun binaire fournisseur, référence d'API, firmware ou exemple de code source n'est publié sans autorisation de redistribution et périmètre pris en charge enregistrés.

Seule une famille de produits est enregistrée

Suspendez la réclamation et demandez le modèle exact et l'option matérielle.

Le micrologiciel ou SDK est inconnu

Marquez le résultat comme non testé ; ne déduisez pas le support d’une version différente.

Un paramètre change après le redémarrage

Enregistrez le comportement de persistance et déplacez-le dans la liste de contrôle de déploiement.

Le résultat ne fonctionne que dans une seule région

Divisez l'enregistrement par région et configuration au lieu d'élargir l'instruction.

États de preuve

Des preuves comparables avec méthode, version et limites.

  1. 01

    Joindre une méthode de test reproductible et le résultat attendu à la ligne de base.

  2. 02

    Enregistrez la version de l'application et le logiciel exact de l'appareil avant chaque nouveau test matériel.

  3. 03

    Séparez la documentation du fournisseur de RuggedLayer ou des preuves de test client.

  4. 04

    Écrivez la limitation à côté de la conclusion, pas dans une note interne cachée.

Connectez et validez votre application sur le matériel cible. Utilisez la référence comme première page d’une demande de validation d’application.

Ressources

Modèles SDK et API

Aucun binaire fournisseur, référence d'API, firmware ou exemple de code source n'est publié sans autorisation de redistribution et périmètre pris en charge enregistrés.

Connectez et validez votre application sur le matériel cible.

Partagez le flux applicatif non confidentiel, le terminal actuel et le chemin d’intégration ; nous cadrerons le livrable de validation le plus pertinent.

Connecter et valider mon application