Update RulesManagerService after APEX files
Context ======= The "time zone updates via APK" feature was implemented in O-MR1 to enable devices to take time zone updates via an APK update and without needing an OTA. RulesManagerService is an important part of the time zone updates via APK feature. When RulesManagerService was implemented things were simple; there was a copy of time zone data in /system. A new (optional) copy was introduced in /data that could be managed / updated by the RulesManagerService. Since there were only two copies the /system copy was referred to as the "system" data. With the introduction of the runtime APEX and time zone data APEX things have become more complicated. Android devices can have time zone data in several places: 1 The copy in /system/usr/share/zoneinfo/ is partially complete and remains for legacy usecases, e.g. binaries that "know" about the /system path and cannot be updated, or binaries which run before /apex paths are mounted. 2 The copy in /apex/com.android.runtime/ is a complete set of time zone data that can be used by libraries on the device. 3 The copy in /apex/com.android.tzdata/ is the "overlay" copy for use when the time zone data APEX can be updated. For devices that can take APEX updates it will be present and is expected to start with the same version as present in /apex/com.android.runtime. Note: Nothing in the code *requires* this copy to be present but it is expected to be present in most cases. RulesManagerService is being kept around for devices that may not have the capability of updating their APEX files but which still want to update time zone data without taking an OTA. It is assumed that RulesManagerService will *only* be turned on in these situations and *not* when the time zone data in /apex/com.android.tzdata/ might actually be updated independently of the copy in /apex/com.android.runtime/. The RulesManagerService therefore adds the fourth copy of the data that *could* be present: 4 The copy /data/misc/zoneinfo/ managed by RulesManagerService. Important libraries / binaries on device know about all 4 copies and prioritize them in order 4, 3, 2, 1. i.e. the libraries will use the first copy of data found in that order. In scenarios where RulesManagerService is disabled, 4 will not be present and therefore 3 will be used (or 2 if 3 is also not present). In scenarios where RulesManagersService is enabled, 4 is present iff an APK update has been received. It is assumed that *if* /apex/com.android.tzdata/ is present, it contains the same version of tz data as in /apex/com.android.runtime/, will never be updated, and can therefore be ignored by RulesManagerService. The changes =========== This commit and others in the same topic do the following: 1) Change RulesManagerService references to "system" data to "base" data in a valiant attempt to limit confusion until it can be removed. 2) Switch RulesManagerService over from using the data in /system/usr/share/zoneinfo/ as base data to the data in /apex/com.android.runtime/. As part of this change, the RulesManagerService can now use the tz_version file to identify the version of tzdb in "base" rather than reading the header of the tzdata file, so that is done here too. 3) Update imports neccessary to meet pre-upload check requirements. Note: tzdatacheck, an independent binary that manages time zone data after OTA, was updated to use /apex/com.android.runtime/ instead of /system/usr/share/zoneinfo/ in commit c6a2737e0861472d1726ed472708d7762ab1e802. Bug: 119293618 Bug: 113373927 Test: atest FrameworksCoreTests:android.app.timezone Test: atest FrameworksServicesTests:com.android.server.timezone Test: CTS: run cts-dev -m CtsLibcoreTestCases -t libcore.libcore.timezone.ZoneInfoDBTest Test: CTS: run cts-dev -m CtsLibcoreTestCases -t libcore.libcore.icu.TimeZoneIntegrationTest Change-Id: Idabe245c7ad337938c202b1796ce9d89ec68bbd6
Loading
Please register or sign in to comment