# Ballbox machine package and remote ads path

Date: 2026-06-06
Goal: locate the USB update package and assess whether the same file-swap model could be reproduced remotely for ads.

## Located packages

Most relevant packaged artifacts found on this machine:

- `/home/sebas/outputs/ballbox-machine-copy.zip`
- `/home/sebas/outputs/ballbox-machine-copy-final.zip`
- `/home/sebas/outputs/ballbox-machine-copy-deep.zip`
- `/home/sebas/outputs/ballbox-machine-copy-v3-spanish-candidate.zip`

Likely original inbound zip copies:
- `/home/sebas/outputs/inbox/ballbox-dropzone/20260530-103420-Archivos-En-Maquina-20260529T220853Z-3-001.zip`
- `/home/sebas/outputs/inbox/ballbox-dropzone/20260531-074743-Archivos-En-Maquina-20260529T220853Z-3-001.zip`

Working task tree:
- `/home/sebas/work/tasks/T-ballbox-rebrand-v3/`

## GitHub repo match

Repo:
- `https://github.com/sebasfavaron/dropbox`

Local clone:
- `/home/sebas/dropbox`

The repo README confirms it is the release-manifest repo for Ballbox machine rebrand packages.
Current repo content is mostly documentation, with large binaries expected to live in Releases.

Recent repo commits:
- `b6f3ffb` Document QR payment asset patch in Ballbox v3
- `74136fb` Document Ballbox v3 Spanish candidate release
- `f465fce` Document Ballbox rebrand releases

## Best concrete package now

Strongest package for media-path understanding:
- `/home/sebas/outputs/ballbox-machine-copy-final.zip`

Archive structure confirms the machine update payload includes:
- `YSConfigcopy/`
- `TcnFoldercopy/`
- many vendor APKs
- media directories used by the machine runtime

Relevant media buckets inside package:
- `TcnFoldercopy/ImagePay/`
- `TcnFoldercopy/ImageRight/`
- `TcnFoldercopy/ImageScreen/`
- `TcnFoldercopy/ImageBackground/`
- `TcnFoldercopy/ImageHelp/`
- `TcnFoldercopy/VideoAndImageAd/`
- `TcnFoldercopy/pollFile/`

## Confirmed Ballbox path replacements

From repo docs plus package README, confirmed direct path swaps were:
- `TcnFoldercopy/ImagePay/46d3a954-ec76-4f45-8696-e153b4ef48be.png`
- `TcnFoldercopy/ImageRight/a2f1d5b7-2291-4fa5-8fa3-1385218008a4.png`
- `TcnFoldercopy/ImageScreen/流程图.jpg`
- `TcnFoldercopy/pollFile/Screeempty.png`
- `TcnFoldercopy/pollFile/adEmpty.png`

Additional mapped assets in final package:
- `TcnFoldercopy/ImageBackground/ballbox-home-secondary.png`
- `TcnFoldercopy/ImageScreen/ballbox-home-secondary.png`
- `TcnFoldercopy/ImageHelp/ballbox-help-selection.png`
- `TcnFoldercopy/ImageHelp/ballbox-help-payment-qr.png`

## What this proves

This is the important step-change:
- Ballbox already has a proven machine package format that the machine accepts.
- That package model works by replacing files in exact vendor media buckets.
- Therefore remote ad/control does not need to start from mysterious cloud VIP APIs.
- A viable alternative path is to reproduce the same file replacement behavior from inside Android.

## Practical remote-control model now

Plausible architectures, ordered by simplicity:

### A. Small Android-side sync service
- run a lightweight service on the machine
- fetch a manifest from Ballbox
- download updated files
- write them into exact known folders in `TcnFoldercopy` / live vendor paths
- trigger app refresh / restart / media rescan if needed

### B. Cloned app handles content sync
- patch cloned APK to fetch Ballbox-managed assets
- app writes or directly reads Ballbox assets instead of vendor-hosted ones
- best if partner already controls APK internals

### C. Hybrid
- keep cloned app mostly intact
- add a sidecar updater that only manages file placement
- less invasive than making main APK own all sync logic

## Why this is plausible

- Yunshu cloud already changes machine-visible media somehow.
- The machine already supports offline file-driven updates from USB in this exact directory structure.
- Ballbox already changed those assets successfully by repackaging files.
- User reports partner already cloned and modified the Android app itself.
- Ads/media are lower-risk than payments or vend logic.

## What is still unproven

- exact live writable path on the running Android filesystem
- whether a plain file overwrite is enough or app restart/cache bust is needed
- whether a background service can write there without root or special permissions
- whether remote-downloaded files must preserve exact filenames
- whether some slots are driven by sqlite/config references instead of folder scan only

## Best next technical questions

1. On the machine, what real runtime path corresponds to these imported `TcnFoldercopy/*` files after USB update?
2. Does the app read them on startup only, or hot-reload some of them?
3. Can the cloned app or a sidecar app write to those paths directly?
4. Which ad zones are filename-fixed versus directory-scanned?
5. Is `VideoAndImageRemote` or similar directory actually used for remote-downloaded ads?

## Recommendation

Yes: based on current evidence, remote ad control via machine-side file sync now looks like one of the most realistic Ballbox autonomy paths.

The best near-term path is probably:
1. inspect runtime live paths on machine
2. verify file overwrite + refresh behavior for one ad slot
3. build minimal Ballbox manifest/downloader
4. only later generalize into a polished remote-content system