Google Play Billing ITEM_ALREADY_OWNED ist der Antwortcode 7. Er bedeutet, dass Google Play das an launchBillingFlow() übergebene Abo oder Einmalkaufprodukt als bereits erworben einstuft. Veraltete Kaufinformationen auf dem Gerät können ebenfalls dazu führen, dass die Antwort unerwartet erscheint. Bei Android-Apps, die die Google Play Billing Library verwenden, besteht die sicherste erste Maßnahme darin, queryPurchasesAsync() für den zutreffenden Produkttyp aufzurufen. Gewähren Sie nicht allein aufgrund von Code 7 eine Berechtigung und starten Sie auch keinen erneuten Versuch.

Was ITEM_ALREADY_OWNED mit Antwortcode 7 bedeutet

BillingClient.BillingResponseCode.ITEM_ALREADY_OWNED hat den numerischen Wert 7. Dies bestätigt die API-Referenz zu BillingResponseCode. Der Code kann über BillingResult zurückgegeben werden, wenn launchBillingFlow() für ein Abo oder Einmalkaufprodukt aufgerufen wird, das dem Google-Play-Konto bereits gehört.

Es gibt zwei zentrale Diagnosezweige:

  • Tatsächlicher Besitz: Play meldet einen aktiven Kauf, den die App erkennen muss und nicht doppelt bereitstellen darf.
  • Veralteter Play-Kaufstatus: Die geräteseitigen Kaufinformationen entsprechen noch nicht dem aktuellen Backend-Status. Deshalb erscheint Code 7, obwohl das Produkt nach einer aktualisierten Abfrage nicht als erworben zurückgegeben wird.

Möglicherweise bietet die App außerdem ein bereits erworbenes Produkt an. Auch fehlerhafte Parameter für launchBillingFlow() können diesen Fehler auslösen. Die Antwort allein beweist keinen aktuellen Status PURCHASED. Treffen Sie diese Entscheidung anhand des Ergebnisses der Kaufabfrage und der Berechtigungsdaten der App.

Käufe abfragen, um tatsächlichen Besitz von einem veralteten Play-Status zu unterscheiden

Wann dies zutrifft: Führen Sie diesen Schritt zuerst aus, nachdem ITEM_ALREADY_OWNED in einem Kaufvorgang für ein Abo oder Einmalkaufprodukt zurückgegeben wurde.

Voraussetzungen: BillingClient muss verbunden sein, und die App muss wissen, ob sie ein Abo oder Einmalkaufprodukt abfragt. Verwenden Sie bei Billing Library 8.x die aktuelle Form queryPurchasesAsync(QueryPurchaseParams, ...). Die ältere Überladung mit einer Zeichenfolge wurde entfernt.

  1. Rufen Sie nach dem Ergebnis mit Code 7 queryPurchasesAsync() auf. Die API-Referenz zu BillingClient beschreibt die aktuelle Client-API.
  2. Prüfen Sie die aktualisierten Käufe auf das Produkt, das am fehlgeschlagenen Kaufvorgang beteiligt war.
  3. Wenn das Produkt als erworben zurückgegeben wird, prüfen Sie seinen Kaufstatus und gleichen Sie ihn mit der bestehenden Berechtigung ab. Bieten Sie das Produkt nicht länger zum Kauf an.
  4. Wenn das Produkt im aktualisierten Ergebnis nicht als erworben erscheint, verwenden Sie den unten beschriebenen Zweig für einen veralteten Cache und lassen Sie höchstens einen erneuten Versuch zu.

Erwartetes Ergebnis: Die App erkennt entweder einen bestätigten, vorhandenen Kauf oder einen aktualisierten Status, bei dem das Produkt nicht als erworben gemeldet wird.

Risiko und Rücknahme: Das Risiko ist gering, da hierbei nur Daten gelesen und abgeglichen werden. Lokale Datensätze müssen nicht gelöscht, und die Daten des Google Play Store müssen nicht bereinigt werden. Wenn der Besitz bestätigt wird, beenden Sie den Kaufvorgang und jeden ausstehenden erneuten Versuch.

Play-Besitz mit dem Berechtigungsstatus der App abgleichen

Wann dies zutrifft: Verwenden Sie dieses Verfahren, wenn die aktualisierte Kaufabfrage den Besitz bestätigt oder wenn die Kaufoberfläche und die clientseitigen beziehungsweise im Backend gespeicherten Berechtigungsdaten der App voneinander abweichen.

Voraussetzungen: Der App müssen das aktualisierte Play-Kaufergebnis und die clientseitigen oder im Backend gespeicherten Berechtigungsdaten vorliegen, die sie üblicherweise verwendet. Einzelheiten der Backend-Implementierung sind app-spezifisch und müssen anhand des eigenen sicheren Verarbeitungsdesigns der App geprüft werden.

  1. Vergleichen Sie den aktualisierten Play-Kauf mit den aktuellen clientseitigen und im Backend gespeicherten Berechtigungsdaten der App.
  2. Gewähren oder behalten Sie den Zugriff erst nach Prüfung des zutreffenden Kaufstatus bei. Gestalten Sie die Bereitstellung idempotent, damit derselbe Kauf nicht zweimal gewährt wird, wenn er sowohl vom Client als auch bei der Backend-Verarbeitung erkannt wird.
  3. Blenden Sie Kaufoptionen für bereits erworbene Abos und nicht verbrauchbare Einmalkaufprodukte aus oder deaktivieren Sie sie.
  4. Halten Sie die Kaufoption für Verbrauchsprodukte so lange deaktiviert, bis der Verbrauch bestätigt wurde.
  5. Halten Sie den angezeigten Besitzstatus sowohl mit Play als auch mit dem maßgeblichen Berechtigungsstatus der App synchron.

Erwartetes Ergebnis: Ein tatsächlich erworbenes Produkt besitzt die richtige Berechtigung und wird nicht erneut angeboten. Ein nicht erworbenes Produkt wird dagegen nicht fälschlicherweise als gekauft behandelt.

Risiko und Rücknahme: Das Risiko ist gering, solange nicht allein aufgrund von Code 7 eine Berechtigung gewährt wird. Aktivieren Sie ein Produkt erst wieder, wenn die entsprechende Berechtigung nicht mehr aktiv ist oder bei einem Verbrauchsprodukt der Verbrauch bestätigt wurde. Löschen Sie lokale Berechtigungsdaten nicht als Ersatz für den Abgleich.

Wann nach ITEM_ALREADY_OWNED ein erneuter Versuch zulässig ist

Wann dies zutrifft: Wiederholen Sie den Vorgang nur, wenn queryPurchasesAsync() den Kaufstatus aktualisiert hat und das Produkt im Ergebnis weiterhin nicht als erworben erscheint.

Voraussetzungen: Die Kaufabfrage muss abgeschlossen sein, der Besitz darf nicht bestätigt worden sein, und die App darf aufgrund der Fehlerantwort keine Berechtigung gewährt haben.

  1. Behandeln Sie die erste Antwort mit Code 7 nur in diesem Zweig ohne bestätigten Besitz als mögliches Signal zur Cache-Aktualisierung.
  2. Vergewissern Sie sich, dass das Produkt im aktualisierten Kaufergebnis nicht als erworben enthalten ist.
  3. Wiederholen Sie launchBillingFlow() genau einmal mit einer einfachen Wiederholungslogik.
  4. Beenden Sie den Vorgang, wenn der Besitz bestätigt wird oder dieser einzelne erneute Versuch den Kaufvorgang nicht wiederherstellt.

Erwartetes Ergebnis: Ein Kauf, der nur aufgrund veralteter Geräteinformationen blockiert war, kann nach der Aktualisierung fortgesetzt werden. Die meisten Antworten mit Code 7 sollten nicht als vorübergehender Fehler behandelt werden.

Risiko und Rücknahme: Das Risiko ist gering, wenn der erneute Versuch auf die dokumentierte Bedingung beschränkt bleibt. Eine destruktive Rücknahme ist nicht erforderlich. Beenden Sie den Vorgang sofort, wenn der Besitz bestätigt wird. Erstellen Sie keine sofortige, wiederholte, exponentielle oder unbegrenzte Wiederholungsschleife. Diese Abfolge entspricht den Google-Hinweisen zur Fehlerbehebung bei ITEM_ALREADY_OWNED.

Kauf je nach Produkttyp bestätigen oder verbrauchen

Bestätigung und Verbrauch sind nicht austauschbar. Der richtige Vorgang hängt davon ab, ob es sich um ein Abo, ein nicht verbrauchbares Einmalkaufprodukt oder ein verbrauchbares Einmalkaufprodukt handelt.

Abos und nicht verbrauchbare Produkte bestätigen

Wann dies zutrifft: Verwenden Sie die Bestätigung für Abos und nicht verbrauchbare Produkte, die im Besitz des Nutzers bleiben sollen.

Voraussetzungen: Der Kaufstatus lautet PURCHASED, die zugehörige Berechtigung wurde gewährt, und der Kauf wurde noch nicht bestätigt.

  1. Prüfen Sie den Status PURCHASED.
  2. Gewähren Sie die Berechtigung, ohne eine bereits erfolgte Bereitstellung zu duplizieren.
  3. Bestätigen Sie den Kauf so bald wie möglich, nachdem die Berechtigung gewährt wurde.
  4. Verwenden Sie acknowledgePurchase() für eine Verarbeitung ausschließlich auf dem Client oder die Google Play Developer API in einem sicheren Backend.

Erwartetes Ergebnis: Das bestätigte Abo oder nicht verbrauchbare Produkt bleibt im Besitz des Nutzers und wird nicht mehr zum Kauf angeboten.

Risiko und Rücknahme: Das Risiko ist gering. Wenn der Kauf bereits bestätigt wurde, führen Sie keine weitere Bestätigung aus. Verbrauchen Sie niemals ein Abo oder nicht verbrauchbares Produkt, um Code 7 zu beseitigen.

Verbrauchsprodukte vor einem erneuten Kauf verbrauchen

Wann dies zutrifft: Verwenden Sie den Verbrauch nur für ein Produkt, das ausdrücklich für wiederholte Käufe vorgesehen ist.

Voraussetzungen: Der Katalogartikel muss ein Verbrauchsprodukt sein, und die Leistung für den aktuellen Kauf muss bereits gewährt worden sein.

  1. Prüfen Sie den Kauf und gewähren Sie die verbrauchbare Leistung.
  2. Verbrauchen Sie den Kauf mit consumeAsync() bei einer Verarbeitung ausschließlich auf dem Client oder mit Purchases.products:consume in einem sicheren Backend.
  3. Bestätigen Sie den Verbrauch, bevor das Produkt wieder als kaufbar angezeigt wird.
  4. Verhindern Sie eine doppelte Bereitstellung, wenn derselbe Kauf mehrmals erkannt wird.

Erwartetes Ergebnis: Der Nutzer erhält die aktuelle verbrauchbare Leistung. Das Produkt kann erst nach dem Verbrauch erneut gekauft werden.

Risiko und Rücknahme: Das Risiko ist gering, wenn das Produkt im Katalog richtig eingestuft ist. Der Verbrauch darf nicht vor der Bereitstellung erfolgen. Wenn der Kauf bereits verbraucht wurde, darf die Leistung nicht erneut bereitgestellt werden, nur weil ein Besitzergebnis nochmals erscheint.

Fehlerbehebung prüfen, ohne Zugriff doppelt zu gewähren

Wann dies zutrifft: Verwenden Sie dieses Verfahren in einer Google-Play-Testumgebung, nachdem Sie Besitzabfragen, den Berechtigungsabgleich, die Produktfilterung, die bedingte Wiederholung und den richtigen Bestätigungs- oder Verbrauchspfad implementiert haben.

Voraussetzungen: Auf dem Android-Gerät muss ein Lizenztesterkonto eingerichtet sein. Die App muss über dieses Testerkonto installiert worden sein, und der Tester muss die Play-Kaufdialoge und den Berechtigungsstatus der App beobachten können.

  1. Führen Sie mit dem Lizenztesterkonto einen Testkauf durch.
  2. Prüfen Sie, ob die aktualisierte Kaufabfrage, die App-Berechtigung, der Backend-Datensatz und die Kaufoberfläche übereinstimmen.
  3. Vergewissern Sie sich bei einem Abo oder nicht verbrauchbaren Produkt, dass die Bestätigung innerhalb des dreiminütigen Zeitfensters für Lizenztester erfolgt. Andernfalls wird der Testkauf erstattet.
  4. Prüfen Sie bei einem Verbrauchsprodukt, ob die Bereitstellung vor dem Verbrauch erfolgt und der Artikel erst danach wieder zum Kauf angeboten wird.
  5. Verwenden Sie Play Billing Lab, wenn beschleunigte Aboverlängerungen oder Statusänderungen erforderlich sind.
  6. Wiederholen Sie die normale Aktualisierung des Kaufstatus in der App und prüfen Sie, ob doppelte Callbacks oder eine wiederholte Backend-Verarbeitung die Berechtigung nicht zweimal gewähren.
  7. Vergewissern Sie sich, dass ein bereits erworbenes Abo oder nicht verbrauchbares Produkt keine aktive Kaufoption mehr besitzt und die Wiederholungslogik nach dem dokumentierten einzelnen Versuch endet.

Erwartetes Ergebnis: Besitz, Berechtigung, Bestätigung oder Verbrauch und der Status der Kaufoberfläche bleiben konsistent, ohne Leistungen doppelt bereitzustellen.

Risiko und Rücknahme: In der vorgesehenen Testumgebung ist das Risiko gering. Kündigen Sie den Testkauf oder lassen Sie ihn gemäß den geltenden Testregeln ablaufen beziehungsweise erstatten. Verwenden Sie keine echten Kundenkäufe für destruktive Tests.

Verwenden Sie weder das Löschen der Play-Store-Daten noch das Löschen lokaler Berechtigungen, wiederholte Versuche oder einen unkontrollierten Verbrauch als primäre Fehlerbehebung. Diese Maßnahmen belegen den Besitz nicht zuverlässig und können einen Fehler beim Berechtigungsabgleich verdecken.

Versions- und Implementierungsgrenze: Dieser Leitfaden verwendet Billing Library 8.x und die aktuell unterstützte API-Terminologie. Der genaue Zeitpunkt der Aktualisierung eines veralteten Caches unterscheidet sich je nach Gerät und Play-Store-Version. Die Produkteinstufung und der Backend-Abgleich bleiben app-spezifisch und müssen auf Implementierungsebene geprüft werden.