[0] Sure, better performance is always nice, but I don't care for Vulkan, VR Mode, or Multi-Window.
[0] Sure, better performance is always nice, but I don't care for Vulkan, VR Mode, or Multi-Window.
Just swipe down from the top of the screen to reveal the quick settings, and then press and hold the Settings icon (gear) for a few seconds and release. This will enable the UI tuner.
Swipe down from the top again, then tap "EDIT" in the bottom right corner. There should be a tile for "Night mode", which you can drag and drop into the quick settings panel for easy toggling.
However, there's a third party app that provides access to the switch (seems to not work for some people, or require several tries - YMMV): http://android.wonderhowto.com/how-to/enable-hidden-night-mo...
I'm glad that Google has signaled that they are going to further tighten the restrictions on background app activities in future releases. I hope they follow through with it.
Anything you can do with an app you can do as well with a website.
Any actual app, not just a website in form of an app, which did computational task, data recording, or kept services available, is impossible to create now.
Run tracking app that doesn’t require you uploading your GPS data to Google Fit? Impossible.
Messaging app that doesn’t route all your private messages through Google Cloud Messaging? Impossible.
EDIT: before downvoting, read the comment below from morsch, he and I explained there pretty well the issues.
All Google did is restrict what apps can do in the background, and announced that there will be further restrictions in the future: all background tasks will have to be done through the JobScheduler API.
This does not prevent apps from doing stuff in the background, it just prevents them from doing whatever they want, whenever they want -- they will have to follow the proper procedure.
With Nougat, no background tasks will be run at all while the screen is off – except for Google services, or if they keep the CPU on 100% of the time with a wake lock.
JobScheduler also doesn’t allow continuous tasks, but only short tasks – so you can’t actually keep a low-cost socket open.
Untrue.
First, mobile Doze doesn't kick in immediately when the screen is off.
Second, mobile Doze apparently doesn't stop all background tasks except "Google services" from running, since "wake locks" from apps for background tasks are still supported.
Except a Wake Lock has a significant battery impact, causing the CPU to stay on at all times.
There’s no way to keep your app running while also saving battery – which is the general ideal you want.
So, tell me, how do I keep a socket open without wasting battery?
________________________
A guarantee that, if the device has connection, the notification is transmitted within of 15 seconds, and that the device (in the case of the moto G 2014) gets still the 2 days battery runtime it’d get without the app.That’s what I set as minimum goals for my app, and what I was able to get with older Android versions.
The second is indisputably true of Nougat, no one is arguing against it; the first is what you said upthread, what I was arguing against, and what is and remains false.
In previous dev versions, Google even didn’t allow wake locks at all (which is where my confusion is from), saying devs should instead move all their processing to server side, and use GCM for everything.
That doesn't sound appealing at all.
There are mechanisms to get high-priority notifications, and methods to do background work that are batched on increasingly long intervals to save battery life (both the batching and the increasing intervals serve that purpose), so that shouldn't be an issue. Notifications that need to be immediate have a path, and ones that don't should still happen, just not immediately.
Or never happen at all.
Or just work normally.
Depending on when the heuristics think you are less likely to use your phone.
There is one way to keep getting notifications, by using proprietary Google services, and sending a ping from your server via Google to the device, or sending the actual notification that way.
Which, for email, means either everyone who does that has to build every app themselves from source, or you have to send that data to a third party server which then sends it to Google
Hard to say whether this is one way to do it, or the only way. (E.g. "Unlike stationary Doze, wake locks (apps requesting the phone stay awake so they can do background tasks) are still allowed.")
[0] http://arstechnica.com/gadgets/2016/08/android-7-0-nougat-re...
A wake lock is possible, but it’s far more battery intensive than just using the pre-Nougat solutions.
Pre-Nougat, I could keep a socket open, and only have a timeout message sent every 28 minutes to keep it open – at very low battery cost.
Now I either have to keep a wakelock – keeping the CPU always on, instead of just a few milliseconds per hour – or I can’t use it at all.
That’s a severe issue for me.
(I can’t use GCM, due to architectural reasons, and would have to ask tenthousands of people to change their IRC bouncer setup completely).
If you don't see the app in front of you, iOS will very quickly kill it if it has any background tasks.
It's a leaky abstraction, but honestly I like the implicit promise/guarantee between the scheduler and the user.
I only get annoyed when I want some batch task like uploading photos, but even then it's not too hard to leave the phone powered on and unlocked on my desk until the photos upload...
Or when you try to transmit notifications without going through Google/Apple servers, because those require you to control the messaging server (due to API auth limitations), which does not work with distributed systems.
A messaging app that only works when the screen is on is useless.
That way, you get realtime event notifications without the privacy risk of exposing content to Apple's servers.
That same certificate can be used to replace your app on the store, or so on.
Basically, that is your one key to the kingdom.
So, I obviously can’t give everyone who hosts a server for the app that key.
So I have to host a server transmitting all those pings then.
Even ignoring the obvious DDoS risk, and assuming it’s only used in good ways, I end up with having to buy an entire additional server, just for that.
And I still leak metadata, which – as the NSA has shown – can be easily correlated with who is whom if you have enough data.
It would be a shame to have to turn off all of them. I found most of them to be useful.
I think Apple has done a better job at this balance by not letting people shoot themselves in the foot at the cost the odd useful service not being possible.