Please bring back 5 minutes (and below) poll frequency. PUSH is not an option and eats up battery

No, the replies all just say “yes Google limit the poll frequency to 15 minutes”. That is not an answer, that is just restating what I have already posted. Utterly pointless. Your analogy also basically says that too, doesn’t actually answer the curt statement I initially made. And yes, I am pretty obtuse and coarse.

And you can just edit your post to be a reply, you don’t need to delete it and repost it btw.

@Lurch here is your Q&A <°)))o>.

That question was already answered … several times I think …

THAT is what it has to do with Google.

Yeah this is definitely a lost in translation issue. It has been taken way too literally by everyone.

I think we can just forget this ever happened.

But, isn’t it possible to reinstall the “manual pull button” ? Seams more easyer… Generally, good new redesign in your update - thanks a lot!!

Please bring back the manual-pull-button! Thanks a lot in advance!

You can manually poll by pulling down in the side bar

1 Like

PUSH is not an option and eats up battery

Have you recently measured the difference between a 5 Min pull and IMAP IDLE aka push? I run k9-mail with IMAP IDLE all day and it is by far not a big drain among all those battery suckers…

Not saying, it is not true for you, but it does not eat up battery here.

2 Likes

I am unable to use the new interface since it messes up the way accounts are visualized which is a big no-no for all of us in the company so we had to reinstall 5.6.

Re: consumption - I had looked at this about 2 years back (maybe 5.3 or 5.4 version) and it was about 30% higher, enough to make my S7 at the time need to be charged almost once a day if not more.

I can’t judge on the UI changes, but after 2 years of development you could dare to try IDLE again, before juging prematurely :grinning:. K9 runs on this lowend Android with idle with no noticable impact on battery life.

2 Likes

On reading this I thought, he is asking the same question I have. Maybe a little more detail about my use case will explain why the discussion thus far does not really answer it for me, and perhaps the similar reason applies for him too?

I have numerous email accounts on a variety of servers, and NONE of them are Gmail or otherwise related to Google in any way. One of the reasons I installed K9 was to avoid installing GMail. So I am not using any Google related things other than the Android system itself, and even that is supposedly open source and free for others to use as they wish.

Since these are POP accounts, using the “push” workaround is NOT an option. So more frequent polling will not put any load whatsoever on any Google owned resources, not even the cloud messaging infrastructure.

Since Google does not own any of the affected resources, why should they have any say in this matter? It’s like they are telling everyone what they can or can’t do with servers those other people own! If the owners of these servers are okay with more frequent access, why does Google step in to overrule what does not concern Google?

As for “excessive data use”, a rule like that may make sense on a metered cellular connection, but it should be a user adjustable setting, not an OS enforced thing. For instance, it takes no account of the fact that my devices are wifi-only, and usually get their wifi connection from my home router. So the only one affected by “excess data usage” would be me. Why does Google step in to say what I can or cannot do with my own connection (which by the way is NOT provided by Google) in my own home?

As for excess battery drain, again this should be a user adjustable setting. The current situation enforces battery saving measures even when they are NOT appropriate. Like when my device is connected to a USB charging cable, so the drain is not an issue. Why does Google care about this to the point of overriding how I want to use my device? If I want to drain my battery, shouldn’t that be MY choice?

I get it about these things being set as defaults so most people may get some benefits. But to not allow any way to adjust settings for different use cases, is just wrong of Google, especially when there is no impact to Google from these actions.

Not that saying any of this here has a snowball’s chance in Texas of changing anything about Google policy. Just trying to explain why it is a problem, and what apparently got lost in translation. My basic philosophy is that users should be able to use devices the way they want. Google apparently does not share that thought, which is why I avoid installing their apps.

I’d like to second the request in the original post. Is there any way of getting an exception to the rule, possibly even limiting the exception to only being for POP accounts?

Another possibility, I have seen some projects that have mostly similar, but not quite identical codebases between the Playstore releases vs the F-Droid releases. Usually this is to delete non-free features from the F-Droid version to meet their requirements. But couldn’t this go in both directions, to add features to the F-droid version that are not in the Playstore version? Such as adjusting the limit on the more frequent polling? Seems like an IFDEF to choose what value to set the constant to, based on what version is being built might work? In this case it could even apply beyond just POP accounts since F-Droid may not care about enforcing Google policy.

1 Like

Not possible. It is not the Google Play Store that prevents the <15 minute interval. It is the operating system of your phone itself, no matter where the apps come from.

They do own the oversight on the Android API. And that is the crux: Even though all your servers are OK with frequent poll, the operating system of your smartphone is not OK with that.

1 Like

This may be true for devices running Pie or Q. But my devices are older, from a time before that rule. Indeed, the fact that this is a recent change in even this app is exactly the reason why this very thread exists. It would seem there are many of us using older android versions and the real enforcement is happening at the app level.

1 Like

In deed, but if K-9 were to maintain the old API hooks, it would not be possible to offer it through Play Store.

So if people are supposed to find and install K-9 through the Play Store, it must adhere to the newer APIs (and be published as an AAB rather than APK in the future). Otherwise, it could maintain the old APIs, but it would only be available through F-Droid and other third party stores.

The restrictions apply to Android 8 and newer. Android 8 can use a compatibility mode where it still uses the old technique but this has two disadvantages:

  • Apps with compatibility mode (aka targeting an old SDK) can no longer be uploaded to Google Play
  • The phone shows a warning on the first app start telling that the app is outdated

It would be possible to write two independent sync services. One for Android <= 7.1 and one for recent versions. An app that did this could still be uploaded to Google Play. The problem is that maintaining two independent services is more than twice the work and the number of users with old Android versions is shrinking.