Migration für Android

Gradle-Importe aktualisieren

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

Vision APIs

Bündelte Modelle werden als Teil Ihrer Anwendung bereitgestellt. Dünne Modelle müssen heruntergeladen werden. Einige APIs sind sowohl im Bündel als auch im Thin Client-Format verfügbar, andere nur in einer der beiden Formen:

Aktualisieren Sie die Abhängigkeiten für die ML Kit-Android-Bibliotheken in der Gradle-Datei Ihres Moduls (auf App-Ebene, in der Regel app/build.gradle) gemäß den folgenden Tabellen:

Sets

Dünne Modelle

AutoMLVision Edge

Natural Language APIs

Bündelte Modelle werden als Teil Ihrer Anwendung bereitgestellt. Dünne Modelle müssen heruntergeladen werden:

Aktualisieren Sie die Abhängigkeiten für die ML Kit-Android-Bibliotheken in der Gradle-Datei Ihres Moduls (auf App-Ebene, in der Regel app/build.gradle) gemäß den folgenden Tabellen:

Sets

Dünne Modelle

Kursnamen aktualisieren

Wenn Ihr Kurs in dieser Tabelle aufgeführt ist, nehmen Sie die angegebene Änderung vor:

Für andere Kurse gelten folgende Regeln:

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

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

Methodennamen aktualisieren

Es sind nur geringfügige Codeänderungen erforderlich:

• Die Instanziierung von Detector/Scanner/Labeler/Translator… wurde geändert. Jedes Element hat jetzt einen eigenen Einstiegspunkt. Beispiele: BarcodeScanning, TextRecognition, ImageLabeling, Translation…. Aufrufe des Firebase-Dienstes getInstance() werden durch Aufrufe der Methode getClient() des Einstiegspunkts der Funktion ersetzt.
• Die Standardinstanziierung für TextRecognizer wurde entfernt, da wir zusätzliche Bibliotheken für die Erkennung anderer Schriftsysteme wie Chinesisch und Koreanisch eingeführt haben. Wenn Sie die Standardoptionen mit dem Texterkennungsmodell für lateinische Schrift 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 die Standardoptionen mit dem Basismodell in ImageLabeling verwenden möchten, deklarieren Sie bitte eine Abhängigkeit von com.google.mlkit:image-labeling und verwenden Sie ImageLabeling.getClient(ImageLabelerOptions.DEFAULT_OPTIONS) in Java.
• Alle Handles (Detektor/Scanner/Labeler/Übersetzer usw.) können geschlossen werden. Die Methode close() muss aufgerufen werden, wenn diese Objekte nicht mehr verwendet werden. Wenn Sie sie in einem Fragment oder einer AppCompatActivity verwenden, können Sie einfach LifecycleOwner.getLifecycle() auf dem Fragment oder der AppCompatActivity aufrufen und dann Lifecycle.addObserver.
• processImage() und detectInImage() in den Vision APIs wurden aus Gründen der Einheitlichkeit in process() umbenannt.
• In den Natural Language APIs wird jetzt der Begriff „Sprach-Tag“ (wie im BCP 47-Standard definiert) anstelle von „Sprachcode“ verwendet.
• Die Getter-Methoden in den Klassen „xxxOptions“ wurden entfernt.
• Die Methode „getBitmap()“ in der Klasse „InputImage“ (ersetzt FirebaseVisionImage) wird nicht mehr als Teil der öffentlichen Schnittstelle unterstützt. Weitere Informationen finden Sie unter BitmapUtils.java im Beispiel für den ML Kit-Schnellstart.
• FirebaseVisionImageMetadata wurde entfernt. Sie können Bildmetadaten wie Breite, Höhe, Drehung und Format einfach an die Konstruktionsmethoden von InputImages übergeben.

Hier 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 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 bereitzustellen:

• Über die Google Play-Dienste (auch „dünn“ genannt, empfohlen): Dadurch wird die App-Größe reduziert und das Modell wird zwischen Anwendungen 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 als „bündelt“ bezeichnet: Dadurch wird die App-Größe erhöht, aber das Modell kann sofort verwendet werden.

Die beiden Implementierungen unterscheiden sich geringfügig. Die „kombinierte“ Version bietet eine Reihe von Verbesserungen gegenüber der „schmalen“ Version. Weitere Informationen zu diesen Unterschieden finden Sie in den Richtlinien für die Barcode-Scan-API.

Gesichtserkennung

Für die Face Detection API gibt es zwei Möglichkeiten, die Modelle bereitzustellen:

• Über die Google Play-Dienste (auch „dünn“ genannt, empfohlen): Dadurch wird die App-Größe reduziert und das Modell wird zwischen Anwendungen 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 als „bündelt“ bezeichnet: Dadurch wird die Downloadgröße der App erhöht, aber das Modell kann sofort verwendet werden.

Das Verhalten der Implementierungen ist identisch.

Translation

• In TranslateLanguage werden jetzt lesbare Namen für Konstanten (z. B. ENGLISH) anstelle von Sprach-Tags (z. B. EN) verwendet. Außerdem werden sie jetzt als @StringDef statt als @IntDef deklariert 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. Sie können weiterhin die Option „Geräteladegerät“ verwenden. Wenn Sie ein komplexeres Verhalten wünschen, können Sie den Aufruf von RemoteModelManager.download mithilfe Ihrer eigenen Logik verzögern.

AutoML-Bildbeschriftung

Wenn Ihre App die Downloadbedingung „Gerät inaktiv“ verwendet, beachten Sie, dass diese Option entfernt wurde und nicht mehr verwendet werden kann. Sie können weiterhin die Option „Geräteladegerät“ verwenden.

Wenn du ein komplexeres Verhalten möchtest, kannst du den Aufruf von RemoteModelManager.download mit deiner eigenen Logik verzögern.

Objekterkennung und -tracking

Wenn Ihre App die Objekterkennung mit grober Klassifizierung verwendet, beachten Sie, dass mit dem neuen SDK die Art und Weise geändert wurde, wie die Klassifizierungskategorie für erkannte Objekte zurückgegeben wird.

Die Klassifizierungskategorie wird als Instanz von DetectedObject.Label anstelle einer Ganzzahl zurückgegeben. Die Klasse PredefinedCategory enthält alle möglichen Kategorien für den groben Klassifikator.

Hier 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 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, geben wir einfach kein Label zurück.

Firebase-Abhängigkeiten entfernen (optional)

Dieser Schritt gilt nur, wenn folgende Bedingungen erfüllt sind:

• Firebase ML Kit ist die einzige Firebase-Komponente, die Sie verwenden.
• Sie verwenden nur On-Device-APIs.
• 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 (App-Ebene) Ihrer App löschen.
• Ersetzen Sie das Google-Dienste-Gradle-Plug-in in der Gradle-Datei Ihres Moduls (auf App-Ebene, in der Regel „app/build.gradle“) durch das Plug-in „Strict Version Matcher“:

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 Google-Dienste-Gradle-Plug-ins in der Gradle-Datei (build.gradle) Ihres Projekts (Stammebene) durch den des Strict Version Matcher-Plug-ins:

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

Wenn Probleme auftreten, findest du auf unserer Community-Seite Informationen dazu, wie du dich mit uns in Verbindung setzen kannst.