Leitfaden zur Gerätebereitschaft
Modellgröße, Chipname oder Android-Version reichen als Antwort nicht aus. Prüfe den konkreten App-Build, das Modellartefakt, die Laufzeitumgebung, die Aufgabe und die Wiederherstellung auf dem vorgesehenen Gerät.
Die Android-Module dieses Repositorys deklarieren minSdk 31. Das ist eine Build-Einstellung und legt die minimale Android-API-Ebene für die Installation dieses Builds fest. Es ist weder eine getestete Liste kompatibler Telefone noch eine RAM-Anforderung oder Leistungszusage. Android unterscheidet diesen Mindestwert von Hardwaremerkmalen und der allgemeinen Gerätekompatibilität.
Android 12 entspricht API-Ebene 31. Damit lässt sich die Betriebssystemgrenze einordnen; es ist kein Nachweis, dass ein Gerät ein bestimmtes Modell laden oder eine Aufgabe zuverlässig abschließen kann.
Die frühere Seite nannte acht Telefone, Inferenzzeiten und inkompatible Gerätekategorien. Die zugehörigen Einzeltestprotokolle liegen im Repository nicht vor; diese Aussagen wurden entfernt. Hier gibt es keine öffentliche Kompatibilitätsmatrix, Mindest-RAM-Angabe, Chip-Empfehlung oder Geschwindigkeitszahl. Eine Build-Anforderung ist kein Testergebnis.
systemRequirements.sources.minSdk · systemRequirements.sources.api · systemRequirements.sources.compatibility
Die Gerätebereitschaft hängt von der Aufgabe ab. Ein Telefon kann die App installieren, aber beim Laden des Modells, Öffnen der Kamera, Verarbeiten einer langen Eingabe oder Wiederherstellen nach einer Unterbrechung scheitern. Beschreibe eine konkrete Arbeit und prüfe den vollständigen Ablauf auf genau diesem Gerät.
Beispiel: einen bestimmten App-Build öffnen, das vorgesehene lokale Modell laden, offline ein synthetisches Kassenbonbild analysieren, ein lesbares Ergebnis anzeigen und die Prüfung nach dem Schließen und erneuten Öffnen wiederholen. Das ist ein Testplan, kein Nachweis für einen öffentlichen Cove-Build auf einem bestimmten Telefon.
Verwende eine klar abgegrenzte, datenschutzfreundliche Aufgabe. Ändere jeweils nur eine Variable und protokolliere Fehler ebenso wie Erfolge.
Notiere Hersteller und genaues Modell, Android-Version und Build, freien Speicher, App-Version und Datum. Vermerke, ob es ein Entwicklungsbuild oder die offizielle Verteilung ist. Die API-Ebene hilft beim Prüfen der Systemuntergrenze; der Modellname allein belegt kein Hardwareverhalten.
Installiere genau den vorgesehenen Build und notiere Store-Filter, Paketfehler, Berechtigungen und Ersteinrichtung. Eine erfolgreiche Installation belegt nur diesen Schritt, nicht den Modelldownload, verfügbaren Speicher oder die Funktion der Kamera und anderer Aufgaben.
Erfasse Modelldatei und Laufzeitversion. Schließe nötige Downloads ab und notiere Datei-ID oder Prüfsumme, sofern verfügbar. Downloadgröße, belegter Speicher und Arbeitsspeicher sind verschiedene Werte. Erfinde keine allgemeine freie Speicheranforderung.
Wähle eine harmlose Eingabe mit bekanntem Ergebnis, etwa eine synthetische Notiz. Lege Sprache, Eingabe- und Ausgabelänge sowie Bestehenskriterium vorher fest. Beobachte den Speicher mit einem wiederholbaren Werkzeug; der verbaute RAM entspricht nicht dem verfügbaren Prozessspeicher.
Starte auf dem normalen Einstiegsbildschirm, warte auf die Initialisierung, führe die Aufgabe aus und prüfe Ergebnis, Dauer und sichtbare Fehler. Trenne Kaltstart von späteren Läufen und notiere, an welcher Stufe ein Fehler auftritt. Geschwindigkeit lässt sich nur bei gleichen Artefakten, Eingaben und Messbedingungen vergleichen.
Schließe die App oder wechsle sicher in den Hintergrund, öffne sie erneut und wiederhole dieselbe Aufgabe. Für Offline-Tests nach der Vorbereitung trennen und eine neue Sitzung beginnen; ein zwischengespeichertes Ergebnis zählt nicht. Halte Fehler und Erholung fest. Eine kleine Stichprobe ist kein allgemeiner Benchmark.
So wird aus „scheint zu funktionieren“ eine überprüfbare Entscheidung. Diese Seite setzt keine allgemeine Grenze für Zeit, Speicher, Temperatur oder Akku fest.
Eine brauchbare Kompatibilitätsprüfung verknüpft jede Aussage mit passenden Belegen. Dasselbe Telefon kann die Installation bestehen und bei einer speicherintensiven Aufgabe scheitern.
| Bereich | Aussage der Konfiguration | Erforderlicher Beleg | Deine Prüfung |
|---|---|---|---|
| Android-Build | Das Projekt deklariert minSdk 31. | Installation des konkreten Pakets auf dem konkreten OS-Build. | Android-Version und Ergebnis notieren. |
| Modell | Name oder Dateigröße zeigen nur einen Teil des Setups. | Datei-ID, Laufzeit, Ladeergebnis und Speicherbeobachtung. | Datei erfassen und Initialisierung prüfen. |
| Geräteressourcen | RAM, Speicher und Chipname sind keine Aufgabenergebnisse. | Beobachteter Speicher, Fehler und anhaltendes Verhalten. | Lauf und Hintergrundbedingungen messen. |
| Nutzerablauf | Eine verfügbare API beweist keine vollständige Funktion. | Neue Eingabe durchläuft alle Schritte und erfüllt Kriterien. | Ablauf samt Erholung wiederholen. |
Der Umfang des Urteils muss zum Umfang der Belege passen. Ein Gerät und ein Szenario belegen nur diesen Lauf. Eine allgemeine Liste erfordert wiederholbare Tests mit benannten Konfigurationen, Rohdaten und einer veröffentlichten Abnahmeregel.
Nein. Es ist die minimale API-Ebene des Builds. Das zertifiziert weder jedes Telefon noch Modellspeicher, Beschleuniger oder Aufgabenerfolg. Prüfe das konkrete Paket und Gerät im vorgesehenen Ablauf.
Diese Seite nennt keinen Zahlenwert, weil keine validierten Einzelgerätedaten vorliegen. Laufzeitpuffer, Ein- und Ausgabegröße, andere Apps und das Betriebssystem beeinflussen den Bedarf. Miss den Spitzenwert mit dem konkreten Build und der konkreten Aufgabe.
Eine Chipfamiliengrenze wird hier nicht behauptet. Der Name beweist weder die Nutzung des Beschleunigers noch die Qualität der Aufgabe. Prüfe Artefakt und Laufzeit auf deinem Gerät.
Eine allgemeingültige Zeit gibt es hier nicht. Modell, App, Laufzeit, Beschleuniger, Ein- und Ausgabe und Gerätezustand wirken sich aus. Lege vorab eine Grenze fest und veröffentliche Wiederholungen samt Bedingungen.
Für jede Konfiguration: genaues Telefon und OS-Build, App-Build, Modellartefakt, Laufzeit, Aufgabe, Messmethode, Wiederholungen, Fehler und Bestehensregel. Umfang und Datum nennen, Fehlversuche behalten und nach Änderungen erneut prüfen.
Ein Erfolg belegt nur, dass dieser Build, dieses Artefakt, Telefon, System und diese Aufgabe den protokollierten Ablauf an diesem Datum geschafft haben. Bei Änderungen erneut prüfen. Ein genau beschriebener Fehler ist nützlicher als ein unbelegtes Pauschalurteil.
So funktioniert On-Device-KI · Kameraaufgabe unter schwierigen Bedingungen
Faktenprüfung: Cove-Redaktion, 2026-09-27. Die chinesische Prüfung durch den Eigentümer steht noch aus; der Text wird nicht als freigegeben dargestellt.
