Guide de préparation de l’appareil
La taille du modèle, le nom de la puce et la version d’Android ne suffisent pas. Vérifiez la version exacte de l’application, l’artefact, le runtime, la tâche et la reprise sur le téléphone visé.
Les modules Android de ce dépôt déclarent minSdk 31. C’est un paramètre de compilation qui fixe le niveau d’API Android minimal pour installer cette version. Ce n’est ni une liste de téléphones testés, ni un seuil de RAM, ni une promesse de performances. Android distingue ce minimum des fonctions matérielles et de la compatibilité générale.
Android 12 correspond au niveau d’API 31. Cette correspondance situe la limite du système ; elle ne prouve pas qu’un appareil chargera un modèle donné ou terminera une tâche de manière fiable.
L’ancienne page listait huit téléphones, des durées d’inférence et des catégories incompatibles. Les enregistrements de test par appareil ne sont pas disponibles dans le dépôt ; ces affirmations sont donc retirées. Aucune matrice de compatibilité, RAM minimale, recommandation de puce ou vitesse n’est publiée ici. Une exigence de compilation n’est pas un résultat de test.
systemRequirements.sources.minSdk · systemRequirements.sources.api · systemRequirements.sources.compatibility
La préparation dépend de la tâche. Un téléphone peut installer l’application mais échouer au chargement du modèle, à l’ouverture de l’appareil photo, au traitement d’une longue entrée ou après une interruption. Décrivez un travail précis et testez le parcours complet sur l’appareil concerné.
Exemple : ouvrir une version précise, charger le modèle local prévu, analyser hors ligne une image synthétique de reçu, afficher un résultat lisible puis recommencer après fermeture et réouverture. C’est un protocole, pas l’affirmation qu’une version publique de Cove l’a réussi sur un téléphone donné.
Choisissez une tâche limitée qui protège les données. Changez une variable à la fois et consignez aussi les échecs.
Notez le fabricant, le modèle exact, la version et la compilation Android, l’espace libre, la version de l’application et la date. Indiquez si l’installation est une version de développement ou officielle. Le niveau d’API aide à vérifier le plancher système ; le nom du téléphone ne prouve pas son comportement matériel.
Installez la version exacte à évaluer et notez les filtres de la boutique, erreurs, autorisations et étapes de première utilisation. Une installation réussie ne prouve pas le téléchargement du modèle, la mémoire disponible ou le fonctionnement de la tâche.
Relevez le fichier du modèle et la version du runtime, terminez les téléchargements requis et notez l’identité ou la somme de contrôle si elle existe. Taille téléchargée, stockage installé et mémoire de travail sont distincts. N’inventez pas de quota universel.
Choisissez une entrée sans donnée sensible et avec un résultat attendu, par exemple une note fictive. Fixez langue, longueur d’entrée et de sortie et critère de réussite. Mesurez la mémoire avec un outil répétable ; la RAM totale n’est pas celle disponible pour le processus.
Partez de l’écran habituel, attendez l’initialisation, exécutez la tâche et examinez le résultat, la durée et les erreurs. Distinguez premier démarrage et démarrages suivants. Notez l’étape en échec. Ne comparez la vitesse que si artefact, runtime, entrées et méthode de mesure sont identiques.
Fermez l’application ou passez-la en arrière-plan à un moment sûr, rouvrez-la et répétez. Pour vérifier le mode hors ligne, déconnectez après la préparation et démarrez une nouvelle session ; un résultat en cache ne compte pas. Consignez reprise et erreurs. Un petit échantillon n’est pas une référence universelle.
Définissez les seuils de votre tâche avant l’essai. Cette page ne fixe pas de seuil universel de durée, mémoire, température ou batterie.
Une évaluation utile relie chaque affirmation à des preuves adaptées. Un appareil peut réussir l’installation puis échouer sur une tâche gourmande en mémoire.
| Dimension | Ce qu’indique la configuration | Preuve nécessaire | Votre vérification |
|---|---|---|---|
| Version Android | Le projet déclare minSdk 31. | Installation du paquet exact sur cette version système. | Noter version et résultat. |
| Modèle | Nom et taille ne décrivent qu’une partie du système. | Identité du fichier, runtime, chargement et mémoire observée. | Noter l’identité et l’initialisation. |
| Ressources | RAM, stockage et puce ne sont pas des résultats de tâche. | Mémoire, stockage, erreurs et comportement observés. | Mesurer la session et son contexte. |
| Parcours | Une API disponible ne prouve pas une fonction complète. | Une entrée neuve franchit toutes les étapes et satisfait la grille. | Répéter aussi la reprise. |
La portée de la conclusion doit correspondre aux preuves. Un téléphone et un scénario ne décrivent que cet essai. Une liste générale exige des essais reproductibles sur des configurations nommées, des données brutes et une règle publiée.
Non. C’est le niveau d’API minimal déclaré par la version. Cela ne certifie ni chaque téléphone, ni la mémoire, ni l’accélérateur, ni la réussite d’une tâche. Testez le paquet exact sur l’appareil visé.
Cette page ne publie pas de chiffre faute de mesures validées par appareil. Les tampons du runtime, les entrées et sorties, les autres applications et le système comptent aussi. Mesurez le pic sur la tâche et la version exactes.
Aucun seuil de famille de puces n’est affirmé. Son nom ne prouve ni son utilisation par le runtime ni la qualité de la tâche. Testez l’artefact et le runtime exacts.
Aucune durée universelle ne peut être défendue ici. Elle dépend du modèle, de l’application, du runtime, de l’accélération, des entrées et de l’état du téléphone. Fixez une limite avant la mesure et publiez les répétitions et conditions.
Pour chaque configuration, consignez téléphone et système exacts, version de l’application, artefact, runtime, tâche, méthode, répétitions, erreurs et règle de réussite. Indiquez portée et date, conservez les échecs et retestez après les changements.
Un succès prouve seulement que cette version, cet artefact, ce téléphone, ce système et cette tâche ont accompli le parcours consigné à cette date. Réévaluez si l’un change. Un échec précisément décrit vaut mieux qu’un verdict général sans preuve.
Comprendre le fonctionnement de l’IA locale · Exemple de caméra dans des conditions difficiles
Vérification factuelle : équipe éditoriale Cove, 2026-09-27. La relecture chinoise par le propriétaire reste en attente ; la traduction n’est pas présentée comme approuvée.
