2.2 KiB
Phase 7I – tvfw.jar ART/preopt analysis
Inventory
| Artifact | Bytes | SHA-256 |
|---|---|---|
/system/framework/tvfw.jar |
3,275,657 | a0061795d87cf76c9b739e32022ab3d8c29f47ed01ddc1eee189dd815a8d11ad |
/system/framework/oat/arm/tvfw.odex |
37,540 | a4af432c54153c9325d92f338f93b2b0a6cfa6b618a5d2c31d587e93eceff531 |
/system/framework/oat/arm/tvfw.vdex |
51,572 | abd0f4ce99404199332a779b195c53ca57d2238d0368910b0936cd55a8572509 |
No adjacent .art file was observed. tvfw.jar contains one DEX and is
registered as the Java shared library tvfw.
Boot criticality
Live environment inspection shows tvfw is in neither BOOTCLASSPATH nor
SYSTEMSERVERCLASSPATH. It is therefore not itself part of the boot image and
is not a direct system_server boot classpath input. This narrows, but does not
remove, risk: numerous Philips TV applications load it through their
PathClassLoader. Bugreport logs include a shared-library class-loader-context
size mismatch involving tvstrings, tvwidgets, tvfw and javax.obex.
Can ART regenerate it?
For a PackageManager-managed /data/app APK update, ART normally creates
data-side compiled artifacts. tvfw.jar is different: it is system image
shared-library content with stock ARM ODEX/VDEX and client class-loader
contexts. /data/dalvik-cache/arm was inaccessible to shell, so a working
fallback for a modified system JAR is not device-proven.
Possible build choices are:
- regenerate matching ARM32 ODEX/VDEX and all affected class-loader contexts in the OEM build; or
- deliberately omit stale preopt outputs and validate boot-time/dexopt fallback in an otherwise correctly signed system image.
Blindly replacing the JAR while leaving stock ODEX/VDEX is unsafe. A checksum mismatch may cause rejection/recompilation, while a class-loader-context or API mismatch can crash many client processes. Neither outcome is a production plan.
Conclusion
tvfw.jar is not realistically deployable as an isolated file. It needs a
coherent system-image/OEM-build path, compatible clients/preopt, SELinux/file
metadata and AVB. It is less likely than a bootclasspath JAR to stop
system_server directly, but the blast radius across TV apps is high.