diff options
| author | 2024-08-15 10:45:50 -0700 | |
|---|---|---|
| committer | 2024-09-06 11:45:04 +0000 | |
| commit | 3fe46365cefb859051656faf069aa3cd446510bb (patch) | |
| tree | 74ee05abb268ee6ed8c63918f49031564c4d9869 /compiler/optimizing/instruction_builder.cc | |
| parent | 114656eb2ff4de7a774d4cdd1e4db6b94647bbce (diff) | |
Don't filter default package list for first boot dexopt
commit 20a8542b513a ("Implement app downgrading.") added filtering of the
list of packages to dexopt and for REASON_FIRST_BOOT this filtered the
list of packages based on last active time which is determined as the
maximum of a package's last used time and first install time. During
first boot a package's last used time is 0 so the last active time is
based on a package's installation time which after
commit cbd2f357c218 ("[pm] use actual scanning time as firstInstallTime
for preload apps") in frameworks/base when fix_system_apps_first_install_time
is enabled is set to the current time as returned by
System.currentTimeMillis() when packages are being installed during
PackageManagerService startup. This can be a problem during first boot if
pm.dexopt.downgrade_after_inactive_days is set because in this
case packages with a last active time (installation time in this case) more
than pm.dexopt.downgrade_after_inactive_days in the past will be be filtered
out of the default package list and not dexopted and this filtering is
done relative to the current time as returned by
System.currentTimeMillis() which in some cases will have been advanced by
AlarmManagerService after package installation to the build time as set
in ro.build.date.utc. This can happen on some devices, for example, when
the RTC has never been set correctly or is set to a time more than
pm.dexopt.downgrade_after_inactive_days prior to the build time in
ro.build.date.utc as kernels with CONFIG_RTC_HCTOSYS enabled will set
the system time using the value read from the RTC during kernel init and
this will be the time used to set the first install time for packages
and will later cause AlarmManagerService to advance the system time
prior to first boot dexopt. Fix these cases as well by not doing any
filtering for first boot dexopt.
Test: Set pm.dexopt.downgrade_after_inactive_days=10 on
aosp_cheetah-trunk_staging-userdebug and set system time to more than 10
days in the past and confirm with debugger and ART Service logging that
there are now packages being dexopted:
adb shell 'date @1723857773' && adb shell hwclock -w && adb reboot
bootloader && fastboot flashall -w
Test: atest ArtServiceTests
Change-Id: I4ebd74766cfe21db4001b44bd292cc042a8e23f0
Diffstat (limited to 'compiler/optimizing/instruction_builder.cc')
0 files changed, 0 insertions, 0 deletions