On 06/03/17 14:34, Nathan of Guardian wrote: > For now, Orbot does prompt you to disable the battery optimization > features for Orbot when you enable a hidden service. Otherwise, I think > it is up to the app server/process itself to handle their own wake lock > needs, depending on what kind of availability they are expected to have. > > ChatSecure/Zom already does quite a bit of wakelock management for > instance, and so if we added a Ricochet, Briar or other protocol support > into that stack, I wouldn't expect Orbot to directly handle it. > > Does that make sense?
The situation with doze mode and app standby is far from clear to me, even after a lot of digging, but it seems to me that whichever app holds the wake lock also needs to request whitelisting, otherwise the wake lock won't be honoured in doze mode. So if you think the wake lock should be held by the client app rather than by Orbot (which I would agree with, because it puts the battery blame on the client), then the client app should also request whitelisting. I don't understand the benefit of Orbot requesting whitelisting without also holding a wake lock. Another issue to consider is that apps have been removed from the Play Store for requesting the REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission, if Google decides that the permission isn't needed for "the core function of the app" (see https://commonsware.com/blog/2015/11/11/google-anti-trust-issues.html). If a client app needs a hidden service and Orbot provides one, which of them would Google consider to have a legitimate case for requesting the permission? I have no idea, and frankly it's stupid that we even have to worry about it, but such is the platform. Cheers, Michael
0x9FC527CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
