Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Versionsverwaltung

Magdalena Skarbińska

Demián Renzulli

Isolierte Web-Apps (IWAs) bieten eine vertrauenswürdige, sichere und versionsunabhängige Laufzeitumgebung auf der Webplattform. In Produktionsumgebungen, insbesondere in verwalteten Unternehmen, benötigen Administratoren und Entwickler eine detaillierte Kontrolle über Softwarebereitstellungen.

Um diese Anforderungen zu erfüllen, bietet Chrome umfassende Funktionen zur Versionsverwaltung für IWAs, darunter Update-Channels, Versionsanpinnen und Versionsdowngrade. Diese Funktionen ermöglichen eine vorhersehbare Bereitstellung und schnelle Wiederherstellungskontrollen für alle Nutzer.

Verfügbarkeit

Das Verhalten der Versionsverwaltung hängt davon ab, ob die IWA von einem Administrator verwaltet oder direkt von einem Nutzer installiert wird:

Verwaltete isolierte Web-Apps:Administrative Funktionen (einschließlich richtlinienbasierter Anpinnung und Downgrades) sind ab Chrome 133 verfügbar.
Nicht verwaltete (von Nutzern installierte) isolierte Web-Apps:Nutzerorientierte Funktionen wie die manuelle Kanalauswahl sind ab Chrome 150 verfügbar.

Kompatibilität von Sitzungstypen

Alle Funktionen zur Versionsverwaltung, einschließlich Update-Channels und Anpinnen von Versionen, sind mit allen ChromeOS-Sitzungstypen kompatibel. Dazu zählen:

Standardmäßige verwaltete Nutzersitzungen
Verwaltete Gastsitzungen (MGS)
Umgebungen im dedizierten Kioskmodus

Channels aktualisieren

Mit Update-Channels können Entwickler bestimmte App-Builds für unterschiedliche Bereitstellungs- und Testzielgruppen segmentieren. Wenn Sie Kanäle konfigurieren möchten, fügen Sie jedem Versionseintrag im Anwendungsaktualisierungsmanifest ein optionales Feld für das Array „channels“ hinzu. Diese Channelnamen sind nicht auf feste Plattform-Keywords wie canary oder stable beschränkt, sondern sind beliebige, vom Entwickler definierte IDs, die als alphanumerische ASCII-Strings in Kleinbuchstaben formatiert werden müssen (mit Bindestrichen oder Unterstrichen, aber ohne Leerzeichen). Wenn in einem Versionseintrag das Feld „channels“ vollständig fehlt, wird die Verfügbarkeit in Chrome implizit auf den Standardkanal festgelegt. Letztendlich muss der in der administrativen Richtlinie angegebene Kanalname genau mit dem im Manifest definierten String übereinstimmen. Bei Tippfehlern oder nicht übereinstimmenden Konfigurationen wird keine geeignete Version gefunden, wodurch Updates für diese Clients effektiv gestoppt werden.

Manifestkonfiguration

Wenn Sie Kanäle konfigurieren möchten, fügen Sie jedem Versionseintrag in Ihrem Web-App-Manifest ein optionales channels-Array hinzu. Hier einige Aspekte, die Sie berücksichtigen sollten:

Kanalzuordnung:Wenn in einem Versionseintrag ein channels-Array definiert ist, kann diese Version nur auf den angegebenen Kanälen installiert werden.
Standard-Fallback:Wenn in einem Versionseintrag das Feld channels vollständig fehlt, geht Chrome davon aus, dass die Version ausschließlich zum default-Channel gehört.
Exakter String-Abgleich:Die in clientseitigen Richtlinienkonfigurationen angegebenen Channelnamen müssen genau mit den im Update-Manifest definierten Strings übereinstimmen (Groß-/Kleinschreibung wird berücksichtigt). Wenn keine Version mit dem angegebenen Channelnamen übereinstimmt, kann die App keine infrage kommenden Updates finden.

Beispiel für das Aktualisieren des Manifests

Das folgende Beispiel zeigt ein Aktualisierungsmanifest, das mehrere Release-Channels unterstützt:

{
  "versions": [
    {
      "version": "0.1.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.1.0/iwa-sink.swbn",
      "channels": ["delta"]
    },
    {
      "version": "0.2.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.2.0/iwa-sink.swbn",
      "channels": ["delta", "default"]
    },
    {
      "version": "0.3.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.3.0/iwa-sink.swbn",
      "channels": ["beta", "delta"]
    },
    {
      "version": "0.4.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.4.0/iwa-sink.swbn"
    }
  ]
}

Basierend auf diesem Manifest sind die folgenden Versionen pro Zielkanal verfügbar:

Standard:0.2.0,0.4.0 (ohne expliziten Channel, Standard ist „default“)
delta:0.1.0, 0.2.0, 0.3.0
Beta:0.3.0

Die IWA-Update-Engine unterstützt das Targeting bestimmter Release-Channels, indem sie im Update-Manifest der App nach einem „channels“-Feld sucht.

Angepinnte Version

In Unternehmen mit hohen Compliance-Anforderungen oder in sehr stabilen Unternehmensumgebungen müssen Administratoren dafür sorgen, dass auf Geräten exakte Versionen geschäftskritischer Software ausgeführt werden. Durch das Anpinnen von Versionen können Administratoren eine IWA auf eine bestimmte Version festlegen und alle nachfolgenden Hintergrundaktualisierungen anhalten. So können Unternehmen stabile Konfigurationen beibehalten und strenge interne oder branchenspezifische Vorschriften einhalten.

Wenn Unternehmensadministratoren eine isolierte Web-App (IWA) auf einem bestimmten Release-Build einfrieren möchten, können sie die Eigenschaft pinned_version in der Richtlinie IsolatedWebAppInstallForceList konfigurieren. Diese Funktion wird hauptsächlich über die interaktiven UI-Steuerelemente in der Admin-Konsole im Detailbereich der Anwendung verwaltet. Dabei wird der standardmäßige IWA-Installationsablauf verwendet. Administratoren haben jedoch auch die Möglichkeit, diese Richtlinienwerte direkt über rohe JSON-Konfigurationen bereitzustellen. Sobald ein Administrator einen gültigen Versionsstring erfolgreich als Ziel festgelegt hat, ruft Chrome dieses explizite Paket ab und blockiert alle nachfolgenden automatischen Updates.

Besonderheiten und Einschränkungen

Updates fortsetzen (Anpinnen aufheben): Wenn Sie automatische Updates wiederherstellen möchten, entfernen Sie die pinned_version-Property oder ändern Sie ihren Wert in eine neuere Zielversion.
Standardmäßig kein Downgrade:Wenn Sie pinned_version auf eine niedrigere Version als die aktuell installierte Version festlegen, wird kein Rollback ausgelöst, sofern allow_downgrades nicht explizit aktiviert ist.
Nicht verfügbare Pin-Ziele:Wenn die konfigurierte pinned_version im angegebenen Update-Channel fehlt oder älter als die installierte Version ist (mit deaktivierten Downgrades), behält Chrome die aktuell installierte Version bei und blockiert alle weiteren Updates.
Neuinstallationen:Wenn eine IWA noch nicht auf einem verwalteten Gerät installiert ist und die angegebene „pinned_version“ nicht abgerufen werden kann oder im Update-Manifest fehlt, kann die IWA nicht installiert werden.

Downgrade der Version

Wenn ein neu bereitgestelltes Update einen kritischen Fehler oder eine kritische Sicherheitslücke enthält, müssen Administratoren möglicherweise ein Rollback auf den vorherigen stabilen Zustand durchführen. In Chrome ist es möglich, bereits installierte verwaltete IWA-Apps auf eine niedrigere Version herunterzustufen. Bisher waren auf der Plattform nur Vorwärtsupdates zulässig.

Ein Downgrade ist nur möglich, wenn beide der folgenden Richtlinienbedingungen erfüllt sind:

pinned_version ist auf eine gültige, ältere Version festgelegt.
allow_downgrades ist explizit auf „true“ gesetzt.

So funktionieren Downgrades

Trigger-Mechanismus:Rollbacks werden während des regulären Update-Prüfzyklus verarbeitet, der alle 4 bis 6 Stunden ausgeführt wird.
Im Hintergrund:Chrome führt eine vollständige Neuinstallation der IWA mit dem älteren Web-Bundle (.swbn) durch, das im Aktualisierungsmanifest angegeben ist.

Logik für Channel-Wechsel

Beim Wechseln des Zielkanals einer App mit einer Richtlinie hält sich die Update-Engine an bestimmte Verhaltensweisen:

Szenario A: Zu einem Channel mit früheren Versionen wechseln

Wenn ein Downgrade zulässig ist:Wenn „pinned_version“ mit einer älteren Version im Zielkanal übereinstimmt und allow_downgrades „true“ ist, erfolgt ein Rollback (und lokale Nutzerdaten werden gelöscht).
Wenn ein Downgrade nicht zulässig ist:Es erfolgt kein Downgrade. Das Gerät behält die aktuell installierte höhere Version bei und wird erst aktualisiert, wenn eine neuere Version auf dem neu ausgewählten Kanal verfügbar ist.

Szenario B: Wechsel zu einem Kanal mit einer identischen Version

Keine Änderungen:Wenn der neu ausgewählte Channel auf eine Versionsnummer verweist, die mit der aktuell installierten übereinstimmt, nimmt Chrome keine Änderungen am installierten Bundle vor.
Byte-by-Byte-Identitätsprinzip:Entwickler müssen dafür sorgen, dass identische Versionsnummern in verschiedenen Channels identische, bytegenaue Codesignaturen enthalten. Wenn Sie verschiedene Codebases mit demselben Versionsstring über verschiedene Kanäle bereitstellen, kann dies zu unerwarteten, unregelmäßigen Anwendungsstatus führen.

Konfiguration von Verwaltungsrichtlinien

Die Versionskontrollen für Unternehmen werden über die zentrale Google Admin-Konsole mit dem Richtlinienschema IsolatedWebAppInstallForceList erzwungen. Diese Einstellungen können direkt über die Benutzeroberfläche in der Admin-Konsole verwaltet oder mithilfe von JSON-Richtlinienkonfigurationen bereitgestellt werden.
Das folgende Beispiel für die Konfiguration einer administrativen Richtlinie veranschaulicht Update-Channels, das Fixieren von Versionen und Downgrades:

Darstellung von Richtlinienwerten

[
  {
    "update_manifest_url": "https://awesome-kitchen-sink.glitch.me/update.json",
    "web_bundle_id": "aiv4bxauvcu3zvbu6r5yynoh4atkzqqaoeof5mwz54b4zfywcrjuoaacai",
    "channel": "beta",
    "pinned_version": "0.7.0",
    "allow_downgrades": true
  }
]

Erklärungen zu Schemaparametern

channel (string, optional): Weist Chrome an, im Update-Manifest nur Versionen zu berücksichtigen, die diesem Channel zugewiesen sind. Wenn keine Angabe gemacht wird, wertet Chrome den „default“-Channel aus.
pinned_version (string, optional): Sperrt das Gerät explizit für den angegebenen Versionsstring. Nachfolgende automatische Hintergrundupdates werden blockiert.
allow_downgrades (boolesch, optional): Ermöglicht die Rollback-Funktion. Wenn „true“ und mit einem gültigen, älteren pinned_version kombiniert, löst Chrome eine Neuinstallation für das Downgrade aus. Warnung:Wenn Sie diesen Parameter auf „true“ setzen, werden alle Standard-Forward-Updates blockiert, auch wenn das Feld pinned_version weggelassen wird.

Nicht verwaltete (vom Nutzer installierte) IWAs (ab Version 150)

Bei nicht verwalteten, vom Nutzer installierten isolierten Web-Apps erfolgt die Versionsverwaltung durch manuelle Nutzerinteraktionen:

Installationspaket ──► Nutzer wählt Kanal aus ──► Automatische Prüfungen des ausgewählten Kanals

Manifestvoraussetzung für automatische Updates

Damit von Nutzern installierte IWAs im Hintergrund nach automatischen regelmäßigen Updates suchen und diese erhalten können, muss das lokale Web-App-Manifest der App (die im Bundle unter /.well-known/manifest.webmanifest enthaltenen Metadaten) ein gültiges update_manifest_url-Feld enthalten.

Wenn diese URL in der lokalen Manifestdatei der Anwendung fehlt, führt die nicht verwaltete Update-Engine niemals Hintergrundprüfungen durch und die Anwendung bleibt dauerhaft in der Version, die bei der Erstinstallation installiert wurde.

Manuelle Kanalauswahl

Bei der Erstinstallation einer nicht verwalteten IWA prüft der Browser das Update-Manifest und zeigt dem Nutzer verfügbare Channel-Optionen (z. B. „Stabil“, „Beta“) direkt an, wenn der Entwickler mehrere Channels konfiguriert hat.

Regeln für den Schlüssel-Lebenszyklus

Ursprung der ersten Installation:Unabhängig vom Kanal, den der Nutzer bei der Installation auswählt, werden bei der ersten Installation immer die Dateien bereitgestellt, die im bereitgestellten Installationspaket enthalten sind.
Nachfolgende Updates:Nach der Installation werden zukünftige Updates ausschließlich über den ausgewählten Channel abgerufen. Die App wird nur aktualisiert, wenn eine Version, die höher als die installierte ist, auf diesem Zielkanal veröffentlicht wird.
Kanal wechseln:Wenn der Nutzer nach der Installation zu einem anderen Updatekanal wechseln möchte, muss er die IWA deinstallieren und neu installieren und dabei den gewünschten Kanal auswählen.

Verwaltete Bereitstellungen testen

Für Administratoren, die Geräte über die Chrome Enterprise Admin-Konsole verwalten oder Richtlinien direkt konfigurieren:

Rufen Sie in den Organisationseinstellungen den Bereich App-Details auf.
Konfigurationseigenschaften anwenden, um das Anpinnen von Tests und Channel-Zielen zu testen. Da diese Steuerelemente vollständig mit Standardnutzersitzungen, verwalteten Gastnutzersitzungen (Managed Guest Sessions, MGS) und Kiosken kompatibel sind, können Sie das Verhalten in allen Zielbereitstellungsumgebungen überprüfen.
Wenn Sie Updateprüfungen lokal untersuchen möchten, rufen Sie auf einem Testclient chrome://web-app-internals auf, um Updateprüfungen manuell zu erzwingen und eingehende Manifestpakete zu analysieren.

Fazit

Die Sicherheitsarchitektur von isolierten Web-Apps wurde entwickelt, um Entwicklern mehr Möglichkeiten zu bieten und gleichzeitig eine strenge Vorhersagbarkeit und Kontrolle über das Verhalten des Anwendungslebenszyklus zu gewährleisten. Durch die Nutzung der Chrome-Funktionen zur Versionsverwaltung können sowohl Entwickler als auch IT-Administratoren robuste Bereitstellungspipelines erstellen, die strengen Compliance-Standards und betrieblichen Zielen entsprechen.

Beachten Sie beim Entwerfen und Verwalten der Aktualisierungsstrategie Ihrer Anwendung die folgenden Grundsätze:

Progressive Channels verwenden:Über Update-Channels wie beta, dev oder benutzerdefinierte Rings können Sie nach und nach Telemetriedaten und Feedback sammeln. So wird sichergestellt, dass wichtige Updates einer strengen Überprüfung unterzogen werden, bevor sie im Standardchannel für die allgemeine Bevölkerung verfügbar sind.
Version für Stabilität fixieren:In stark strukturierten oder Compliance-orientierten Unternehmensumgebungen sollten Sie kritische Endpunkte an eine bestätigte, genaue „pinned_version“ binden, um den Betrieb vor unerwarteten Unterbrechungen oder Workflow-Störungen zu schützen.
Downgrades für Notfälle reservieren:Das Downgrade von Versionen ist ein leistungsstarkes, korrigierendes Sicherheitsventil, das zuvor nicht möglich war. Da bei einem Rollback jedoch eine vollständige Neuinstallation ausgelöst und der gesamte lokale Clientspeicher (IndexedDB, LocalStorage, Cookies) gelöscht wird, sollte er nur für kritische Sicherheitsmaßnahmen verwendet werden. Bei gewöhnlichen Patches ist es immer am besten, ein kleines zukunftsorientiertes Update bereitzustellen.
Richtlinien-Flags verstehen:Achten Sie auf administrative Schalter. Wenn Sie allow_downgrades aktivieren, werden alle zukünftigen Updates angehalten, auch wenn keine PIN aktiv definiert ist.
Byte-für-Byte-Integrität herstellen:Achten Sie darauf, dass identische Versionsnummern, die in verschiedenen Channels bereitgestellt werden, identischen, bytegenauen Bundles zugeordnet werden, um unregelmäßige Anwendungsstatus zu vermeiden, wenn Clients zwischen Channels wechseln.

Durch die Integration dieser Funktionen direkt in Ihr Update-Manifest und Ihr Unternehmensrichtlinienschema können Sie einen zuverlässigen, prüfbaren und sicheren Update-Ablauf sicherstellen, der die hohen Vertrauensgarantien des Ökosystems für isolierte Web-Apps beibehält.