Lines Matching +full:service +full:- +full:specific
3 ## Determine whether the example service implementation is sufficient {#determine}
10 are set to a `true` value. See [below](#charger-sysprops).
11 * The device supports offline charging mode, and the `service`
13 provided by the example implementation. See [below](#charger-init-rc).
15 If the example HAL service is sufficient, [install it](#use-example). Otherwise,
16 [implement a custom HAL service](#use-custom).
18 ### System properties for charger {#charger-sysprops}
20 The health AIDL HAL service also provides functionalities of `charger`. As a
23 However, the health AIDL HAL service is not allowed to read `ro.charger.*`
26 service. See [below](#charger-enable-suspend).
27 * `ro.charger.no_ui`. If set, you need a custom health AIDL HAL service.
28 See [below](#charger-no-ui).
36 ### Default `service` declaration for charger in `init.rc` {#charger-init-rc}
39 [android.hardware.health-service.example.rc](default/android.hardware.health-service.example.rc).
41 Check the `service` declaration in your device-specific `init.rc` file that
46 service vendor.charger /system/bin/charger
53 file /sys/fs/pstore/console-ramoops-0 r
54 file /sys/fs/pstore/console-ramoops r
59 service in
60 [android.hardware.health-service.example.rc](default/android.hardware.health-service.example.rc).
63 * For the `service` line, if the name of the service is **NOT**
66 `<name>` is the name of your charger service, then you need a custom health
67 AIDL service.
68 * If your service belongs to additional classes beside `charger`, you need a
69 custom health AIDL service.
71 * If your service has a different `user` (not `system`), you need a custom
72 health AIDL service.
73 * If your service belongs to additional `group`s beside
74 `system wakelock input`, you need a custom health AIDL service.
75 * If your service requires additional capabilities beside `SYS_BOOT`,
76 you need a custom health AIDL service.
77 * If your service requires additional `file`s to be opened prior to execution,
78 you need a custom health AIDL service.
80 ## Using the example health AIDL HAL service {#use-example}
82 If you [determined](#determine) that the example health AIDL HAL service works
87 android.hardware.health-service.example \
88 android.hardware.health-service.example_recovery \
91 Then, delete any existing `service` with `class charger` in your device-specific
93 [android.hardware.health-service.example.rc](default/android.hardware.health-service.example.rc)
97 [move charger resources to `/vendor`](#charger-res)
99 ## Implementing a custom health AIDL HAL service {#use-custom}
101 ### Override the `Health` class {#health-impl}
103 See [`Health.h`](default/include/health-impl/Health.h) for its class
127 |-------------------------------------|-----------------------------|
143 See the [`main.cpp`](default/main.cpp) for the example health AIDL service for
160 If your device does not support off-line charging mode, or does not have a UI
166 Install both the platform and recovery variant of the service. For example:
170 android.hardware.health-service.cuttlefish \
171 android.hardware.health-service.cuttlefish_recovery \
176 Add device specific permissions to the domain where the health HAL
177 process is executed, especially if a device-specific `libhealthd` is used
178 and/or device-specific storage related APIs are implemented.
180 Example (assuming that your health AIDL service runs in domain
192 `hal_health_default`. The device-specific rules for it is likely at
195 defined. You only need to add device-specific permissions.
213 Charger resources in `/system` is not read by the health HAL service in
221 If resources are not found in these locations, the health HAL service falls
236 It is recommended that you move the existing `service` entry with
237 `class charger` to the `init.rc` file in your custom health service.
241 existing charger service (usually `vendor.charger`), then the name of the
242 service must be kept as-is. If you modify the name of the service, the actions
245 Modify the entry to invoke the health service binary with `--charger` argument.
247 [android.hardware.health-service.example.rc](default/android.hardware.health-service.example.rc)
251 service vendor.charger /vendor/bin/hw/android.hardware.health-service-tuna --charger
257 #### No charger mode {#no-charger}
259 If your device does not support off-line charging mode, skip the invocation of
265 // Skip checking if arguments contain "--charger"
267 return hal_health_loop->StartLoop();
271 You may optionally delete the `service` entry with `class charger` in the
274 #### No charger UI {#charger-no-ui}
285 if (argc >= 2 && argv[1] == "--charger"sv) {
290 return hal_health_loop->StartLoop();
294 #### Enable suspend {#charger-enable-suspend}
298 [`ChargerCallback`](default/include/health-impl/ChargerUtils.h). Then
310 if (argc >= 2 && argv[1] == "--charger"sv) {
323 If your health AIDL service runs in a domain other than `hal_health_default`,
324 add `charger_type` to it so the health HAL service can have charger-specific
325 permissions. Example (assuming that your health AIDL service runs in domain