Die Geschichte der Release-Arbeit der Anwendung, die Google nicht erzählt

Ich arbeite an der Veröffentlichung und bin immer besorgt, daher möchte ich den Versionscode und die Versionsnamensspezifikationen zusammenfassen.

Möglicherweise stoßen fortgeschrittene Android-Benutzer nicht auf diese Probleme, wenn sie den Release-Ablauf automatisieren oder CI / CD-Tools verwenden. Diesmal dient dies jedoch dem Verständnis der Spezifikationen von GooglePlayConsole. Ich werde diese hochqualifizierten Teile nicht ansprechen, ich werde sie für Anfänger bis Fortgeschrittene schreiben: santa_tone1:

1. Veröffentlichen Sie die APK / AAB-Datei der erstellten App im Store

Laden Sie beim Veröffentlichen einer App für Benutzer die Build-Datei hoch, die an der Stelle erstellt wurde, an der die Seite "[Release Management]" -> "[App Release]" von GooglePlayConsole "Produktversionsspur" anzeigt, und veröffentlichen Sie sie. Wenn Sie dies tun, können Sie es freigeben.

Wenn es die erste Veröffentlichung ist, kann sie meiner Meinung nach problemlos veröffentlicht werden.

Im obigen Bild lautet der Versionscode "1" und der Versionsname "1.0". Dies ist mit dem in app / build.gradle festgelegten versionCode und versionName verknüpft.

Übrigens, wenn Sie zum ersten Mal auf ein Problem stoßen (Angst haben), möchten Sie die Produktversion der App aktualisieren.

2. Ich möchte die veröffentlichte kommerzielle Versionsanwendung aktualisieren

Die Einzelhandels-App sollte aus verschiedenen Gründen aktualisiert werden. Wenn Sie zu diesem Zeitpunkt versuchen, die APK / AAB-Datei zu veröffentlichen, ohne an irgendetwas zu denken, können die folgenden Probleme auftreten.

Sie sind wütend, dass Sie den Versionscode in etwas anderes als "1" ändern. Der Build mit dem Versionscode "1" wurde bereits verwendet, als die App zum ersten Mal veröffentlicht wurde. Sie können nicht mehrere Build-Dateien mit demselben Versionscode hochladen. Ändern wir nun app / build.gradle, um den Versionscode zu ändern.

.... Wie soll der Wert zu diesem Zeitpunkt geändert werden? Würde sich diese Frage zum Beispiel nicht stellen?

――Da der Versionscode eine Zahl ist, ist es in Ordnung, ihn vorerst zu erhöhen? ――Ist es in Ordnung, eine große Zahl zu verwenden, wenn sie sich nicht mit dem vorhandenen Versionscode überschneidet? --Was ist "System.currentTimeMillis ()" in Java? ――Ist es in Ordnung, wenn "ein anderer Versionscode" niedriger als der vorhandene Versionscode ist? ――Ist es in Ordnung, wenn die Versionsnamen gleich sind?

Lassen Sie uns jeden einzelnen lösen.

・ Ist es in Ordnung, den Versionscode vorerst zu erhöhen, da er eine Zahl ist?

Beim Aktualisieren der App ist das Inkrementieren jederzeit in Ordnung. Wenn Sie es erhöhen, sollte niemand unglücklich sein.

・ Ist es in Ordnung, eine große Zahl zu verwenden, wenn sie sich nicht mit dem vorhandenen Versionscode überschneidet?

In u2020 / JakeWharton habe ich die folgende Beschreibung gesehen. Es kann hilfreich sein!

u2020/build.gradle

def versionMajor = 1
def versionMinor = 0
def versionPatch = 0
def versionBuild = 0

android {
    
    defaultConfig {

        versionCode versionMajor * 10000 + versionMinor * 1000 + versionPatch * 100 + versionBuild
        versionName "${versionMajor}.${versionMinor}.${versionPatch}"
    }
}

Übrigens scheint "versionCode" einen Build-Fehler zu verursachen, wenn es sich um eine Zahl mit 10 oder mehr Ziffern handelt. Es warnte mich auch, dass die Zahl zu groß eingestellt war, verwenden Sie also keine außergewöhnliche Zahl. In diesem Sinne ist es gefährlich, den Wert von "System.currentTimeMillis ()" zu verwenden: joy:

・ Ist es in Ordnung, wenn "ein anderer Versionscode" niedriger als der vorhandene Versionscode ist?

Wenn Sie versuchen, eine Build-Datei mit einem niedrigeren Versionscode als dem veröffentlichten Versionscode für den Einzelhandel zu veröffentlichen, ist der Upload erfolgreich, wenn die Build-Datei einen Versionscode enthält, der noch nie in die Google Play Console hochgeladen wurde. .. Die Veröffentlichung wird jedoch nicht erfolgreich sein. Ich erhalte folgende Fehlermeldung: Mit anderen Worten

** Versionscode höher als vorhandene Einzelhandelsversion = Benutzer kann Ziel-App aus dem Store aktualisieren **

Es scheint die Spezifikation zu sein. Selbst wenn Sie eine Version mit einem niedrigen Versionscode veröffentlichen, hat dies keinerlei Auswirkungen auf vorhandene Benutzer. Es ist also sinnlos, dies zu tun. Selbst wenn Sie eine App von Deploygate installieren und eine App mit einem niedrigeren Versionscode als die installierte App verwenden möchten, müssen Sie sie einmal deinstallieren.

・ Ist es in Ordnung, wenn die Versionsnamen identisch sind?

Der Standard-Versionsname ist "1.0". Es sieht also so aus, als müssten Sie ihn zusammen mit dem Versionscode erhöhen. In Bezug auf den Versionsnamen scheint das gleiche wie der vorhandene in Ordnung zu sein. Es kann kein Faktor bei der Entscheidung sein, ob ein Update auf der Google Play Console durchgeführt werden soll. Beispiel: ** Wenn der Versionscode mit der vorhandenen Einzelhandelsversion identisch ist, der Versionsname jedoch unterschiedlich ist, kann die Build-Datei nicht als Einzelhandelsversion aktualisiert werden. ** Der Versionscode scheint auf der Seite der Google Play Console besonders wichtig zu sein.

Darüber hinaus kann der Versionsname vor und nach der Veröffentlichung in der Google Play Console geändert werden. Wozu dient er also? .. .. Außerdem muss der Versionsname keine Zahl sein, da er als Zeichenfolge angegeben werden kann. Im Extremfall können Sie alles einstellen: no_mouth:

Der eingestellte Wert scheint sich im folgenden Teil "Aktuelle Version" zu widerspiegeln, der auf dem App-Detailbildschirm des Stores angezeigt wird.

Befolgen wir nun die Spezifikationen des Versionscodes und des Versionsnamens, einschließlich der Beta-Version und der internen Testversion!

3. Ich möchte den manuellen Anwendungstest vor der Veröffentlichung verwenden

Es gibt vier Möglichkeiten, Apps zu veröffentlichen, die Entwickler verwenden können.

• Produktversion LKW (Produktversion)
• Open Track (Beta)
• Geschlossene Spur (Alpha-Version)
• Interne Testversionsspur (interne Testversion)

Es ist geworden. Es reicht aus, auf die folgenden Links zu verweisen, um zu erfahren, wie sie verwendet werden, daher werde ich darauf verzichten. Offene Testversion, geschlossene Testversion, interne Testversion einrichten

Ich möchte, dass Sie in diesem Artikel daran denken:

** Interne Testversion kann als Alpha-Version hochgestuft (freigegeben) werden, Alpha-Version kann zur Beta-Version heraufgestuft (freigegeben) werden, Beta-Version kann zur kommerziellen Version heraufgestuft (freigegeben) werden **

darüber. Es ist ein Bild, das Sie jeweils eine Ebene höher gehen können. Zu diesem Zeitpunkt werden ** Versionscode und Versionsname mit demselben Wert hochgestuft. ** ** ** Natürlich ist es natürlich.

Es gibt jedoch Zeiten, in denen ich mich bei der Verwendung dieser Teststrecke unwohl fühle.

-Wenn der Build in einem Track mit einer höheren Hierarchie veröffentlicht wird, kann der Build mit dem niedrigeren Track je nach Versionscode möglicherweise nicht verwendet werden.

In Bezug auf die Alpha- und Beta-Builds wurden die folgenden Hinweise auch in der Google Play Console angezeigt.

Damit Tester Alpha- und Beta-APKs verwenden können, muss der Versionscode für diese APK höher sein als für die Einzelhandels-APK.

Dies ist jedoch in der Anfangsanzeige nicht zu sehen. (Sie können es nur durch Drücken von ? Im Bild unten sehen)

Wenn Sie dagegen einen Build mit einem höheren Versionscode veröffentlichen als den Build, der als kommerzielle Version in die Alpha- oder Beta-Version hochgeladen wurde, können Sie die Alpha- und Beta-Builds nicht verwenden.

In Fällen, in denen Sie Funktionen testen möchten, die noch in der Zukunft liegen, empfiehlt es sich möglicherweise, einen Build mit einem gewissen Rand im Versionscode zu erstellen. (Es ist nicht so mühsam, es wieder anzuheben, auch wenn es nicht mehr verwendet werden kann, aber lol)

- Bleibt der auf die interne Teststrecke hochgeladene Build weiterhin bestehen, unabhängig vom Versionscode anderer Spuren?

Ähnlich wie bei den Funktionen der Alpha- und Beta-Versionen war auch die interne Testversion nicht verfügbar, wenn ein Build mit einem höheren Versionscode auf einem höheren Track veröffentlicht wurde. Es scheint jedoch, dass sich die Spezifikationen auf der Google-Seite geändert haben, und jetzt bleibt nur die interne Testversion übrig, selbst wenn der Build mit dem High-Version-Code auf der oberen Spur veröffentlicht wird.

Auch wenn die interne Testversion auf die Alpha-Version hochgestuft wird, bleibt die interne Testversion weiterhin bestehen und kann verwendet werden.

Unsterblich ...

Aufgrund dieser Spezifikation ist es möglich, Aktionen wie das Heraufstufen eines internen Testversions-Builds mit einem niedrigeren Versionscode als der Produktversion auf die Alpha-Version durchzuführen (die Anzeige der Alpha-Version wurde sofort durch die Produktversion ersetzt). Werden).

warum ist es. Ich bin so besorgt, dass ich nachts nicht schlafen kann. .. ..

Zusammenfassung

Es ist länger als erwartet, aber die Hauptsache ist die Verwaltung des Versionscodes, und es scheint, dass Sie den Versionsnamen relativ frei verwalten können. Damit ist die Angst vor Release-Arbeit fast verschwunden! Beginnen wir nächstes Jahr damit, die diesjährigen Ängste so weit wie möglich zu beseitigen oder zu vergessen!

Wenn Sie eine falsche Erklärung haben oder das Gefühl haben, nicht zufrieden zu sein, weisen Sie bitte darauf hin, um Ihre Angst zu lösen: bow_tone2:

Vielen Dank!