Implement generic vendor-specific parameters.
This commit covers HAL changes only.
Bug: 65862441
Test: it builds
Change-Id: Ibd20e2a1db826a0dc3ade4fb9bd1cb830ee11f8d
diff --git a/broadcastradio/1.2/ITuner.hal b/broadcastradio/1.2/ITuner.hal
index ee8a45d..cc966fc 100644
--- a/broadcastradio/1.2/ITuner.hal
+++ b/broadcastradio/1.2/ITuner.hal
@@ -19,4 +19,50 @@
import @1.1::ITuner;
interface ITuner extends @1.1::ITuner {
+ /**
+ * Generic method for setting vendor-specific parameter values.
+ * The framework does not interpret the parameters, they are passed
+ * in an opaque manner between a vendor application and HAL.
+ *
+ * Framework does not make any assumptions on the keys or values, other than
+ * ones stated in VendorKeyValue documentation (a requirement of key
+ * prefixes).
+ *
+ * Results vector may not contain a result for each parameter being set,
+ * it can even be empty.
+ *
+ * Application and HAL must not use keys with unknown prefix. In particular,
+ * it must not place a key-value pair in results vector for unknown key from
+ * parameters vector - instead, an unknown key should simply be ignored.
+ * In other words, results vector may contain a subset of parameter keys
+ * (however, the framework doesn't enforce a strict subset - the only
+ * formal requirement is vendor domain prefix for keys).
+ *
+ * @param parameters Vendor-specific key-value pairs.
+ * @return results Operation completion status for parameters being set.
+ * Value format for result status is vendor-specific.
+ */
+ setParameters(vec<VendorKeyValue> parameters)
+ generates (vec<VendorKeyValue> results);
+
+ /**
+ * Generic method for retrieving vendor-specific parameter values.
+ * The framework does not interpret the parameters, they are passed
+ * in an opaque manner between a vendor application and HAL.
+ *
+ * Framework does not cache set/get requests, so it's allowed for
+ * getParameter to return a different value than previous setParameter call.
+ *
+ * The syntax and semantics of keys are up to the vendor (as long as prefix
+ * rules are obeyed). For instance, vendors may include some form of
+ * wildcard support. In such case, result vector may be of different size
+ * than requested keys vector. However, wildcards are not recognized by
+ * framework and they are passed as-is to the HAL implementation.
+ *
+ * Unknown keys must be ignored and not placed into results vector.
+ *
+ * @param keys Parameter keys to fetch.
+ * @return parameters Vendor-specific key-value pairs.
+ */
+ getParameters(vec<string> keys) generates (vec<VendorKeyValue> parameters);
};