# TCN remote ads autonomy notes Date: 2026-06-06 Status: working note ## Current intent Ballbox does not want to pay for OurVend VIP ad access for now. The active research direction is to control machine ads/media through the Android runtime and known machine file paths instead of depending on Yunshu cloud entitlements. ## New evidence from Felipe chat Source dropzone file: - `/home/sebas/outputs/inbox/ballbox-dropzone/20260606-185445-WhatsApp-Chat---Feli-Oliver.zip` Important extracted claims from the chat: - Felipe explicitly said he downloaded content from the machine and some files were added by him, including videos. - Felipe said the machine requires specific folder names for the machine to pick up content. - Felipe said the sent videos explain which asset goes where. - Felipe did not fully know where some image slots 2/3/4/5 went yet at that moment. - Felipe later said: `yo puse un video en la carpeta ImageScreen` and clarified it was `el video grande`. - Felipe confirmed a later APK path worked: `funciono y pude cambiar textos e imagenes`. - Felipe's stated direction was to build/control a new APK so Ballbox can later add Mercado Pago and manage advertising from there. - Felipe also said a per-machine SIM may be needed for stronger remote control. ## Important current assumptions - A Ballbox partner already cloned and modified the Android machine app. - That partner reportedly changed at least one image shown when selecting a product. - Ballbox already has accepted USB update packages that replace machine-visible assets by placing files into exact vendor folders. - Therefore remote ad/media control should be evaluated first as a machine-side file sync problem, not first as an OurVend VIP/API problem. ## Why this looks viable The machine already accepts update bundles with: - `YSConfigcopy/` - `TcnFoldercopy/` Confirmed vendor media buckets used by Ballbox packages: - `TcnFoldercopy/ImagePay/` - `TcnFoldercopy/ImageRight/` - `TcnFoldercopy/ImageScreen/` - `TcnFoldercopy/ImageBackground/` - `TcnFoldercopy/ImageHelp/` - `TcnFoldercopy/VideoAndImageAd/` - `TcnFoldercopy/pollFile/` This means a remote autonomy path could be: 1. Ballbox service publishes manifest + files 2. machine-side Android service or cloned app downloads updates 3. updater overwrites exact target files in known vendor buckets 4. app restart or OS restart is allowed if needed ## Operational constraint accepted by user Ad changes are likely monthly, not frequent. So optimal live refresh is nice but not required. For Ballbox operations, either of these is acceptable if needed: - restart app - restart Android system This lowers product risk substantially. We do not need perfect hot-reload to make the autonomy path useful. ## Known package evidence Most relevant package found locally: - `/home/sebas/outputs/ballbox-machine-copy-final.zip` Supporting repo: - `https://github.com/sebasfavaron/dropbox` - local clone: `/home/sebas/dropbox` Confirmed exact replaced paths from Ballbox package history: - `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 paths in the deeper/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` ## Image vs video status after reading Felipe chat This is now clearer. What is now directly supported: - Felipe said some manually added files included videos. - Felipe explicitly said he put a video into `ImageScreen`. - Therefore Ballbox machine experimentation definitely included video-side testing, not only static image replacement. What is still open: - we do not yet have a full verified slot map for every image/video surface - we do not yet know whether every video slot is folder-driven versus partially APK-driven ## APK-side evidence from Felipe chat Felipe reported: - icons/GIFs for some flows are inside the main TCN APK, not loose folders - changing wording/voice text required editing APK resources and rebuilding/signing - test APKs existed, including: - `TCN-SD-05-BallBox-QR-AR.apk` - `TCN-SD-05-BallBox-QR-AR-v5205.apk` - one later version reportedly worked for changing texts and images Meaning: - some visible media can be controlled by loose files in vendor folders - other visible media are embedded inside APK resources - the real autonomy strategy may need both: 1. file-bucket sync for loose media 2. APK patching/redeployment for embedded resources ## Most likely implementation options ### Option A — sidecar updater service A lightweight Android service handles: - polling Ballbox manifest - downloading files - writing vendor-path assets - triggering restart/rescan ### Option B — cloned app owns sync The modified TCN app itself fetches Ballbox media and writes or reads from Ballbox-managed sources. ### Option C — hybrid Keep the cloned app mostly intact and add a sidecar updater just for content replacement. This may be the lowest-risk path. ## Complexity read ### File-sync only path If the target ad zone is driven by loose files in known folders: - complexity: low to medium - blockers: writable runtime path, restart behavior, connectivity ### APK-embedded asset path If the target ad zone is embedded in the APK: - complexity: medium to high - blockers: rebuild/sign/install stability, update path, machine compatibility ### Full Ballbox-controlled machine runtime direction Felipe's own direction points toward: - stabilizing Ballbox-controlled APK first - then using that runtime to manage advertising and later payments That is plausible, but a bigger project than simple file sync. ## Key unknowns still to prove on a live machine 1. what runtime path corresponds to the imported USB package folders 2. whether overwriting files in place is enough 3. whether restart is needed and at which level 4. whether filenames must stay exact for each slot 5. whether any slot is folder-scanned versus hardcoded by filename 6. whether `VideoAndImageRemote` or another remote bucket is actually used in practice 7. which visible surfaces are folder-driven vs APK-driven ## Best next validation when machines are on again 1. inspect live Android filesystem paths 2. pick one low-risk folder-driven asset slot 3. overwrite with a clearly different test asset 4. restart app if needed 5. if still needed, reboot OS 6. confirm which slots update and which do not 7. record exact writable path + refresh rule 8. separately test one APK-driven surface if needed ## Repo/path note User asked to persist this under `~/ballbox`, but on this machine the main Ballbox repo is actually: - `/home/sebas/work/projects/ballbox` This document is stored there accordingly.