Phase 7 decision – Signing, OTA, recovery and deployment

1. Can the three APKs be updated under `/data/app`?

Android's updated-system-app mechanism can in principle update Channels, GEL and TPTvService while retaining their stock /system APKs. The device already uses this mechanism for other packages. None of the three is currently updated.

2–3. What exact signature blocks us?

All three share UID1000 and the exact Platform signer SHA-256 D8:FF:E0:AF:40:4E:AB:8E:45:5A:00:74:D4:17:B0:DA:12:D0:67:26:E5:05:B0:2B:7F:DB:18:31:29:C8:90:68. It is also the framework-res signer. The matching private key or OEM signing service is unavailable; the signer is therefore mandatory and currently blocking. The separate OTA certificate cannot replace it.

4. tvfw.jar

No useful isolated deployment exists. It is DEX-bearing, preoptimized and loaded as a Philips shared library by many clients. Although not on BOOTCLASSPATH/SYSTEMSERVERCLASSPATH, it requires coherent ART/client/system- image integration and accepted AVB.

5. AVB boundary

The device is locked/green with AVB 1.2 and enforcing dm-verity. system, vendor, linux_rootfs, 3rd and factory have device-proven AVB mappings/ fstab flags. Exact vbmeta descriptors, keys, chains and rollback indexes are unread. A content-changed system image is not trusted without OEM AVB signing.

6. Recovery paths actually proven

Proven: PackageManager fallback for a removable updated-system APK while normal Android/ADB runs; static A/B architecture, UpdateEngine, Boot-Control HAL and UpdateVerifier. Not proven: physical recovery key combo, recovery ADB/sideload, USB emergency mode, manual slot control or end-to-end bad-slot fallback. No separate recovery partition exists.

7. Bad Channels update

Likely the TV still boots and the update can be removed with PackageManager, revealing the untouched stock APK. This is not yet cold-boot tested, and a data schema migration could make the old APK unusable. Hence it is not a present GO.

8. Bad framework/tvfw patch

Many Philips TV clients may crash; ADB/UI availability is uncertain. There is no PM fallback. Recovery depends on A/B rollback or an official full USB firmware path, neither end-to-end proven. High risk.

9–10. Safest permanent path and live status

Safest production path: Philips/TPVision integrates, signs and ships the fixes through its official build/OTA process. Safest first engineering candidate: OEM-Platform-signed Channels updated-system APK after a lab rollback drill. First live patch remains NO-GO. No installation was performed in Phase 7.

11. What Philips/TPVision must provide

matching source/build integration and approved Platform signing;
preferably an official A/B firmware containing the fixes;
full autorun*.upg recovery firmware for 43PUS7394/12 / TPM191E_R;
exact cold-boot USB recovery/key procedure;
documented payload/AVB signing and rollback policy;
or a Platform-signed Channels test APK plus verified uninstall/data rollback.

12. Maintenance fallback

Use tools/epg-health-check/health_check.py. Its default ADB mode reads only dumpsys dbinfo and df; offline snapshot mode uses SQLite read-only. It never repairs automatically. If maintenance is recommended, repeat only the already validated supervised repair workflow after a fresh backup and explicit authorization.

3.3 KiB Raw Permalink Blame History Unescape Escape