-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add bindings for Thermal Manager #481
base: master
Are you sure you want to change the base?
Conversation
Upstream recently (yesterday as of writing this patch) fixed the `thermal.h` header in https://android-review.googlesource.com/c/ platform/frameworks/native/+/3205910 to finally contain valid C code, allowing us to finally generate C bindings for this API and start writing safe bindings inside the `ndk` crate.
https://developer.android.com/ndk/reference/group/thermal `AThermal` allows querying the current thermal (throttling) status, as well as forecasts of future thermal statuses to allow applications to respond and mitigate possible throttling in the (near) future.
/// Workaround for <https://issuetracker.google.com/issues/358664965>. `status_t` should only | ||
/// contain negative error codes, but the underlying `AThermal` implementation freely passes | ||
/// positive error codes around. At least the expected return codes are "implicitly" documented to | ||
/// be positive. | ||
fn status_to_io_result(status: i32) -> Result<()> { | ||
// Intentionally not imported in scope (and an identically-named function) to prevent | ||
// accidentally calling this function without negation. | ||
crate::utils::status_to_io_result(-status) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unlike all other NDK APIs, this one returns positive errno values 🙃
/// # Warning | ||
/// [`ThermalManager`] is synchronized internally, and its lock is held while this callback is | ||
/// called. Interacting with [`ThermalManager`] inside this closure *will* result in a deadlock. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While all the extra locking makes it possible to add Send
+Sync
on ThermalManager
, it means the user can now trivially pass this type into the callback and (if it's the same instance!) get a deadlock when interacting with it.
The header for this got fixed just yesterday to contain valid C so that we can parse it (without making trivial custom changes...) so now seems to be about the right time to actually write out the bindings and at least have them open in a PR!
https://developer.android.com/ndk/reference/group/thermal
AThermal
allows querying the current thermal (throttling) status, as well as forecasts of future thermal statuses to allow applications to respond and mitigate possible throttling in the (near) future.