1: Check the presence of the file 'prefetch_ready'. If it doesn't exist then the device is booting for the first time after wipe. Thus, we would just create the file and exit as we do not want to initiate the record after data wipe primiarly because boot after data wipe is long and the I/O pattern during first boot may not actually match with subsequent boot. 2: If the file 'prefetch_ready' is present: a: Compare the build-finger-print of the device with the one record format is associated with by reading the file 'build_finger_print'. If they match, start the prefetch_replay. b: If they don't match, then the device was updated through OTA. Hence, start a fresh record and delete the build-finger-print file. This should also cover the case of device rollback. c: If the build-finger-print file doesn't exist, then just restart the record from scratch. Bug: 362507272 Test: Prefetch record/replay Change-Id: I90b861ba9381ddba6ab7dedb9930a735e55b0e5d Signed-off-by: Akilesh Kailash <akailash@google.com>
29 lines
715 B
Text
29 lines
715 B
Text
on init && property:ro.prefetch_boot.enabled=true
|
|
start prefetch
|
|
|
|
service prefetch /system/bin/prefetch start
|
|
class main
|
|
user root
|
|
group root system
|
|
disabled
|
|
oneshot
|
|
|
|
on property:ro.prefetch_boot.record=true
|
|
start prefetch_record
|
|
|
|
service prefetch_record /system/bin/prefetch record --duration ${ro.prefetch_boot.duration_s:-0}
|
|
class main
|
|
user root
|
|
group root system
|
|
disabled
|
|
oneshot
|
|
|
|
on property:ro.prefetch_boot.replay=true
|
|
start prefetch_replay
|
|
|
|
service prefetch_replay /system/bin/prefetch replay --io-depth ${ro.prefetch_boot.io_depth:-2} --max-fds ${ro.prefetch_boot.max_fds:-128}
|
|
class main
|
|
user root
|
|
group root system
|
|
disabled
|
|
oneshot
|