1.8 KiB
Platform-signing and shared-UID analysis
Proven baseline
Channels, GEL and TPTvService carry the same RSA-2048 certificate, 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,
and APK Signature Schemes v1, v2 and v3. Their manifests request the system
shared UID; Channels is privileged and TPTvService is core/persistent. The
public certificate exists in each APK, but the private key does not exist in
the workspace.
Package Manager consequences
An updated system app can normally live under /data/app and override its
read-only /system base while preserving system-app identity. For these
packages it must have the same package name, compatible version and—decisively—
the exact accepted signer/signing lineage. The shared UID also requires signer
compatibility with the other members. A debug/test key, a certificate with the
same subject text, or copied signature files is rejected or invalid.
Therefore:
- a Philips-platform-signed Channels/GEL/TPTvService APK is potentially the
safest first deployment because it need not alter
/systemor AVB; - a locally rebuilt but differently signed APK is not an installable update;
- changing sharedUserId/package name creates a different app and cannot replace privileged providers/services or inherit signature permissions;
- no “signature bypass” is proposed.
tvfw.jar is not an APK and has no package update route. Its integrity is
controlled by the verified system image and ART/shared-library integration.
What is still unknown
Philips signer custody/lineage, whether Philips will sign an external patch, their current build-tools versions, OTA payload keys and firmware container signing are unknown. They must be supplied by Philips or a documented accepted engineering/recovery chain; they cannot be inferred from public certificates.