{
  "name": "bar-install",
  "icon": "https://bb10repo.whytofly.de/img/bb10-apkui.png",
  "category": "Runtime",
  "type": "cli",
  "homepage": "https://bb10repo.whytofly.de/",
  "description": "BB10 .bar and Android .apk installer. Every Rubus package that needs to land an app on the home screen runs this in its post-install hook — it talks to sud via PPS messages, handles dev-slot allocation, ID rewriting (gYAB → andrB so unsigned bars install), and pps-based result polling.\n\nFor Android .apk installs it also parses AndroidManifest.xml + resources.arsc to extract the application label, icon, and main activity, then writes a synthetic MANIFEST.MF + invokes sud's install_apk flow. The resmap hash table inside is sized for very large apks (Telegram X has 7687 string entries) so labels and icon paths resolve correctly.\n\nThis package's post-install hook is __devuser-mediated like bb10-apk-tools — the new bar-install binary lands with BB10 pathtrust EXEC so it stays runnable from any perimeter that calls it.",
  "history": [
    {
      "version": "20260719.1",
      "released": "2026-07-19",
      "changes": "- Corrects 20260719: no longer depends on bb10-rootd. Pulling a root daemon (bb10-rootd's sudo, which currently has no auth — any local process can ask it to run something as root) onto every device as a side effect of installing bar-install was more than the confirmed bug warranted; it was only root-caused and tested on one heavily-modified device, not shown to be a widespread issue. The activator.py nudge in bar-install.c is unchanged and still opportunistic — if bb10-rootd happens to already be installed, installs/uninstalls get the nudge+retry reliability improvement from 20260719 for free; if not, behavior is identical to pre-20260719 (a single passive wait). Install bb10-rootd yourself first if you want the nudge."
    },
    {
      "version": "20260719",
      "released": "2026-07-19",
      "changes": "- Fixes installs/uninstalls (including Rubus's own self-upgrade!) hanging at 'Waiting for system installer... Timed out', or completing at the apk-package level while the actual app never lands/updates on the home screen. Root cause: BB10's install/uninstall processor (activator.py, run as sud.py) is NOT a persistent daemon — it's meant to be spawned on-demand by a ppsnetd watch on the installer-request PPS path, and that watch doesn't reliably fire on every device (or never got registered at boot). A request we write can then sit unprocessed forever with no result. activator.py itself works fine when run directly (verified on-device) — it just needs root. If bb10-rootd's sudo daemon is installed, every install/uninstall request is followed by a direct nudge (the same one-shot activator.py invocation the system's own boot script uses) instead of passively waiting on the flaky watch, with several short nudge+retry cycles instead of one long timeout. Devices without bb10-rootd get the unchanged original single-wait behavior — no regression. Root-caused live: an actual Rubus self-upgrade was stuck at progress::50 forever pre-fix; with the nudge it installed successfully on the first attempt."
    },
    {
      "version": "20260718",
      "released": "2026-07-18",
      "changes": "- Fixes 'Android app missing legacy icon' / install fails to land an icon on the home screen (hit on Telegram X). Root cause: modern apps often only ship an Android adaptive-icon XML descriptor at the resolved icon resource path, not a flat PNG — unzip 'succeeds' extracting that XML, but it isn't a real image, so upd's installer rejects the app. Icon resolution now runs BEFORE the manifest is written and validates every candidate (resolved path, then the drawable/mipmap glob fallbacks) is an actual PNG via its magic bytes; if nothing usable exists anywhere in the apk, a baked-in placeholder icon is written so the install always succeeds with SOME icon. (The 20260526 changelog claimed this fallback already existed; it did not survive the 20260601/20260602 rollback to the legacy binary — this properly re-adds it with real validation.)\n- Also improves the odds of recovering the REAL icon instead of the placeholder: the resource map used to resolve icon paths kept only the first config seen per resource ID. Apps commonly ship an adaptive-icon XML (the anydpi-v26 config) alongside legacy flat-PNG fallbacks for older launchers under other density configs of the SAME resource ID — if the XML config happened to be visited first, the real PNG was discarded. The map now prefers a later .png config over an already-stored .xml one (a no-op for label strings and everything else that isn't a res/... path)."
    },
    {
      "version": "20260629",
      "released": "2026-06-29",
      "changes": "- Adds --check [--apk] <file>: prints 'CHECK: INSTALLED|REMOVED <id>' by deriving the app's installed id and looking it up in the navigator registry. Used by Rubus's db reconciliation (which apk-dels GUI packages whose app was deleted from the homescreen).\n- --remove now short-circuits to success when the app is already gone from the homescreen, instead of polling upd for a result that never comes — so reconcile's apk del is instant. The registry is read via cat (the device grep rejects the long PPS lines as 'message too long', and stdio fopen mis-reads the PPS special)."
    },
    {
      "version": "20260628",
      "released": "2026-06-28",
      "changes": "- Fixes apk/Rubus-driven installs that failed with 'permission denied' on /pps/system/installer/upd/current/runtimeInstall.* (and the resulting 'Waiting for system installer... Timed out'). The installer-PPS writes must run as the upd user (owner of that dir); bar-install looked for the impersonation helper only under /q/, but the autoroot ships it as /bin/__upd. Helper resolution now searches /q, /bin, and /base/bin for __upd/__pps/etc., so the request is written as upd from any perimeter — no ACL grant, boot script, or computer needed. Validated on-device (request object lands upd-owned; install succeeds with no devuser ACL on the dir)."
    },
    {
      "version": "20260602",
      "released": "2026-06-01",
      "changes": "- Rolled back 20260601. The msg::removeApp removal was the wrong layer to address the icon-disappearance during self-upgrade: the underlying issue was that 20260601 also lost the `/q/__upd` privilege-impersonation fallback and the explicit activator spawn that the legacy binary used to get upd to actually process writes to /pps/system/installer/upd/current/. Without those, `/pps/...` writes silently fail under autoroot and upd never picks up the install request. Going back to the legacy binary; the no-removeApp work will land separately once those pieces are reimplemented (likely via /bin/__devuser stdin-piped PPS writes + a non-qon activator trigger)."
    },
    {
      "version": "20260601",
      "released": "2026-06-01",
      "changes": "- Dropped the legacy `msg::removeApp` to navigator that fired before every install. It was supposed to clear the old icon ahead of the new install, but if the install died mid-way (e.g. Rubus's self-upgrade trampoline failing) the icon never came back. The PPS install flow already handles icon publish/update correctly, so the explicit removeApp was redundant and the failure mode wasn't.\n- New Rubus builds drop the redundant bar-install copy from their .bar; Rubus now calls the system bar-install at /accounts/1000/shared/misc/apk/bar-install which this package keeps current."
    },
    {
      "version": "20260526",
      "released": "2026-05-26",
      "changes": "- post-install probes for __devuser at /bin/, /q/, /base/bin/\n- Resource-map hash table bumped from 2048 to 65536 entries so big apks (Telegram X) resolve labels/icons correctly\n- Final-fallback placeholder PNG for adaptive-icon-only apks\n- 'Reclaimed N dev-slot markers' now reports actual leaks, not slots that were never used"
    },
    {
      "version": "20260525",
      "released": "2026-05-25",
      "changes": "- Initial release of bar-install 4.0 as an apk package"
    }
  ]
}