android sensor 的aidl和 hidl 接口

ISensorService接口:


enum {
    GET_SENSOR_LIST = IBinder::FIRST_CALL_TRANSACTION,
    CREATE_SENSOR_EVENT_CONNECTION,
    ENABLE_DATA_INJECTION,
    GET_DYNAMIC_SENSOR_LIST,
    CREATE_SENSOR_DIRECT_CONNECTION,
    SET_OPERATION_PARAMETER,
};

hidl ISensors


interface ISensors {
    /**
     * Enumerate all available (static) sensors.
     */
    getSensorsList() generates (vec list);

    /**
     * Place the module in a specific mode. The following modes are defined
     *  SENSOR_HAL_NORMAL_MODE - Normal operation. Default state of the module.
     *  SENSOR_HAL_DATA_INJECTION_MODE - Loopback mode.
     */
    setOperationMode(OperationMode mode) generates (Result result);

    /**
     * Activate/de-activate one sensor.
     * @param  sensorHandle is the handle of the sensor to change.
     * @param  enabled set to true to enable, or false to disable the sensor.
     */
    activate(int32_t sensorHandle, bool enabled) generates (Result result);

    /**
     * Generate a vector of sensor events containing at most "maxCount"
     * entries.
     *
     * If there is no sensor event when this function is being called, block
     * until there are sensor events available.
     *
     * @param  maxCount max number of samples can be returned, must be > 0.
     *         Actual number of events returned in data must be <= maxCount
     *         and > 0.
     * @return result OK on success or BAD_VALUE if maxCount <= 0.
     * @return data vector of Event contains sensor events.
     */
    poll(int32_t maxCount)
        generates (
                Result result,
                vec data,
                vec dynamicSensorsAdded);

    /**
     * Sets a sensor���s parameters, including sampling frequency and maximum
     * report latency. This function can be called while the sensor is
     * activated, in which case it must not cause any sensor measurements to
     * be lost: transitioning from one sampling rate to the other cannot cause
     * lost events, nor can transitioning from a high maximum report latency to
     * a low maximum report latency.
     * See the Batching sensor results page for details:
     * http://source.android.com/devices/sensors/batching.html
     *
     * @param  sensorHandle handle of sensor to be changed.
     * @param  samplingPeriodNs specifies sensor sample period in nanoseconds.
     * @param  maxReportLatencyNs allowed delay time before an event is sampled to time of report.
     * @return result OK on success, BAD_VALUE if any parameters are invalid.
     */
    batch(int32_t sensorHandle,
          int64_t samplingPeriodNs,
          int64_t maxReportLatencyNs) generates (Result result);

    /**
     * Trigger a flush of internal FIFO.
     *
     * Flush adds a FLUSH_COMPLETE metadata event to the end of the "batch mode"
     * FIFO for the specified sensor and flushes the FIFO.  If the FIFO is empty
     * or if the sensor doesn't support batching (FIFO size zero), return
     * SUCCESS and add a trivial FLUSH_COMPLETE event added to the event stream.
     * This applies to all sensors other than one-shot sensors. If the sensor
     * is a one-shot sensor, flush must return BAD_VALUE and not generate any
     * flush complete metadata.  If the sensor is not active at the time flush()
     * is called, flush() return BAD_VALUE.
     */
    flush(int32_t sensorHandle) generates (Result result);
};

你可能感兴趣的:(人工智能)