Skip to content

Selbst-Updater-Erkennung

Electron-App-Erkennung

AppPorts identifiziert Electron-Apps anhand der folgenden drei Erkennungsbedingungen (in Prioritätsreihenfolge geprüft, Kurzschlussauswertung):

#ErkennungselementPfad / Muster
1Electron FrameworkContents/Frameworks/Electron Framework.framework-Verzeichnis vorhanden
2Electron Helper-VariantenEinträge mit Electron Helper im Namen unter Contents/Frameworks/ vorhanden
3Info.plist IdentifikationsschlüsselElectronDefaultApp- oder electron-Schlüssel in Contents/Info.plist vorhanden

Electron-Selbstupdate-Erkennung

Zusätzlich wird das Vorhandensein der Datei Contents/Resources/app-update.yml geprüft (Konfigurationsdatei für electron-updater). Falls vorhanden, wird die Electron-App als selbstupdatefähig markiert.

Sparkle-App-Erkennung

AppPorts identifiziert Sparkle-Apps anhand der folgenden drei Erkennungsbedingungen:

#ErkennungselementPfad / Muster
1Sparkle FrameworkContents/Frameworks/Sparkle.framework oder Contents/Frameworks/Squirrel.framework vorhanden
2Updater-BinärdateienDateien, die shipit, autoupdate, updater, update entsprechen, unter Contents/MacOS/ oder Contents/Frameworks/ vorhanden
3Info.plist Sparkle-SchlüsselEiner der folgenden Schlüssel in Contents/Info.plist vorhanden: SUFeedURL, SUPublicDSAKeyFile, SUPublicEDKey, SUScheduledCheckInterval, SUAllowsAutomaticUpdates

⚠️ Spezialbehandlung für Electron-Apps

Wenn eine App als Electron-App identifiziert wurde, wird die Erkennungsbedingung #2 (Updater-Binärdateien) übersprungen, um falsch-positive Erkennungen des electron-updater-updater-Binär als Sparkle zu vermeiden.

Hybrid Electron + Sparkle Apps

Einige Apps enthalten sowohl das Electron-Framework als auch den Sparkle-Updater. AppPorts erkennt beide Flags unabhängig, sodass isElectron und isSparkle beide true sein können.

Erkennungslogik

text
isElectron = erfüllt eine der drei Electron-Erkennungsbedingungen
isSparkle  = erfüllt eine der drei Sparkle-Erkennungsbedingungen (Electron-Apps überspringen Bedingung #2)

Die beiden Flags sind unabhängig und können beide gleichzeitig wahr sein.

Verhalten nach der Migration

AttributBestimmungsbedingung
hasSelfUpdaterisSparkle oder (isElectron und app-update.yml vorhanden) oder Custom Updater vorhanden
needsLockisSparkle oder (isElectron und app-update.yml vorhanden)

Wenn needsLock true ist, führt AppPorts nach Abschluss der Migration chflags -R uchg (Setzen des immutable Flags) auf der externen Speicher-App aus, um zu verhindern, dass Selbst-Updater die externe Kopie löschen oder ändern.

Custom-Updater-Erkennung

Für native Selbstupdate-Apps, die weder Sparkle noch Electron sind (z. B. Chrome, Edge, Parallels), identifiziert AppPorts diese anhand folgender Muster:

ErkennungspfadÜbereinstimmungsmusterTypische Apps
Contents/Library/LaunchServices/Dateiname enthält updateChrome, Edge, Thunderbird
Contents/MacOS/Binärdateiname enthält update oder upgrade (ausgenommen electron)Parallels, Thunderbird
Contents/SharedSupport/Dateiname enthält updateWPS Office
Contents/Info.plistKSProductID-Schlüssel vorhandenGoogle Keystone (Chrome)

Legacy-Strategie-Identifikation

Bei der Wiederherstellung oder Entlinkung muss AppPorts Legacy-Einträge erkennen, die von älteren Versionen erstellt wurden:

Lokale StrukturerkennungIdentifiziert als
Stammverzeichnis ist ein symbolischer LinkwholeAppSymlink
Contents/ ist ein symbolischer LinkdeepContentsWrapper
Contents/Info.plist ist ein symbolischer LinkwholeAppSymlink (Legacy Sparkle-Hybrid-Schema)
Contents/Frameworks/ ist ein symbolischer LinkwholeAppSymlink (Legacy Electron-Hybrid-Schema)
Contents/MacOS/launcher vorhandenstubPortal
Keine der obigen ÜbereinstimmungenNicht von AppPorts verwaltet
最近更新