Migration für Android

Gradle-Importe aktualisieren

Das neue SDK erfordert nur eine Abhängigkeit für jede ML Kit API. Sie müssen keine gängige Bibliotheken wie firebase-ml-vision oder firebase-ml-natural-language. ML Kit verwendet den Namespace com.google.android.gms für Bibliotheken, die von Google Play-Diensten abhängen.

Vision-APIs

Gebündelte Modelle werden als Teil Ihrer Anwendung bereitgestellt. Dünne Modelle müssen heruntergeladen werden. Einige APIs sind sowohl gebündelt als auch dünn, andere nur in einer Form verfügbar. oder andere:

Aktualisieren Sie die Abhängigkeiten für die ML Kit-Android-Bibliotheken in Ihrem Modul (app- Level) Gradle-Datei (in der Regel app/build.gradle) gemäß den folgenden Tabellen:

Gebündelte Modelle

Dünne Modelle

AutoMLVision Edge

Natural Language-APIs

Gebündelte Modelle werden als Teil Ihrer Anwendung bereitgestellt. Schmale Modelle müssen heruntergeladen werden:

Aktualisieren Sie die Abhängigkeiten für die ML Kit-Android-Bibliotheken in Ihrem Modul (app- Level) Gradle-Datei (in der Regel app/build.gradle) gemäß den folgenden Tabellen:

Gebündelte Modelle

Dünne Modelle

Kursnamen aktualisieren

Wenn Ihr Kurs in dieser Tabelle angezeigt wird, nehmen Sie die entsprechende Änderung vor:

Halten Sie sich bei anderen Kursen an diese Regeln:

• Entfernen Sie das Präfix FirebaseVision aus dem Klassennamen.
• Entfernen Sie andere Präfixe, die mit dem Präfix Firebase beginnen, aus dem Klassennamen.

Ersetzen Sie in Paketnamen außerdem das Präfix com.google.firebase.ml. mit com.google.mlkit.

Methodennamen aktualisieren

Es gibt nur minimale Änderungen am Code:

• Die Instanziierung von Detektor/Scanner/Labeler/Übersetzer... wurde geändert. Jede Funktion hat jetzt einen eigenen Einstiegspunkt. Beispiele: BarcodeScanning, Texterkennung, ImageLabeling, Übersetzung... Aufrufe des Firebase-Dienstes getInstance() werden durch Aufrufe der getClient()-Methode des Feature-Einstiegspunkts ersetzt.
• Die Standardinstanziierung für TextErkennung wurde entfernt, da wir zusätzliche Bibliotheken zur Erkennung anderer Skripte wie Chinesisch und Koreanisch eingeführt haben. Wenn Sie mit dem Texterkennungsmodell mit lateinischer Schrift Standardoptionen verwenden möchten, deklarieren Sie eine Abhängigkeit von com.google.android.gms:play-services-mlkit-text-recognition und verwenden Sie TextRecognition.getClient(TextRecognizerOptions.DEFAULT_OPTIONS).
• Die Standardinstanziierung für ImageLabeler und ObjectDetector wurde entfernt, da wir die Unterstützung benutzerdefinierter Modelle für diese beiden Funktionen eingeführt haben. Wenn Sie beispielsweise in ImageLabeling Standardoptionen mit dem Basismodell verwenden möchten, deklarieren Sie eine Abhängigkeit von com.google.mlkit:image-labeling und verwenden Sie ImageLabeling.getClient(ImageLabelerOptions.DEFAULT_OPTIONS) in Java.
• Alle Griffe (Detektoren, Labelersteller, Übersetzer usw.) lassen sich schließen. Achten Sie darauf, dass die Methode close() aufgerufen wird, wenn diese Objekte nicht mehr verwendet werden. Wenn Sie sie in einem Fragment oder einer AppCompatActivity verwenden, können Sie dies einfach tun, indem Sie LifecycleOwner.getLifecycle() für das Fragment oder die AppCompatActivity aufrufen und dann Lifecycle.addObserver aufrufen.
• processImage() und detectInImage() in den Vision APIs wurden aus Konsistenzgründen in process() umbenannt .
• Die Natural Language APIs verwenden jetzt den Begriff „Sprachcode“ (gemäß der Definition im BCP-47-Standard) anstelle von „Sprachcode“.
• Getter-Methoden in xxxOptions-Klassen wurden entfernt.
• Die getBitmap()-Methode in der InputImage-Klasse(ersetzt FirebaseVisionImage) wird als Teil der öffentlichen Schnittstelle nicht mehr unterstützt. Unter BitmapUtils.java im ML Kit-Schnellstartbeispiel finden Sie Informationen zur Konvertierung von Bitmaps aus verschiedenen Eingaben.
• FirebaseVisionImageMetadata wurde entfernt. Sie können jetzt einfach Bildmetadaten wie Breite, Höhe, RotationDegrees und das Format an die Konstruktionsmethoden von InputImages übergeben.

Hier sind einige Beispiele für alte und neue Kotlin-Methoden:

// Construct image labeler with base model and default options.
val imageLabeler = FirebaseVision.getInstance().onDeviceImageLabeler

// Construct object detector with base model and default options.
val objectDetector = FirebaseVision.getInstance().onDeviceObjectDetector

// Construct face detector with given options
val faceDetector = FirebaseVision.getInstance().getVisionFaceDetector(options)

// Construct image labeler with local AutoML model
val localModel =
    FirebaseAutoMLLocalModel.Builder()
      .setAssetFilePath("automl/manifest.json")
      .build()
val autoMLImageLabeler =
    FirebaseVision.getInstance()
      .getOnDeviceAutoMLImageLabeler(
          FirebaseVisionOnDeviceAutoMLImageLabelerOptions.Builder(localModel)
            .setConfidenceThreshold(0.3F)
            .build()
    )

// Construct image labeler with base model and default options.
val imageLabeler = ImageLabeling.getClient(ImageLabelerOptions.DEFAULT_OPTIONS)
// Optional: add life cycle observer
lifecycle.addObserver(imageLabeler)

// Construct object detector with base model and default options.
val objectDetector = ObjectDetection.getClient(ObjectDetectorOptions.DEFAULT_OPTIONS)

// Construct face detector with given options
val faceDetector = FaceDetection.getClient(options)

// Construct image labeler with local AutoML model
val localModel =
  LocalModel.Builder()
    .setAssetManifestFilePath("automl/manifest.json")
    .build()
val autoMLImageLabeler =
  ImageLabeling.getClient(
    CustomImageLabelerOptions.Builder(localModel)
    .setConfidenceThreshold(0.3F).build())
  

Hier sind einige Beispiele für alte und neue Java-Methoden:

// Construct image labeler with base model and default options.
FirebaseVisionImageLabeler imagelLabeler =
     FirebaseVision.getInstance().getOnDeviceImageLabeler();

// Construct object detector with base model and default options.
FirebaseVisionObjectDetector objectDetector =
     FirebaseVision.getInstance().getOnDeviceObjectDetector();

// Construct face detector with given options
FirebaseVisionFaceDetector faceDetector =
     FirebaseVision.getInstance().getVisionFaceDetector(options);

// Construct image labeler with local AutoML model
FirebaseAutoMLLocalModel localModel =
    new FirebaseAutoMLLocalModel.Builder()
      .setAssetFilePath("automl/manifest.json")
      .build();
FirebaseVisionImageLabeler autoMLImageLabeler =
    FirebaseVision.getInstance()
      .getOnDeviceAutoMLImageLabeler(
          FirebaseVisionOnDeviceAutoMLImageLabelerOptions.Builder(localModel)
            .setConfidenceThreshold(0.3F)
            .build());

// Construct image labeler with base model and default options.
ImageLabeler imageLabeler = ImageLabeling.getClient(ImageLabelerOptions.DEFAULT_OPTIONS);
// Optional: add life cycle observer
getLifecycle().addObserver(imageLabeler);

// Construct object detector with base model and default options.
ObjectDetector objectDetector = ObjectDetection.getClient(ObjectDetectorOptions.DEFAULT_OPTIONS);

// Construct face detector with given options
FaceDetector faceDetector = FaceDetection.getClient(options);

// Construct image labeler with local AutoML model
LocalModel localModel =
  new LocalModel.Builder()
    .setAssetManifestFilePath("automl/manifest.json")
    .build();
ImageLabeler autoMLImageLabeler =
  ImageLabeling.getClient(
    new CustomImageLabelerOptions.Builder(localModel)
    .setConfidenceThreshold(0.3F).build());
  

API-spezifische Änderungen

Barcode scannen

Für die Barcode Scanning API gibt es jetzt zwei Möglichkeiten, die Modelle zu übermitteln:

• Über die Google Play-Dienste, auch als „dünn“ bezeichnet (empfohlen): Dadurch wird die App-Größe reduziert und das Modell wird von mehreren Apps gemeinsam genutzt. Entwickler müssen jedoch dafür sorgen, dass das Modell heruntergeladen wird, bevor es zum ersten Mal verwendet wird.
• Mit dem APK Ihrer App, auch „gebündelt“ genannt, wird die App-Größe erhöht, aber das Modell kann sofort verwendet werden.

Die beiden Implementierungen unterscheiden sich geringfügig. Die gebündelte Version weist gegenüber der „dünnen“ Version eine Reihe von Verbesserungen auf. Details zu diesen Unterschieden finden Sie in den Richtlinien für die Barcode Scanning API.

Gesichtserkennung

Für die Gesichtserkennungs-API gibt es zwei Möglichkeiten, die Modelle zu liefern:

• Über die Google Play-Dienste, auch als „dünn“ bezeichnet (empfohlen): Dadurch wird die App-Größe reduziert und das Modell wird von mehreren Apps gemeinsam genutzt. Entwickler müssen jedoch dafür sorgen, dass das Modell heruntergeladen wird, bevor es zum ersten Mal verwendet wird.
• Mit dem APK Ihrer App, auch „gebündelt“ genannt, erhöht sich die Downloadgröße der App, aber das Modell kann sofort genutzt werden.

Das Verhalten der Implementierungen ist identisch.

Translation

• TranslateLanguage verwendet jetzt lesbare Namen für seine Konstanten (z.B. ENGLISH) anstelle von Sprach-Tags (EN). Sie sind auch jetzt @StringDef anstelle von @IntDef und der Wert der Konstante ist das entsprechende BCP 47-Sprach-Tag.

• Wenn Ihre App die Downloadbedingung „Gerät inaktiv“ verwendet, beachten Sie, dass diese Option entfernt wurde und nicht mehr verwendet werden kann. Du kannst weiterhin die Option „Gerät aufladen“ verwenden. Wenn Sie ein komplexeres Verhalten wünschen, können Sie den Aufruf von RemoteModelManager.download im Hintergrund Ihrer eigenen Logik verzögern.

AutoML Image Labeling

Wenn Ihre App die Downloadbedingung „Gerät inaktiv“ verwendet, beachten Sie, Die Option wurde entfernt und kann nicht mehr verwendet werden. Sie können die Methode Option zum Aufladen des Geräts.

Wenn Sie eine komplexere Funktionsweise wünschen, können Sie den Aufruf verzögern. RemoteModelManager.download hinter Ihrer eigenen Logik.

Objekterkennung und -tracking

Wenn Ihre App die Objekterkennung mit grober Klassifizierung verwendet, beachten Sie, Beim neuen SDK wurde die Rückgabe der Klassifizierungskategorie für erkannte Objekte.

Die Klassifizierungskategorie wird als Instanz von DetectedObject.Label anstelle einer Ganzzahl. Alle möglichen Kategorien für die grobe Klassifikatoren sind in der PredefinedCategory-Klasse enthalten.

Hier sehen Sie ein Beispiel für den alten und den neuen Kotlin-Code:

if (object.classificationCategory == FirebaseVisionObject.CATEGORY_FOOD) {
    ...
}

if (!object.labels.isEmpty() && object.labels[0].text == PredefinedCategory.FOOD) {
    ...
}
// or
if (!object.labels.isEmpty() && object.labels[0].index == PredefinedCategory.FOOD_INDEX) {
    ...
}

Hier ist ein Beispiel für den alten und den neuen Java-Code:

if (object.getClassificationCategory() == FirebaseVisionObject.CATEGORY_FOOD) {
    ...
}

if (!object.getLabels().isEmpty()
    && object.getLabels().get(0).getText().equals(PredefinedCategory.FOOD)) {
    ...
}
// or
if (!object.getLabels().isEmpty()
    && object.getLabels().get(0).getIndex() == PredefinedCategory.FOOD_INDEX) {
    ...
}

Die Kategorie „Unbekannt“ wurde entfernt. Wenn die Konfidenz der Klassifizierung eines Objekts niedrig ist, wird kein Label zurückgegeben.

Firebase-Abhängigkeiten entfernen (optional)

Dieser Schritt ist nur möglich, wenn die folgenden Bedingungen erfüllt sind:

• Firebase ML Kit ist die einzige Firebase-Komponente, die Sie verwenden.
• Sie verwenden nur APIs auf dem Gerät.
• Sie verwenden keine Modellbereitstellung.

In diesem Fall können Sie die Firebase-Abhängigkeiten nach der Migration entfernen. Gehen Sie so vor:

• Entfernen Sie die Firebase-Konfigurationsdatei, indem Sie die Konfigurationsdatei google-services.json im Modulverzeichnis (auf App-Ebene) Ihrer App löschen.
• Ersetzen Sie das Gradle-Plug-in für Google-Dienste in der Gradle-Datei Ihres Moduls (in der Regel app/build.gradle) durch das Plug-in "Strict Version Matcher" auf App-Ebene:

apply plugin: 'com.android.application'
apply plugin: 'com.google.gms.google-services'  // Google Services plugin

android {
  // …
}

apply plugin: 'com.android.application'
apply plugin: 'com.google.android.gms.strict-version-matcher-plugin'

android {
  // …
}

• Ersetzen Sie den classpath des Gradle-Plug-ins für Google-Dienste in der Gradle-Datei Ihres Projekts (auf Stammebene) (build.gradle) durch den Klassenpfad für das Plug-in "Strict Version Matcher":

buildscript {
  dependencies {
    // ...

    classpath 'com.google.gms:google-services:4.3.3'  // Google Services plugin
  }
}

buildscript {
  dependencies {
    // ...

    classpath 'com.google.android.gms:strict-version-matcher-plugin:1.2.1'
  }
}

Löschen Sie Ihre Firebase-App in der Firebase Console gemäß der Anleitung auf der Firebase-Supportwebsite.

Hilfe erhalten

Solltest du Probleme haben, besuche unsere Community-Seite. Dort findest du über die Kanäle, über die Sie mit uns Kontakt aufnehmen können.