diff --git a/bluetooth/audio/aidl/TEST_MAPPING b/bluetooth/audio/aidl/TEST_MAPPING
new file mode 100644
index 0000000..0c853f8
--- /dev/null
+++ b/bluetooth/audio/aidl/TEST_MAPPING
@@ -0,0 +1,12 @@
+{
+  "presubmit": [
+    {
+      "name": "VtsHalBluetoothAudioTargetTest"
+    }
+  ],
+  "kernel-presubmit": [
+    {
+      "name": "VtsHalBluetoothAudioTargetTest"
+    }
+  ]
+}
diff --git a/compatibility_matrices/compatibility_matrix.9.xml b/compatibility_matrices/compatibility_matrix.9.xml
index 3f09b61..e23f2ae 100644
--- a/compatibility_matrices/compatibility_matrix.9.xml
+++ b/compatibility_matrices/compatibility_matrix.9.xml
@@ -142,7 +142,7 @@
             <instance>default</instance>
         </interface>
     </hal>
-    <hal format="aidl" optional="true">
+    <hal format="aidl" optional="true" updatable-via-apex="true">
         <name>android.hardware.biometrics.fingerprint</name>
         <version>2</version>
         <interface>
@@ -150,14 +150,6 @@
             <instance>default</instance>
         </interface>
     </hal>
-    <hal format="hidl" optional="true">
-        <name>android.hardware.bluetooth</name>
-        <version>1.0-1</version>
-        <interface>
-            <name>IBluetoothHci</name>
-            <instance>default</instance>
-        </interface>
-    </hal>
     <hal format="aidl" optional="true">
         <name>android.hardware.bluetooth</name>
         <interface>
@@ -637,14 +629,6 @@
             <instance>default</instance>
         </interface>
     </hal>
-    <hal format="hidl" optional="true">
-        <name>android.hardware.soundtrigger</name>
-        <version>2.3</version>
-        <interface>
-            <name>ISoundTriggerHw</name>
-            <instance>default</instance>
-        </interface>
-    </hal>
     <hal format="aidl" optional="true">
          <name>android.hardware.soundtrigger3</name>
          <version>1</version>
@@ -653,22 +637,6 @@
              <instance>default</instance>
          </interface>
     </hal>
-    <hal format="hidl" optional="true">
-        <name>android.hardware.tetheroffload.config</name>
-        <version>1.0</version>
-        <interface>
-            <name>IOffloadConfig</name>
-            <instance>default</instance>
-        </interface>
-    </hal>
-    <hal format="hidl" optional="true">
-        <name>android.hardware.tetheroffload.control</name>
-        <version>1.1</version>
-        <interface>
-            <name>IOffloadControl</name>
-            <instance>default</instance>
-        </interface>
-    </hal>
     <hal format="aidl" optional="true">
         <name>android.hardware.tetheroffload</name>
         <version>1</version>
diff --git a/graphics/composer/2.4/vts/functional/TEST_MAPPING b/graphics/composer/2.4/vts/functional/TEST_MAPPING
new file mode 100644
index 0000000..aedac5b
--- /dev/null
+++ b/graphics/composer/2.4/vts/functional/TEST_MAPPING
@@ -0,0 +1,13 @@
+{
+  "presubmit": [
+    {
+      "name": "VtsHalGraphicsComposerV2_4TargetTest"
+    }
+  ],
+  "kernel-presubmit": [
+    {
+      "name": "VtsHalGraphicsComposerV2_4TargetTest"
+    }
+  ]
+}
+
diff --git a/security/keymint/aidl/vts/functional/AuthTest.cpp b/security/keymint/aidl/vts/functional/AuthTest.cpp
index 78c88f4..290e8fc 100644
--- a/security/keymint/aidl/vts/functional/AuthTest.cpp
+++ b/security/keymint/aidl/vts/functional/AuthTest.cpp
@@ -93,17 +93,21 @@
     void TearDown() {
         if (gk_ == nullptr) return;
         gk_->deleteUser(uid_);
+        if (alt_uid_ != 0) {
+            gk_->deleteUser(alt_uid_);
+        }
     }
 
     bool GatekeeperAvailable() { return (gk_ != nullptr) || (hidl_gk_ != nullptr); }
 
-    std::optional<GatekeeperEnrollResponse> doEnroll(const std::vector<uint8_t>& newPwd,
+    std::optional<GatekeeperEnrollResponse> doEnroll(uint32_t uid,
+                                                     const std::vector<uint8_t>& newPwd,
                                                      const std::vector<uint8_t>& curHandle = {},
                                                      const std::vector<uint8_t>& curPwd = {}) {
         if (gk_ != nullptr) {
             while (true) {
                 GatekeeperEnrollResponse rsp;
-                Status status = gk_->enroll(uid_, curHandle, curPwd, newPwd, &rsp);
+                Status status = gk_->enroll(uid, curHandle, curPwd, newPwd, &rsp);
                 if (!status.isOk() && status.getExceptionCode() == EX_SERVICE_SPECIFIC &&
                     status.getServiceSpecificError() == IGatekeeper::ERROR_RETRY_TIMEOUT) {
                     sleep(1);
@@ -120,7 +124,7 @@
             while (true) {
                 HidlGatekeeperResponse rsp;
                 auto status = hidl_gk_->enroll(
-                        uid_, curHandle, curPwd, newPwd,
+                        uid, curHandle, curPwd, newPwd,
                         [&rsp](const HidlGatekeeperResponse& cbRsp) { rsp = cbRsp; });
                 if (!status.isOk()) {
                     GTEST_LOG_(ERROR) << "doEnroll(HIDL) failed";
@@ -155,20 +159,23 @@
         }
     }
 
-    std::optional<GatekeeperEnrollResponse> doEnroll(const string& newPwd,
+    std::optional<GatekeeperEnrollResponse> doEnroll(uint32_t uid, const string& newPwd,
                                                      const std::vector<uint8_t>& curHandle = {},
                                                      const string& curPwd = {}) {
-        return doEnroll(std::vector<uint8_t>(newPwd.begin(), newPwd.end()), curHandle,
+        return doEnroll(uid, std::vector<uint8_t>(newPwd.begin(), newPwd.end()), curHandle,
                         std::vector<uint8_t>(curPwd.begin(), curPwd.end()));
     }
+    std::optional<GatekeeperEnrollResponse> doEnroll(const string& newPwd) {
+        return doEnroll(uid_, newPwd);
+    }
 
-    std::optional<HardwareAuthToken> doVerify(uint64_t challenge,
+    std::optional<HardwareAuthToken> doVerify(uint32_t uid, uint64_t challenge,
                                               const std::vector<uint8_t>& handle,
                                               const std::vector<uint8_t>& pwd) {
         if (gk_ != nullptr) {
             while (true) {
                 GatekeeperVerifyResponse rsp;
-                Status status = gk_->verify(uid_, challenge, handle, pwd, &rsp);
+                Status status = gk_->verify(uid, challenge, handle, pwd, &rsp);
                 if (!status.isOk() && status.getExceptionCode() == EX_SERVICE_SPECIFIC &&
                     status.getServiceSpecificError() == IGatekeeper::ERROR_RETRY_TIMEOUT) {
                     sleep(1);
@@ -185,7 +192,7 @@
             while (true) {
                 HidlGatekeeperResponse rsp;
                 auto status = hidl_gk_->verify(
-                        uid_, challenge, handle, pwd,
+                        uid, challenge, handle, pwd,
                         [&rsp](const HidlGatekeeperResponse& cbRsp) { rsp = cbRsp; });
                 if (!status.isOk()) {
                     GTEST_LOG_(ERROR) << "doVerify(HIDL) failed";
@@ -220,10 +227,15 @@
             return std::nullopt;
         }
     }
+    std::optional<HardwareAuthToken> doVerify(uint32_t uid, uint64_t challenge,
+                                              const std::vector<uint8_t>& handle,
+                                              const string& pwd) {
+        return doVerify(uid, challenge, handle, std::vector<uint8_t>(pwd.begin(), pwd.end()));
+    }
     std::optional<HardwareAuthToken> doVerify(uint64_t challenge,
                                               const std::vector<uint8_t>& handle,
                                               const string& pwd) {
-        return doVerify(challenge, handle, std::vector<uint8_t>(pwd.begin(), pwd.end()));
+        return doVerify(uid_, challenge, handle, pwd);
     }
 
     // Variants of the base class methods but with authentication information included.
@@ -268,6 +280,13 @@
         return plaintext;
     }
 
+    string SignMessage(const vector<uint8_t>& key_blob, const string& message,
+                       const AuthorizationSet& in_params, AuthorizationSet* out_params,
+                       const HardwareAuthToken& hat) {
+        SCOPED_TRACE("SignMessage");
+        return ProcessMessage(key_blob, KeyPurpose::SIGN, message, in_params, out_params, hat);
+    }
+
   protected:
     std::shared_ptr<IGatekeeper> gk_;
     sp<IHidlGatekeeper> hidl_gk_;
@@ -275,6 +294,8 @@
     string password_;
     uint32_t uid_;
     int64_t sid_;
+    uint32_t alt_uid_;
+    int64_t alt_sid_;
     std::vector<uint8_t> handle_;
 };
 
@@ -347,6 +368,116 @@
     }
 }
 
+// Test use of a key that requires user-authentication within recent history, but where
+// the `TimestampToken` provided to the device is unrelated to the in-progress operation.
+TEST_P(AuthTest, TimeoutAuthenticationIncorrectTimestampToken) {
+    if (!GatekeeperAvailable()) {
+        GTEST_SKIP() << "No Gatekeeper available";
+    }
+    if (!timestamp_token_required_) {
+        GTEST_SKIP() << "Test only applies to devices with no secure clock";
+    }
+    if (clock_ == nullptr) {
+        GTEST_SKIP() << "Device requires timestamps and no ISecureClock available";
+    }
+
+    // Create an AES key that requires authentication within the last 3 seconds.
+    const uint32_t timeout_secs = 3;
+    auto builder = AuthorizationSetBuilder()
+                           .AesEncryptionKey(256)
+                           .BlockMode(BlockMode::ECB)
+                           .Padding(PaddingMode::PKCS7)
+                           .Authorization(TAG_USER_SECURE_ID, sid_)
+                           .Authorization(TAG_USER_AUTH_TYPE, HardwareAuthenticatorType::PASSWORD)
+                           .Authorization(TAG_AUTH_TIMEOUT, timeout_secs);
+    vector<uint8_t> keyblob;
+    vector<KeyCharacteristics> key_characteristics;
+    vector<Certificate> cert_chain;
+    ASSERT_EQ(ErrorCode::OK,
+              GenerateKey(builder, std::nullopt, &keyblob, &key_characteristics, &cert_chain));
+
+    // Verify to get a HAT, arbitrary challenge.
+    const uint64_t challenge = 42;
+    const std::optional<HardwareAuthToken> hat = doVerify(challenge, handle_, password_);
+    ASSERT_TRUE(hat.has_value());
+    EXPECT_EQ(hat->userId, sid_);
+
+    // KeyMint implementation has no clock, so only detects timeout via timestamp token provided
+    // on update()/finish().  However, for this test we ensure that that the timestamp token has a
+    // *different* challenge value.
+    const string message = "Hello World!";
+    auto params = AuthorizationSetBuilder().BlockMode(BlockMode::ECB).Padding(PaddingMode::PKCS7);
+    AuthorizationSet out_params;
+    ASSERT_EQ(ErrorCode::OK, Begin(KeyPurpose::ENCRYPT, keyblob, params, &out_params, hat));
+
+    secureclock::TimeStampToken time_token;
+    EXPECT_EQ(ErrorCode::OK,
+              GetReturnErrorCode(clock_->generateTimeStamp(challenge_ + 1, &time_token)));
+    string output;
+    EXPECT_EQ(ErrorCode::KEY_USER_NOT_AUTHENTICATED,
+              Finish(message, {} /* signature */, &output, hat, time_token));
+}
+
+// Test use of a key with multiple USER_SECURE_ID values.  For variety, use an EC signing key
+// generated with attestation.
+TEST_P(AuthTest, TimeoutAuthenticationMultiSid) {
+    if (!GatekeeperAvailable()) {
+        GTEST_SKIP() << "No Gatekeeper available";
+    }
+    if (timestamp_token_required_ && clock_ == nullptr) {
+        GTEST_SKIP() << "Device requires timestamps and no ISecureClock available";
+    }
+
+    // Enroll a password for a second user.
+    alt_uid_ = 20001;
+    const string alt_password = "correcthorsebatterystaple2";
+    std::optional<GatekeeperEnrollResponse> rsp = doEnroll(alt_uid_, alt_password);
+    ASSERT_TRUE(rsp.has_value());
+    alt_sid_ = rsp->secureUserId;
+    const std::vector<uint8_t> alt_handle = rsp->data;
+
+    // Create an attested EC key that requires authentication within the last 3 seconds from either
+    // secure ID. Also allow any authenticator type.
+    const uint32_t timeout_secs = 3;
+    auto builder = AuthorizationSetBuilder()
+                           .EcdsaSigningKey(EcCurve::P_256)
+                           .Digest(Digest::NONE)
+                           .Digest(Digest::SHA_2_256)
+                           .SetDefaultValidity()
+                           .AttestationChallenge("challenge")
+                           .AttestationApplicationId("app_id")
+                           .Authorization(TAG_USER_SECURE_ID, alt_sid_)
+                           .Authorization(TAG_USER_SECURE_ID, sid_)
+                           .Authorization(TAG_USER_AUTH_TYPE, HardwareAuthenticatorType::ANY)
+                           .Authorization(TAG_AUTH_TIMEOUT, timeout_secs);
+    vector<uint8_t> keyblob;
+    vector<KeyCharacteristics> key_characteristics;
+    vector<Certificate> cert_chain;
+    ASSERT_EQ(ErrorCode::OK,
+              GenerateKey(builder, std::nullopt, &keyblob, &key_characteristics, &cert_chain));
+
+    // Verify first user to get a HAT that should work.
+    const uint64_t challenge = 42;
+    const std::optional<HardwareAuthToken> hat = doVerify(uid_, challenge, handle_, password_);
+    ASSERT_TRUE(hat.has_value());
+    EXPECT_EQ(hat->userId, sid_);
+
+    const string message = "Hello World!";
+    auto params = AuthorizationSetBuilder().Digest(Digest::SHA_2_256);
+    AuthorizationSet out_params;
+    const string signature = SignMessage(keyblob, message, params, &out_params, hat.value());
+
+    // Verify second user to get a HAT that should work.
+    const uint64_t alt_challenge = 43;
+    const std::optional<HardwareAuthToken> alt_hat =
+            doVerify(alt_uid_, alt_challenge, alt_handle, alt_password);
+    ASSERT_TRUE(alt_hat.has_value());
+    EXPECT_EQ(alt_hat->userId, alt_sid_);
+
+    const string alt_signature =
+            SignMessage(keyblob, message, params, &out_params, alt_hat.value());
+}
+
 // Test use of a key that requires an auth token for each action on the operation, with
 // a per-operation challenge value included.
 TEST_P(AuthTest, AuthPerOperation) {
@@ -407,6 +538,93 @@
               Finish(message, {} /* signature */, &ciphertext, hat.value()));
 }
 
+// Test use of a key that requires an auth token for each action on the operation, with
+// a per-operation challenge value included, with multiple secure IDs allowed.
+TEST_P(AuthTest, AuthPerOperationMultiSid) {
+    if (!GatekeeperAvailable()) {
+        GTEST_SKIP() << "No Gatekeeper available";
+    }
+
+    // Enroll a password for a second user.
+    alt_uid_ = 20001;
+    const string alt_password = "correcthorsebatterystaple2";
+    std::optional<GatekeeperEnrollResponse> rsp = doEnroll(alt_uid_, alt_password);
+    ASSERT_TRUE(rsp.has_value());
+    alt_sid_ = rsp->secureUserId;
+    const std::vector<uint8_t> alt_handle = rsp->data;
+
+    // Create an AES key that requires authentication per-action.
+    auto builder = AuthorizationSetBuilder()
+                           .AesEncryptionKey(256)
+                           .BlockMode(BlockMode::ECB)
+                           .Padding(PaddingMode::PKCS7)
+                           .Authorization(TAG_USER_SECURE_ID, sid_)
+                           .Authorization(TAG_USER_SECURE_ID, alt_sid_)
+                           .Authorization(TAG_USER_AUTH_TYPE, HardwareAuthenticatorType::ANY);
+    vector<uint8_t> keyblob;
+    vector<KeyCharacteristics> key_characteristics;
+    vector<Certificate> cert_chain;
+    ASSERT_EQ(ErrorCode::OK,
+              GenerateKey(builder, std::nullopt, &keyblob, &key_characteristics, &cert_chain));
+
+    // Get a HAT for first user with the challenge from an in-progress operation.
+    const string message = "Hello World!";
+    auto params = AuthorizationSetBuilder().BlockMode(BlockMode::ECB).Padding(PaddingMode::PKCS7);
+    AuthorizationSet out_params;
+    EXPECT_EQ(ErrorCode::OK, Begin(KeyPurpose::ENCRYPT, keyblob, params, &out_params));
+    const std::optional<HardwareAuthToken> hat = doVerify(uid_, challenge_, handle_, password_);
+    ASSERT_TRUE(hat.has_value());
+    EXPECT_EQ(hat->userId, sid_);
+    string ciphertext;
+    EXPECT_EQ(ErrorCode::OK, Finish(message, {} /* signature */, &ciphertext, hat.value()));
+
+    // Get a HAT for second user with the challenge from an in-progress operation.
+    EXPECT_EQ(ErrorCode::OK, Begin(KeyPurpose::ENCRYPT, keyblob, params, &out_params));
+    const std::optional<HardwareAuthToken> alt_hat =
+            doVerify(alt_uid_, challenge_, alt_handle, alt_password);
+    ASSERT_TRUE(alt_hat.has_value());
+    EXPECT_EQ(alt_hat->userId, alt_sid_);
+    string alt_ciphertext;
+    EXPECT_EQ(ErrorCode::OK, Finish(message, {} /* signature */, &ciphertext, alt_hat.value()));
+}
+
+// Test use of a key that requires an auth token for each action on the operation, but
+// which gets passed a HAT of the wrong type
+TEST_P(AuthTest, AuthPerOperationWrongAuthType) {
+    if (!GatekeeperAvailable()) {
+        GTEST_SKIP() << "No Gatekeeper available";
+    }
+
+    // Create an AES key that requires authentication per-action, but with no valid authenticator
+    // types.
+    auto builder =
+            AuthorizationSetBuilder()
+                    .AesEncryptionKey(256)
+                    .BlockMode(BlockMode::ECB)
+                    .Padding(PaddingMode::PKCS7)
+                    .Authorization(TAG_USER_SECURE_ID, sid_)
+                    .Authorization(TAG_USER_AUTH_TYPE, HardwareAuthenticatorType::FINGERPRINT);
+    vector<uint8_t> keyblob;
+    vector<KeyCharacteristics> key_characteristics;
+    vector<Certificate> cert_chain;
+    ASSERT_EQ(ErrorCode::OK,
+              GenerateKey(builder, std::nullopt, &keyblob, &key_characteristics, &cert_chain));
+
+    // Get a HAT with the challenge from an in-progress operation.
+    const string message = "Hello World!";
+    auto params = AuthorizationSetBuilder().BlockMode(BlockMode::ECB).Padding(PaddingMode::PKCS7);
+    AuthorizationSet out_params;
+    EXPECT_EQ(ErrorCode::OK, Begin(KeyPurpose::ENCRYPT, keyblob, params, &out_params));
+    const std::optional<HardwareAuthToken> hat = doVerify(challenge_, handle_, password_);
+    ASSERT_TRUE(hat.has_value());
+    EXPECT_EQ(hat->userId, sid_);
+
+    // Should fail because auth type doesn't (can't) match.
+    string ciphertext;
+    EXPECT_EQ(ErrorCode::KEY_USER_NOT_AUTHENTICATED,
+              Finish(message, {} /* signature */, &ciphertext, hat.value()));
+}
+
 INSTANTIATE_KEYMINT_AIDL_TEST(AuthTest);
 
 }  // namespace aidl::android::hardware::security::keymint::test
diff --git a/security/keymint/aidl/vts/functional/KeyMintAidlTestBase.cpp b/security/keymint/aidl/vts/functional/KeyMintAidlTestBase.cpp
index e51bb6e..b55e609 100644
--- a/security/keymint/aidl/vts/functional/KeyMintAidlTestBase.cpp
+++ b/security/keymint/aidl/vts/functional/KeyMintAidlTestBase.cpp
@@ -1606,7 +1606,8 @@
     auto res = property_get("ro.vendor.qti.soc_model", buffer.data(), nullptr);
     if (res <= 0) return false;
 
-    const string allowed_soc_models[] = {"SM8450", "SM8475", "SM8550", "SXR2230P"};
+    const string allowed_soc_models[] = {"SM8450", "SM8475", "SM8550", "SXR2230P",
+                                         "SM4450", "SM7450", "SM6450"};
 
     for (const string model : allowed_soc_models) {
         if (model.compare(buffer.data()) == 0) {
diff --git a/security/rkp/README.md b/security/rkp/README.md
index a966141..f8e1d5e 100644
--- a/security/rkp/README.md
+++ b/security/rkp/README.md
@@ -3,7 +3,7 @@
 ## Objective
 
 Design a HAL to support over-the-air provisioning of certificates for asymmetric
-keys. The HAL must interact effectively with Keystore (and other daemons) and
+keys. The HAL must interact effectively with Keystore (and other services) and
 protect device privacy and security.
 
 Note that this API was originally designed for KeyMint, with the intention that
@@ -20,125 +20,52 @@
 To more securely and reliably get keys and certificates to Android devices, we
 need to create a system where no party outside of the device's secure components
 is responsible for managing private keys. The strategy we've chosen is to
-deliver certificates over the air, using an asymmetric key pair created
-on-device in the factory as a root of trust to create an authenticated, secure
-channel. In this document we refer to this device-unique asymmetric key pair as
-Device Key (DK), its public half DK\_pub, its private half DK\_priv and a Device
-Key Certificate containing DK\_pub is denoted DKC.
+deliver certificates over the air, using an asymmetric key pair derived from a
+unique device secret (UDS) as a root of trust for authenticated requests from
+the secure components. We refer to the public half of this asymmetric key pair
+as UDS\_pub.
 
-In order for the provisioning service to use DK (or a key authenticated by DK),
-it must know whether a given DK\_pub is known and trusted. To prove trust, we
-ask device OEMs to use one of two mechanisms:
+In order for the provisioning service to trust UDS\_pub we ask device OEMs to
+use one of two mechanisms:
 
-1.  (Preferred, recommended) The device OEM extracts DK\_pub from each device it
-    manufactures and uploads the public keys to a backend server.
+1.  (Preferred, recommended) The device OEM extracts the UDS\_pub from each
+    device they manufacture and uploads the public keys to a backend server.
 
-1.  The device OEM signs the DK\_pub to produce DKC and stores it on the device.
-    This has the advantage that they don't need to upload a DK\_pub for every
-    device immediately, but the disadvantage that they have to manage their
-    private signing keys, which means they have to have HSMs, configure and
-    secure them correctly, etc. Some backend providers may also require that the
-    OEM passes a factory security audit, and additionally promises to upload the
-    keys eventually as well.
+1.  The device OEM signs the UDS\_pub and stores the certificates on the device
+    rather than uploading a UDS\_pub for every device immediately. However,
+    there are many disadvantages and costs associated with this option as the
+    OEM will need to pass a security audit of their factory's physical security,
+    CA and HSM configuration, and incident response processes before the OEM's
+    public key is registered with the provisioning server.
 
-Note that in the full elaboration of this plan, DK\_pub is not the key used to
-establish a secure channel. Instead, DK\_pub is just the first public key in a
-chain of public keys which ends with the KeyMint public key, KM\_pub. All keys
-in the chain are device-unique and are joined in a certificate chain called the
-_Boot Certificate Chain_ (BCC), because in phases 2 and 3 of the remote
-provisioning project it is a chain of certificates corresponding to boot phases.
-We speak of the BCC even for phase 1, though in phase 1 it contains only a
-single self-signed DKC. This is described in more depth in the Phases section
-below.
-
-The BCC is authenticated by DK\_pub. To authenticate DK\_pub, we may have
-additional DKCs, from the SoC vendor, the device OEM, or both. Those are not
-part of the BCC but included as optional fields in the certificate request
-structure.
-
-The format of the the DK and BCC is specified within [Open Profile for DICE]
-(https://pigweed.googlesource.com/open-dice/+/HEAD/docs/specification.md).  To
-map phrases within this document to their equivalent terminology in the DICE
-specification, read the terms as follows: the DK corresponds to the UDS-derived
-key pair, DKC corresponds to the UDS certificate, and the BCC entries between
-DK\_pub and KM\_pub correspond to a chain of CDI certificates.
-
-Note: In addition to allowing 32 byte hash values for fields in the BCC payload,
-this spec additionally constrains some of the choices allowed in open-DICE.
-Specifically, these include which entries are required and which are optional in
-the BCC payload, and which algorithms are acceptable for use.
+Note that in the full elaboration of this plan, UDS\_pub is not the key used to
+sign certificate requests. Instead, UDS\_pub is just the first public key in a
+chain of public keys that end the KeyMint public key. All keys in the chain are
+transitively derived from the UDS and joined in a certificate chain following
+the specification of the [Android Profile for DICE](#android-profile-for-dice).
 
 ### Phases
 
-RKP will be deployed in three phases, in terms of managing the root of trust
+RKP will be deployed with phased management of the root of trust
 binding between the device and the backend. To briefly describe them:
 
-* Phase 1: In phase 1 there is only one entry in the BCC; DK_pub and KM_pub are
-  the same key and the certificate is self-signed.
-* Phase 2: This is identical to phase 1, except it leverages the hardware root
-  of trust process described by DICE. Instead of trust being rooted in the TEE,
-  it is now rooted in the ROM by key material blown into fuses which are only
-  accessible to the ROM code.
-* Phase 3: This is identical to Phase 2, except the SoC vendor also does the
-  public key extraction or certification in their facilities, along with the OEM
-  doing it in the factory. This tightens up the "supply chain" and aims to make
-  key upload management more secure.
+* Degenerate DICE (Phase 1): A TEE root of trust key pair is used to sign
+  certificate requests; a single self-signed certificate signifies this phase.
+* DICE (Phase 2): A hardware root of trust key pair is only accessible to ROM
+  code; the boot process follows the [Android Profile for
+  DICE](#android-profile-for-dice).
+* SoC vendor certified DICE (Phase 3): This is identical to Phase 2, except the
+  SoC vendor also does the UDS\_pub extraction or certification in their
+  facilities, along with the OEM doing it in the factory. This tightens up the
+  "supply chain" and aims to make key upload management more secure.
 
 ### Privacy considerations
 
-Because DK and the DKCs are unique, immutable, unspoofable hardware-bound
-identifiers for the device, we must limit access to them to the absolute minimum
-possible. We do this in two ways:
-
-1.  We require KeyMint (which knows the BCC and either knows or at least has the
-ability to use KM\_priv) to refuse to ever divulge the BCC or additional
-signatures in plaintext. Instead, KeyMint requires the caller to provide an
-_Endpoint Encryption Key_ (EEK), with which it will encrypt the data before
-returning it. When provisioning production keys, the EEK must be signed by an
-approved authority whose public key is embedded in KeyMint. When certifying test
-keys, KeyMint will accept any EEK without checking the signature, but will
-encrypt and return a test BCC, rather than the real one.  The result is that
-only an entity in possession of an Trusted EEK (TEEK) private key can discover
-the plaintext of the production BCC.
-1.  Having thus limited access to the public keys to the trusted party only, we
-need to prevent the entity from abusing this unique device identifier.  The
-approach and mechanisms for doing that are beyond the scope of this document
-(they must be addressed in the server design), but generally involve taking care
-to ensure that we do not create any links between user IDs, IP addresses or
-issued certificates and the device pubkey.
-
-Although the details of the mechanisms for preventing the entity from abusing
-the BCC are, as stated, beyond the scope of this document, there is a subtle
-design decision here made specifically to enable abuse prevention. Specifically
-the `CertificateRequest` message sent to the server is (in
-[CDDL](https://tools.ietf.org/html/rfc8610)):
-
-```
-cddl
-CertificateRequest = [
-    DeviceInfo,
-    challenge : bstr,
-    ProtectedData,
-    MacedKeysToSign
-]
-```
-
-The public keys to be attested by the server are in `MacedKeysToSign`, which is
-a COSE\_Mac0 structure, MACed with a key that is found in `ProtectedData`. The
-MAC key is signed by DK\_pub.
-
-This structure allows the backend component that has access to EEK\_priv to
-decrypt `ProtectedData`, validate that the request is from an authorized device,
-check that the request is fresh and verify and extract the MAC key. That backend
-component never sees any data related to the keys to be signed, but can provide
-the MAC key to another backend component that can verify `MacedKeysToSign` and
-proceed to generate the certificates.
-
-In this way, we can partition the provisioning server into one component that
-knows the device identity, as represented by DK\_pub, but never sees the keys to
-be certified or certificates generated, and another component that sees the keys
-to be certified and certificates generated but does not know the device
-identity.
+Because the UDS, CDIs and derived values are unique, immutable, unspoofable
+hardware-bound identifiers for the device, we must limit access to them. We
+require that the values are never exposed in public APIs and are only available
+to the minimum set of system components that require access to them to function
+correctly.
 
 ### Key and cryptographic message formatting
 
@@ -195,24 +122,6 @@
 choice for algorithm implies the implementor should also choose the P256 public
 key group further down in the COSE structure.
 
-### Testability
-
-It's critical that the remote provisioning implementation be testable, to
-minimize the probability that broken devices are sold to end users. To support
-testing, the remote provisioning HAL methods take a `testMode` argument. Keys
-created in test mode are tagged to indicate this. The provisioning server will
-check for the test mode tag and issue test certificates that do not chain back
-to a trusted public key. In test mode, any EEK will be accepted, enabling
-testing tools to use EEKs for which they have the private key so they can
-validate the content of certificate requests. The BCC included in the
-`CertificateRequest` must contain freshly-generated keys, not the real BCC keys.
-
-Keystore (or similar) will need to be able to handle both testMode keys and
-production keys and keep them distinct, generating test certificate requests
-when asked with a test EEK and production certificate requests when asked with a
-production EEK. Likewise, the interface used to instruct Keystore to create keys
-will need to be able to specify whether test or production keys are desired.
-
 ## Design
 
 ### Certificate provisioning flow
@@ -220,25 +129,20 @@
 TODO(jbires): Replace this with a `.png` containing a sequence diagram.  The
 provisioning flow looks something like this:
 
-Provisioner -> Keystore: Prepare N keys
-Keystore -> KeyMint: generateKeyPair
-KeyMint -> KeyMint: Generate  key pair
-KeyMint --> Keystore: key\_blob,pubkey
-Keystore -> Keystore: Store key\_blob,pubkey
-Provisioner -> Server: Get TEEK
-Server --> Provisioner: TEEK
-Provisioner -> Keystore: genCertReq(N, TEEK)
-Keystore -> KeyMint: genCertReq(pubkeys, TEEK)
-KeyMint -> KeyMint: Sign pubkeys & encrypt BCC
-KeyMint --> Keystore: signature, encrypted BCC
-Keystore -> Keystore: Construct cert\_request
-Keystore --> Provisioner: cert\_request
-Provisioner --> Server: cert\_request
-Server -> Server: Validate cert\_request
+rkpd -> KeyMint: generateKeyPair
+KeyMint -> KeyMint: Generate key pair
+KeyMint --> rkpd: key\_blob,pubkey
+rkpd -> rkpd: Store key\_blob,pubkey
+rkpd -> Server: Get challenge
+Server --> rkpd: challenge
+rkpd -> KeyMint: genCertReq(pubkeys, challenge)
+KeyMint -> KeyMint: Sign CSR
+KeyMint --> rkpd: signed CSR
+rkpd --> Server: CSR
+Server -> Server: Validate CSR
 Server -> Server: Generate certificates
-Server --> Provisioner: certificates
-Provisioner -> Keystore: certificates
-Keystore -> Keystore: Store certificates
+Server --> rkpd: certificates
+rkpd -> rkpd: Store certificates
 
 The actors in the above diagram are:
 
@@ -246,10 +150,12 @@
     the uploaded device public keys and is responsible for providing encryption
     keys, decrypting and validating requests, and generating certificates in
     response to requests.
-*   **Provisioner** is an application that is responsible for communicating with
-    the server and all of the system components that require key certificates
-    from the server. It also implements the policy that defines how many key
-    pairs each client should keep in their pool.
+*   **rkpd** is, optionally, a modular system component that is responsible for
+    communicating with the server and all of the system components that require
+    key certificates from the server. It also implements the policy that defines
+    how many key pairs each client should keep in their pool. When a system
+    ships with rkpd as a modular component, it may be updated independently from
+    the rest of the system.
 *   **Keystore** is the [Android keystore
     daemon](https://developer.android.com/training/articles/keystore) (or, more
     generally, whatever system component manages communications with a
@@ -257,51 +163,37 @@
 *   **KeyMint** is the secure area component that manages cryptographic keys and
     performs attestations (or perhaps some other secure area component).
 
-### `BCC`
+### Android Profile for DICE
 
-The _Boot Certificate Chain_ (BCC) is the chain of certificates that contains
-DK\_pub as well as other often device-unique certificates. The BCC is
-represented as a COSE\_Key containing DK\_pub followed by an array of
-COSE\_Sign1 "certificates" containing public keys and optional additional
-information, ordered from root to leaf, with each certificate signing the next.
-The first certificate in the array is signed by DK\_pub, the last certificate
-has the KeyMint (or whatever) signing key's public key, KM\_pub. In phase 1
-there is only one entry; DK\_pub and KM\_pub are the same key and the
-certificate is self-signed.
+The Android Profile for DICE is based on the [Open Profile for
+DICE](https://pigweed.googlesource.com/open-dice/+/refs/heads/main/docs/specification.md),
+with additional constraints for details that the Open Profile for DICE leaves
+intentionally underspecified. This section describes the differences from the
+Open Profile for DICE.
 
-Each COSE\_Sign1 certificate is a CBOR Web Token (CWT) as described in [RFC
-8392](https://tools.ietf.org/html/rfc8392) with additional fields as described
-in the Open Profile for DICE. Of these additional fields, only the
-_subjectPublicKey_ and _keyUsage_ fields are expected to be present for the
-KM\_pub entry (that is, the last entry) in a BCC, but all fields required by the
-Open Profile for DICE are expected for other entries (each of which corresponds
-to a particular firmware component or boot stage). The CWT fields _iss_ and
-_sub_ identify the issuer and subject of the certificate and are consistent
-along the BCC entries; the issuer of a given entry matches the subject of the
-previous entry.
+#### Algorithms
 
-The BCC is designed to be constructed using the Open Profile for DICE. In this
-case the DK key pair is derived from the UDS as described by that profile and
-all BCC entries before the leaf are CBOR CDI certificates chained from DK\_pub.
-The KM key pair is not part of the derived DICE chain. It is generated (not
-derived) by the KeyMint module, certified by the last key in the DICE chain, and
-added as the leaf BCC entry. The key usage field in this leaf certificate must
-indicate the key is not used to sign certificates. If a UDS certificate is
-available on the device it should appear in the certificate request as the leaf
-of a DKCertChain in AdditionalDKSignatures (see
-[CertificateRequest](#certificaterequest)).
+The choice of algorithm must remain consistent with a given certificate e.g. if
+SHA-256 is used for the code hash then the authority hash, config hash, etc.
+must also use SHA-256.
+
+* UDS and CDI key pairs:
+  * Ed25519 / P-256 / P-384
+* Hash algorithms (digests can be encoded with their natural size and do not
+  need to be the 64-bytes specified by the Open Profile for DICE):
+  * SHA-256 / SHA-384 / SHA-512
+* HKDF with a supported message digest for all key derivation
 
 #### Mode
 
-The Open Profile for DICE specifies four possible modes with the most important
-mode being `normal`. A certificate must only set the mode to `normal` when all
-of the following conditions are met when loading and verifying the software
-component that is being described by the certificate:
+A certificate must only set the mode to `normal` when all of the following
+conditions are met when loading and verifying the software component that is
+being described by the certificate:
 
-*   verified boot with anti-rollback protection is enabled
-*   only the verified boot authorities for production images are enabled
-*   debug ports, fuses or other debug facilities are disabled
-*   device booted software from the normal primary source e.g. internal flash
+* verified boot with anti-rollback protection is enabled
+* only the verified boot authorities for production images are enabled
+* debug ports, fuses, or other debug facilities are disabled
+* device booted software from the normal primary source e.g. internal flash
 
 The mode should never be `not configured`.
 
@@ -310,11 +202,11 @@
 
 #### Configuration descriptor
 
-The Open Profile for DICE allows for an arbitrary configuration descriptor. For
-BCC entries, this configuration descriptor is a CBOR map with the following
-optional fields. If no fields are relevant, an empty map should be encoded.
-Additional implementation-specific fields may be added using key values not in
-the range \[-70000, -70999\] (these are reserved for future additions here).
+The configuration descriptor is a CBOR map with the following optional fields.
+If no fields are relevant, an empty map should be encoded. The key value range
+\[-70000, -70999\] is reserved for the Android Profile for DICE.
+Implementation-specific fields may be added using key values outside of the
+reserved range.
 
 ```
 | Name              | Key    | Value type | Meaning                           |
@@ -332,42 +224,6 @@
 :                   :        :            : version                           :
 ```
 
-Please see
-[ProtectedData.aidl](https://cs.android.com/android/platform/superproject/+/master:hardware/interfaces/security/rkp/aidl/android/hardware/security/keymint/ProtectedData.aidl)
-for a full CDDL definition of the BCC.
-
-### `CertificateRequest`
-
-The full CBOR message that will be sent to the server to request certificates
-is:
-
-```cddl
-CertificateRequest = [
-    DeviceInfo,
-    challenge : bstr,       // Provided by the server
-    ProtectedData,          // See ProtectedData.aidl
-    MacedKeysToSign         // See IRemotelyProvisionedComponent.aidl
-]
-
-DeviceInfo = [
-    VerifiedDeviceInfo,     // See DeviceInfo.aidl
-    UnverifiedDeviceInfo
-]
-
-// Unverified info is anything provided by the HLOS. Subject to change out of
-// step with the HAL.
-UnverifiedDeviceInfo = {
-    ? "fingerprint" : tstr,
-}
-
-```
-
-It will be the responsibility of Keystore and the Provisioner to construct the
-`CertificateRequest`. The HAL provides a method to generate the elements that
-need to be constructed on the secure side, which are the tag field of
-`MacedKeysToSign`, `VerifiedDeviceInfo`, and the ciphertext field of
-`ProtectedData`.
-
 ### HAL
 
 The remote provisioning HAL provides a simple interface that can be implemented
diff --git a/tv/tuner/1.1/vts/functional/FrontendTests.cpp b/tv/tuner/1.1/vts/functional/FrontendTests.cpp
index 9f0f30d..0a645fc 100644
--- a/tv/tuner/1.1/vts/functional/FrontendTests.cpp
+++ b/tv/tuner/1.1/vts/functional/FrontendTests.cpp
@@ -379,7 +379,7 @@
                 break;
             }
             case FrontendStatusTypeExt1_1::UEC: {
-                ASSERT_TRUE(realStatuses[i].uec() == expectStatuses[i].uec());
+                ASSERT_TRUE(realStatuses[i].uec() >= 0 );
                 break;
             }
             case FrontendStatusTypeExt1_1::T2_SYSTEM_ID: {
diff --git a/tv/tuner/1.1/vts/functional/VtsHalTvTunerV1_1TestConfigurations.h b/tv/tuner/1.1/vts/functional/VtsHalTvTunerV1_1TestConfigurations.h
index 669fa11..dcdc673 100644
--- a/tv/tuner/1.1/vts/functional/VtsHalTvTunerV1_1TestConfigurations.h
+++ b/tv/tuner/1.1/vts/functional/VtsHalTvTunerV1_1TestConfigurations.h
@@ -86,7 +86,7 @@
     types.push_back(FrontendStatusTypeExt1_1::IS_MISO);
     vector<FrontendStatusExt1_1> statuses;
     FrontendStatusExt1_1 status;
-    status.uec(4);
+    status.uec(0);
     statuses.push_back(status);
     status.isMiso(true);
     statuses.push_back(status);