Be more defensive around invalid tzids
Add checks during boot in case the persist.sys.timezone property is set to a bad ID. This can happen in the rare case of a mainline rollback: i.e. if a device has been set to a new ID and then the update is rolled back. Using GMT as a fallback probably works without this change (it does in java.util.TimeZone), but relies on all code, including native code that uses persist.sys.timezone directly, knowing to interpret a bad ID as "GMT". This commit makes that choice more explicit and defensive. This change also removes the possibility of IOException, which is never thrown, from some ZoneInfoDb methods. Bug: 155738410 Test: boot with a valid id, verify persist.sys.timezone is unchanged Test: boot with an invalid id set, verify persist.sys.timezone is "GMT" Merged-In: I6dc0f4f81848efbbaec6a11a62014471a0ef01fd Change-Id: I6dc0f4f81848efbbaec6a11a62014471a0ef01fd Exempt-From-Owner-Approval: Approved / landed internally
Loading
Please register or sign in to comment