On 8 Dec. 2016, at 01:20, Michael Rogers michael@briarproject.org wrote:
...
I'll spare you a long rant about the quality of Android's documentation and just say that I looked into this, and in summary, an unprivileged process can't use native calls to schedule alarms that will wake the CPU.
(There may be a few devices where alarm timer support is enabled in the kernel, *and* timerfd_create() supports the relevant clocks, *and* it hasn't yet been patched to check the CAP_WAKE_ALARM capability like timer_create() does, but those devices will never be the majority.)
Unfortunately, I also found that in doze mode, which was introduced in Android M, alarms can't be scheduled via the Android API more frequently than once every nine minutes. I don't think we can realistically expect to refactor second_elapsed_callback() to be called once every nine minutes, especially if no other timers can fire during that time. So my original question is moot. We'll have to stick with a wake lock.
I would just like to plant the seed of a thought, though. Is it possible to imagine a protocol for connecting a service to Tor, such that the device running the service can sleep for long periods without losing connectivity?
This has two variants. In the easy variant, the device can wake up to handle network traffic. In the hard variant, the device can't wake up until its next alarm.
This list probably isn't the place to discuss solutions to that problem
- I just mention it as food for thought.
Please feel free to log tickets for these issues. We can consider them as part of our upcoming mobile device work.
T