cleanyourtv - Moses Yebei

The Problem

Smart TVs ship with a bundle of pre‑installed apps that add ads, telemetry and rarely used features. Because the devices are locked down, users cannot remove them without rooting, and the default launcher is cluttered. A clean, ad‑free home screen that can be restored in a single tap would improve privacy and performance.

What This Does

The project replaces the stock launcher on any Android or Google TV device with a lightweight, Apple‑TV‑style home.

launcher/app/src/main/java/com/gathin/tvhome/MainActivity.java is the UI entry point.
AppLibraryDialog (AppLibraryDialog.java) presents a list of removable packages read from the examples/*/debloat.txt files.
HomeKeyService (HomeKeyService.java) listens for the Home button; when pressed it launches the dialog, allowing the user to delete apps over an ADB‑over‑Wi‑Fi connection.
Config.java holds constants such as ADB_HOST, ADB_PORT, and the default package list path, making it easy to change the target device or add new lists.

The app does not modify the system itself; it only issues adb shell pm uninstall -k --user 0 <pkg> commands, preserving data for a one‑line restore.

How It Is Wired

Entry Point – MainActivity.onCreate() initializes the launcher and registers HomeKeyService.
Call Flow – HomeKeyService.onKeyDown() → MainActivity.startAppLibraryDialog() → AppLibraryDialog.showDialog() → AppLibraryDialog.onAppSelected() → Config.getDebloatList() → AppLibraryDialog.uninstallPackage().
External Touches –
ADB shell calls (Runtime.exec) to uninstall packages.
Network socket to ADB_HOST:ADB_PORT for the Wi‑Fi ADB connection.
Responsibilities –
Config owns constants and path resolution.
AppLibraryDialog owns the UI logic and package removal.
HomeKeyService owns key‑event handling and triggering of the dialog.
MainActivity orchestrates the overall flow and manages lifecycle. No file has a wide blast radius; each is tightly scoped.

How To Use It

Setup

git clone https://github.com/moses-y/cleanyourtv
cd cleanyourtv/launcher
./gradlew assembleDebug   # builds the APK

Configuration – Edit launcher/app/src/main/java/com/gathin/tvhome/Config.java to point ADB_HOST to your TV’s IP.

Running – Install the generated app-debug.apk on the TV. Enable ADB debugging and connect over Wi‑Fi (adb connect <ip>:5555). Launch the app and press the Home key to open the debloat dialog.

Real‑World Use

A network engineer installs the launcher on a fleet of Google TVs in a hotel. After enabling ADB over Wi‑Fi, the engineer updates Config.java with the hotel’s TV IP range and pushes the APK via OTA. Guests can press Home to remove unwanted telemetry apps and restore the default launcher with a tap.

Code Health & Issues

Low – Dependencies declared without a lockfile – launcher/app/build.gradle
Low – No reproducible build lock for tools/requirements.txt
Low – Missing unit tests for AppLibraryDialog logic (only 23 test files in tests/).

No critical security findings; all external calls are encapsulated in Runtime.exec with user‑supplied package names validated against the debloat list.

The Bottom Line

CleanYourTV delivers a straightforward, non‑rooted solution to strip bloatware from Android/Google TVs. Its architecture is clear: a launch‑time entry point, a key‑event service, and a dialog that runs ADB uninstall commands. The code is modular, but the build lacks reproducibility due to missing lockfiles. The project is ideal for environments where root access is unavailable but a clean home screen is desired.

What the analyser found

Deployment readiness

5/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

327 files

Java44
Markdown18
Python13
YAML5
JSON5
Shell4

CUDA

Dependencies

1 of 5 declared dependencies are a major version behind. Resolved 3 of 5 against the registry.

Package	Declared	Latest	Behind
`cryptography`	>=46.0.7	50.0.0	4 major

Findings

LowDependencies declared without a lockfile - non-reproducible builds launcher/app/build.gradle

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high2

medium4

low1

Pin third-party GitHub Actions to a commit SHAhigh2 occurrences

.github/workflows

android-actions/setup-android@v3, gradle/actions/setup-gradle@v4

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Make CI invoke the test suite it hashigh23 occurrences

.github/workflows

23 test files, no test command in any workflow

A green check that never executed an assertion is worse than no check, because reviewers trust it.

Fix: Add a test step to the existing workflow rather than a new workflow.

Enable Dependabot or Renovatemedium

1 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Set persist-credentials: false on checkoutmedium

.github/workflows/ci.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Pin the resolution so a vulnerable version cannot installmedium7 occurrences

no lockfile, and the declared ranges reach cryptography@46.0.7 GHSA-537c-gmf6-5ccf (high) +6 more

The range includes versions with published advisories and nothing in the repository records which one was resolved, so two installs a month apart can differ in whether they are vulnerable and neither is reproducible from what is committed.

Fix: Commit the lockfile, which fixes the resolution and makes this answerable.

Set timeout-minutes on the workflow jobslow

.github/workflows/ci.yml

1 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.