Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 64b9ab2a authored by android-build-team Robot's avatar android-build-team Robot
Browse files

Snap for 7189849 from 0a9323ca to sc-v2-release

Change-Id: I1380f9c9746183a30003247fdf5320d16683d792
parents 7ba54606 0a9323ca
Loading
Loading
Loading
Loading
+9 −9
Original line number Diff line number Diff line
@@ -3037,7 +3037,7 @@ enum VehicleProperty : int32_t {
    /**
     * Starts the ClusterUI in cluster display.
     *
     * int32[0]: the type of ClusterUI to show
     * int32: the type of ClusterUI to show
     *    0 indicates ClusterHome, that is a home screen of cluster display, and provides
     *        the default UI and a kind of launcher functionality for cluster display.
     *    the other values are followed by OEM's definition.
@@ -3057,12 +3057,12 @@ enum VehicleProperty : int32_t {
     * int32[0]: on/off: 0 - off, 1 - on, -1 - don't care
     * int32[1]: width: positive number - actual width in pixels
                        -1 - don't care (should set "don't care" both width and height)
     * int32[2]: height: ditto with width
     * int32[2]: height: same format with 'width'
     * int32[3]: Inset - left: positive number - actual left inset value in pixels
                               -1 - don't care (should set "don't care" all Inset fields)
     * int32[4]: Inset - top
     * int32[5]: Inset - right
     * int32[6]: Inset - bottom
     * int32[4]: Inset - top:    same format with 'left'
     * int32[5]: Inset - right:  same format with 'left'
     * int32[6]: Inset - bottom: same format with 'left'
     *
     * @change_mode VehiclePropertyChangeMode:ON_CHANGE
     * @access VehiclePropertyAccess:READ
@@ -3097,9 +3097,9 @@ enum VehicleProperty : int32_t {
     *    -1 indicates the area isn't used any more.
     * bytes: the array to represent the availability of ClusterUI.
     *     0 indicates non-available and 1 indicates available.
     *     For example, let's assume a car supports 3 UI like HOME, MAPS, CALL and it only supports
     *     CALL UI only when the cellular network is available. Then, if the nework is avaibale,
     *     it'll send [1 1 1], and if it's out of network, it'll send [1 1 0].
     *     For example, let's assume a car supports 3 OEM defined ClusterUI like HOME, MAPS, CALL,
     *     and it only supports CALL UI only when the cellular network is available. Then, if the
     *     nework is avaibale, it'll send [1 1 1], and if it's out of network, it'll send [1 1 0].
     *
     * @change_mode VehiclePropertyChangeMode:ON_CHANGE
     * @access VehiclePropertyAccess:WRITE
@@ -3117,7 +3117,7 @@ enum VehicleProperty : int32_t {
     * request to turn the display on to show some specific ClusterUI.
     * ClusterOS should response this with CLUSTER_DISPLAY_STATE.
     *
     * int32[0]: the type of ClusterUI to show
     * int32: the type of ClusterUI to show
     *
     * @change_mode VehiclePropertyChangeMode:ON_CHANGE
     * @access VehiclePropertyAccess:WRITE
+1 −1
Original line number Diff line number Diff line
@@ -34,7 +34,7 @@
package android.hardware.biometrics.face;
@VintfStability
interface ISession {
  void generateChallenge(in int cookie, in int timeoutSec);
  void generateChallenge(in int cookie);
  void revokeChallenge(in int cookie, in long challenge);
  android.hardware.biometrics.common.ICancellationSignal enroll(in int cookie, in android.hardware.keymaster.HardwareAuthToken hat, in android.hardware.biometrics.face.EnrollmentType type, in android.hardware.biometrics.face.Feature[] features, in android.hardware.common.NativeHandle previewSurface);
  android.hardware.biometrics.common.ICancellationSignal authenticate(in int cookie, in long operationId);
+7 −9
Original line number Diff line number Diff line
@@ -45,7 +45,7 @@ interface ISession {
     *      to allow addition of biometric enrollments.
     * To secure this path, the following path is taken:
     *   1) Upon user requesting face enroll, the framework requests
     *      IFace#generateChallenge
     *      ISession#generateChallenge
     *   2) Framework sends the challenge to the credential subsystem, and upon credential
     *      confirmation, a HAT is created, containing the challenge in the "challenge" field.
     *   3) Framework sends the HAT to the HAL, e.g. ISession#enroll.
@@ -53,11 +53,10 @@ interface ISession {
     *   5) Implementation now has confidence that the user entered their credential to allow
     *      biometric enrollment.
     *
     * Note that the interface allows multiple in-flight challenges. For example, invoking
     * generateChallenge(0, 0, timeoutSec) twice does not invalidate the first challenge. The
     * challenge is invalidated only when:
     *   1) The provided timeout expires, or
     *   2) IFace#revokeChallenge is invoked
     * Note that this interface allows multiple in-flight challenges. Invoking generateChallenge
     * twice does not invalidate the first challenge. The challenge is invalidated only when:
     *   1) Its lifespan exceeds the HAL's internal challenge timeout
     *   2) IFingerprint#revokeChallenge is invoked
     *
     * For example, the following is a possible table of valid challenges:
     * ----------------------------------------------
@@ -70,9 +69,8 @@ interface ISession {
     * ----------------------------------------------
     *
     * @param cookie A unique number identifying this operation
     * @param timeoutSec Duration for which the challenge is valid for
     */
    void generateChallenge(in int cookie, in int timeoutSec);
    void generateChallenge(in int cookie);

    /**
     * revokeChallenge:
@@ -113,7 +111,7 @@ interface ISession {
     *
     * Before capturing face data, the implementation must first verify the authenticity and
     * integrity of the provided HardwareAuthToken. In addition, it must check that the challenge
     * within the provided HardwareAuthToken is valid. See IFace#generateChallenge. If any of
     * within the provided HardwareAuthToken is valid. See ISession#generateChallenge. If any of
     * the above checks fail, the framework must be notified via ISessionCallback#onError and the
     * HAL must notify the framework when it returns to the idle state. See
     * Error::UNABLE_TO_PROCESS.
+1 −1
Original line number Diff line number Diff line
@@ -37,7 +37,7 @@ class CancellationSignal : public common::BnCancellationSignal {

Session::Session(std::shared_ptr<ISessionCallback> cb) : cb_(std::move(cb)) {}

ndk::ScopedAStatus Session::generateChallenge(int32_t /*cookie*/, int32_t /*timeoutSec*/) {
ndk::ScopedAStatus Session::generateChallenge(int32_t /*cookie*/) {
    LOG(INFO) << "generateChallenge";
    if (cb_) {
        cb_->onStateChanged(0, SessionState::GENERATING_CHALLENGE);
+1 −1
Original line number Diff line number Diff line
@@ -30,7 +30,7 @@ class Session : public BnSession {
  public:
    explicit Session(std::shared_ptr<ISessionCallback> cb);

    ndk::ScopedAStatus generateChallenge(int32_t cookie, int32_t timeoutSec) override;
    ndk::ScopedAStatus generateChallenge(int32_t cookie) override;

    ndk::ScopedAStatus revokeChallenge(int32_t cookie, int64_t challenge) override;

Loading