The tzdatacheck binary is being modified to support
"staging" of an install / uninstall. tzdatacheck is now
responsible for making time zone distros "live" during
boot. It was previously the responsibility of the
TimeZoneDistroInstaller.
Bug: 31008728
Test: Manual testing
Test: CTS: run cts -m CtsHostTzDataTests
Change-Id: I1d390bf2b383a9505320e3455a20ae640bf83d7b
Some classes referenced in comments in libcore.tzdata.update2 have
moved to libcore.tzdata.shared2.
Bug: 31008728
Test: mmm system/core/tzdatacheck
Change-Id: I390b375ab8fefbb46e69f4534000ff43ffcceae8
Tweaks for documentation. Mostly to point out that the constants
are duplicated in Java code.
Bug: 31008728
Test: mmm tzdatacheck
Change-Id: I068c09cfc6109a7567ad7e08edcecad40be831b3
Renaming "Bundle" to "Distro" because bundle is confusing
given android.os.Bundle.
Bug: 31008728
Test: mmm tzdatacheck
Change-Id: I70408678d67eed9f9e0424c0791e856c909837be
Change tzdatacheck to account for bundle format changes:
The update bundle now contains a bundle_version file to enable
us to detect changes to the format of the files in addition to
just checking the IANA rules version. The version will be
incremented as we make incompatible changes to the structure
of the bundle (e.g. the files present or their names), the
file formats or the file contents.
The old assumption was that a system image would typically
contain newer rules than had been pushed via ConfigUpdater
and we'd never get rid of the tzdata file from the bundle
content.
If Android makes rule updates routinely or makes substantial
changes to the timezone data files between major releases
then this assumption becomes (even more) untenable.
The bundle_version file in the bundle is expected to contain
the ASCII bytes for "001". This could be extended
in a future version to include minor versioning information
(e.g. "002.001") and so the code here only reads the first
three bytes. This allows for a future change to add the minor
version suffix and optionally increment the major version if
required.
Some error conditions that were previously treated as fatal
are now handled more elegantly. Generally if things are not
as expected with the installed bundle in /data tzdatacheck
will attempt to delete it. The return code of the binary is
used to distinguish between failure cases, which will be
used in a future automated test.
Some of the ConfigUpdater deletion code has been temporarily
retained (with a TODO) so the v2 of the installer code can be
used with ConfigUpdater/ConfigInstaller and keep something
like the existing process working until we have replaced it
with some thing better.
Using the v2 installer code with ConfigInstaller is one
possible fallback if the new distribution approach is not
completed in time.
Bug: 31008728
Test: Manual testing
Change-Id: Ib253f7d4c9cd72d3e392754f4b787a98ec22bc53
tzdatacheck is exec'd from init.rc early in boot just after /data is
mounted. It checks to make sure that the tz rule data in /data
is newer than the version in /system. If the data is older it is
deleted. This is to address problems with earlier tz rule updates
that occurred: after an OTA upgrade previous updates in /data
would override newer versions in the system partition.
Includes change to init.rc neccessary to run it at boot time. Other
changes are in external/selinux.
Bug: 19941636
Bug: https://code.google.com/p/android/issues/detail?id=35730
Change-Id: I7cc61e058424c856da88f11ff9b259f34cb39dc7
