From b18b55181f08fb62d07ecf33ebcc687a4191155d Mon Sep 17 00:00:00 2001 From: Martin Stjernholm Date: Fri, 8 Nov 2024 16:05:50 +0000 Subject: Add a comment to explain the API considerations for the pre-reboot dexopt usage of BatchDexoptParamsProto. Test: n/a - comment change only Bug: 356996742 Change-Id: I01f170a95aaf718891ad70efb2d0d77844840f5a --- libartservice/service/proto/batch_dexopt_params.proto | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'libartservice') diff --git a/libartservice/service/proto/batch_dexopt_params.proto b/libartservice/service/proto/batch_dexopt_params.proto index ac3d20849a..0cf9088728 100644 --- a/libartservice/service/proto/batch_dexopt_params.proto +++ b/libartservice/service/proto/batch_dexopt_params.proto @@ -19,6 +19,17 @@ syntax = "proto2"; package com.android.server.art.proto; option java_multiple_files = true; +// These protobufs are currently used as an ART-internal API for pre-reboot +// dexopt to pass parameters from a version of the ART module to a potentially +// more recent version in an OTA package. It's a 1:1 mapping to the +// BatchDexoptParams API used for (normal) batch dexopt. That approach does not +// add any extra compatibility constraints, because: a) We need to keep the +// BatchDexoptParams API for all SDK levels the ART module gets pushed to, and +// b) we only allow pre-reboot dexopt from SDK level N to N+1. Since (a) always +// has a longer support window than (b), we cannot end up in a situation where +// these protobufs forces us to keep support for a feature we wouldn't need to +// keep anyway for batch dexopt. + // The protobuf representation of `BatchDexoptParams`. See classes in // java/com/android/server/art/model/BatchDexoptParams.java and // java/com/android/server/art/model/DexoptParams.java for details. -- cgit v1.2.3-59-g8ed1b