add light controller for Rockchip3566 (Inkbook Focus Plus)

[matejbart]

Note

Testing device:
MANUFACTURER: inkbook
BRAND : rockchip
MODEL : focus plus
DEVICE : rk3566_eink
PRODUCT : r0782a
HARDWARE : rk30board

This PR adds a new light controller for the InkBOOK Focus Plus e-reader, which is based on the Rockchip3566 device. The generic (or any other existing) controller doesn't work for this model at all.

The light is controlled by two hardware LEDs called leda and ledb. The input for the led values needs to be computed based on the brightness and warmth. The computation function has been reverse engineered from the inkBOOKSettings.apk.

Controlling the light is done by writing to the "files" directly which works without root access. I also added a fallback by using reflection in case that the write/read should not be permitted on some other devices even though I think it's not that versatile as it relies on the existence of a specific class.

I tried to mimic the behavior of the system app as good as possible, i.e. as soon as a new value is set, the value is also persisted in the corresponding system property:

• brightness: persist.inkbook.frontlight.brightness
• warmth: persist.inkbook.frontlight.temperature
• leda: persist.yitoa.backlight.leda.brightness
• ledb: persist.yitoa.backlight.ledb.brightness

And finally, a broadcast action com.android.systemui.statusbar.action.light_change is sent out so that the systemUI app bar updates the light icon. However, the light handlers in the inkBOOK related .apks are not listening to that broadcast action, they only send it out in case something changes.
Furthermore, they also cache their last known brightness in the RAM, so when the koreader manipulates some light settings, then the inkBOOK apps are unaware of that, resulting in an unsynced state.

---

This section just contains details about the device specific APKs and light handling.

I started my investigations by reverse engineering the following system apks to find out how the light is being controlled:

• /system_ext/priv-app/SystemUI_inkBook/SystemUI_inkBook.apk - the system UI which e.g. displays the status bar.
• /odm/bundled_persist-app/inkBook3566Setting/inkBook3566Setting.apk an app that mainly is responsible for displaying context menus for the status bar. it listens to broadcast receiver actions from the status bar:
  • click on light icon --> listens to the action, but does nothing.
  • long click on light icon --> starts LightActivity of the inkBOOKSettings.apk where the user can set the brightness and temperature with UI sliders.
• /odm/bundled_persist-app/inkBOOKSettings/inkBOOKSettings.apk - the main settings app, which also listens to broadcast receiver actions from the status bar.
  • this apk uses android.yitoa.rk3566.SysUtil from the platform's framework.jar to control the light. That util class provides methods to write to the leda/ledb files.
• lightProvider.apk (a provider which seems to handle the light as well but it's not exposed, so I guess it's just dead code)

---

This change is 

[hugleo]

Warning

Currently only tested in the TestActivity.

Need to be well tested, specially a new driver.

[matejbart]

I finally managed to compile the entire project to test it within the main koreader app. It works very well as long as the light is only manipulated within the koreader app itself. However, there are some (expected) limitations that I would want to discuss:

As already mentioned in the PR's description, whenever one party changes the light settings, the other one doesn't receive any feedback about that resulting in an inconsistent UI state.

But the most annoying issue occurs when the device's screen is turned back on. The system app listens to the android.intent.action.SCREEN_ON action and always tries to restore the light based on the cached brightness/warmth settings in the system's app RAM. Practically this means that any changes to the light settings made by the koreader app are overridden by the system app at android.intent.action.SCREEN_ON.

This could be mitigated by trying to re-apply the currently known light settings in the koreader app at android's onResume lifecycle callback, but as the system app will also try to restore it right before that, it will result in an ugly UI effect. I think it's not a good idea to start to "fight the system's app" as any further updates to it could introduce changes that could break this hack, therefore my conclusion would be to keep this as a known limitation.

[Frenzie]

I never quite understood why you'd want to manage the brightness from KOReader at all really, but I guess there must be something awkward about it on at least some of these readers.

[matejbart]

Warning
Currently only tested in the TestActivity.

Need to be well tested, specially a new driver.

I linked this PR in the main repo koreader/koreader#8482 (comment) to ask users for testing support.