Skip to content
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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Add bindings for Thermal Manager #481

wants to merge 3 commits into from

Conversation

MarijnS95
Copy link
Member

@MarijnS95 MarijnS95 commented Aug 3, 2024

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.

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.
Comment on lines +17 to +25
/// 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)
}
Copy link
Member Author

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 🙃

https://issuetracker.google.com/issues/358664965

Comment on lines +75 to +77
/// # 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.
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant