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

1 files changed, 11 insertions, 0 deletions

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.