You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
release: 2.2.44 — .pkg install: switch primary backend from BGFT to AppInstUtil (etaHEN-style)
User report: BGFT install fails with "BGFT symbol missing:
sceBgftInitialize" / 0xe0000001. The 2.2.43 BGFT-side fix added
multiple library paths and symbol-name variants to harden the
dlopen+dlsym dance, but BGFT's symbol decoration drifts across
firmwares enough that some path/name combination is bound to fail.
Studied etaHEN's pkg-install implementation
(util/source/DirectPKGInstaller.cpp) — they don't use BGFT at all.
They use Sony's higher-level sceAppInstUtilInstallByPackage,
which:
- Lives in libSceAppInstUtil, *already compile-time linked* in
our payload via -lSceAppInstUtil (no dlopen/dlsym needed).
- Takes a URL + meta info and handles the full download +
decrypt + install chain end-to-end.
- Returns the content_id we use for status polling via
sceAppInstUtilGetInstallStatus.
bgft.c now dispatches:
- AppInstUtil path (primary): no firmware-symbol-drift fragility,
same call etaHEN / DirectPKGInstaller use, years of field
testing on 9.6x firmwares.
- BGFT path (fallback): unchanged from 2.2.43, kept so obscure
firmwares where AppInstUtil refuses still have a chance.
Synthetic 32-bit task IDs route status polls back to the right
backend (task_id & 0x40000000 → AppInstUtil, otherwise BGFT).
Sony's status string ("downloading"/"installing"/"playable") maps
to our phase enum so the UI doesn't change.
Verification: tsc clean, vitest 226/226, eslint clean,
clippy -D warnings clean (tauri), payload -Werror clean.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0 commit comments