{
  "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": "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"
    }
  ]
}