No IMAP only sync after reboot on Marshmallow, android 6

[das1996]

Before going through the trouble of a full factory reset I thought i'd look deeper into amplify (https://play.google.com/store/apps/details?id=com.ryansteckler.nlpunbounce&hl=en ).  That's about the only app installed that has any effect on disabling services/alarms.  I didn't see any active aqua entries under wakelocks, alarms or services in the program's lists.  It does however use an xml file which contains all entries, triggered and untriggered.  There were several untriggered aqua entries.  I deleted anything with the string aqua in it then rebooted.

Sent a few messages to myself using the pc.  Sure enough, a new email alert came shortly after the phone rebooted.  Without any further intervention!

Unfortunately I didn't make a note of which specific aqua entries I removed.  Been trying to improve battery life/reduce wakelocks and must of enabled something for aqua a few days ago.  The entry(ies) in question had some influence even though they weren't showing up in amplify as triggered event.

@Kostya, your last comment about the alarm above helped me make this connection.

Thanks to everyone for their help in trying to narrow this down.

[Kostya Vasilyev]

Glad to hear it got resolved, but...

I really wish that anyone messing with their Android system software would state this up front when reporting "bugs".

[das1996]

^^You are correct.  Thought I had undone all traces of modified system elements related to aquamail before even starting this thread.

Purpose was to try to reduce excessive wakelocks/alarms to improve battery life.  Was seeing quite a few more from aqua compared to k9/k@. 

[Kostya Vasilyev]

K9's IMAP IDLE code is missing a certain crucial piece

[Davey126]

^^You are correct.  Thought I had undone all traces of modified system elements related to aquamail before even starting this thread.

Purpose was to try to reduce excessive wakelocks/alarms to improve battery life.  Was seeing quite a few more from aqua compared to k9/k@.

Also important to recognize the presence of a wakelock/alarm does not always correlate to increased wake time and/or CPU utilization. AquaMail, GravityScreen, WiFi Manager and several other apps on my phone collectively generate thousands of wakelocks per hour. Device (deep) sleeps like a baby when no user interaction is needed. I also use Amplify, Greenify and other tools to manage apps/services that exhibit poor manners - mostly those related to location services. Amazon and Google are major offenders (should not come as a surprise to anyone). Rule of thumb: use a light touch and only target apps/processes/services/wakelocks that decisively demonstrate that they are bad actors. Side effects of limiting alarms/wakelocks are well documented - even if not well understood.

[Kostya Vasilyev]

Re: thousands of wakelocks per hour

I'm surprised it's not billions

AquaMail only uses one wake lock per push connection (acquired / released on every catch-up) and one wake lock for everything else (scheduled sync, syncing changes to the server, sending, etc).

So I guess we're talking about "acquire / release" cycles here -- but even so, let's say if we pick a scheduled mail check as a "scenario", the app acquires its "one" wake lock at the beginning and releases it when it's fully done checking mail, all accounts and folders.

I think there is something wrong with those numbers (or wherever they come from).

[Davey126]

Re: thousands of wakelocks per hour

I'm surprised it's not billions

Actually, the number is so large it has yet to be named (Wiki only shows identifiers up to Centillion which clearly underestimates the true magnitude). 

Kidding aside, the values come from WLD (Wakelock Detector) which I assume is reputable. Also backed by other apps that supposedly count wakelocks. Recall I said the collective total is thousands per hour which remains accurate according to WLD. AquaMail and WiFi Manager contribute ~100 per hour each which obviously vary by activity. Gravity Screen adds many more as does Google Location Services, expecially when the device is on the move. Settings in these apps are not ridiculously aggressive. That said, I also know neither of your apps contribute to excessive wake time or CPU utilization which was the point of my post. I don't view Alarms and Wakelocks as bad things. What apps do with the information is what matters.

[Kostya Vasilyev]

Re: AquaMail and WiFi Manager contribute ~100 per hour each

If by WiFi Manager you mean another little app of mine -- it only uses a wake lock when you start an "auto-scan" (where it scans the networks every few seconds, while the app is open on the screen). I just grep'd the code.

AquaMail acquiring / releasing a wake lock hundreds of time an hour also seems strange, I can only see it if the app was set up with more than a few (say over 3-5) push folders and the mail server was on the "nervous" side.

So no, sorry, those numbers don't make sense to me.

[Davey126]

re: So no, sorry, those numbers don't make sense to me.

Understand your take from a developer perspective but also have to meld what is being presented from well regarded tools like WLD that have stood the test of time. Either WLD is miscounting or ... something else.

AquaMail: One account, 4 synced folders (Inbox, Drafts, Sent, Trash), IMAP Push (1 hour duration), 1 Event type (app resuming), no scheduled sync, radios off while sleeping. I do use slightly different settings on various devices but no radical departures.

WiFi Manager: auto scanning is disabled (interval set to 15 sec) and Best Network switching is limited to 30 sec. Nothing crazy. This tool has been a godsend in our modest home that requires 3 APs for adequate coverage. Some devices have 'sticky' radios that don't like to let go of weak signals even sitting 3M from a strong AP.

[Kostya Vasilyev]

Re: your take from a developer perspective

Yes, I'm the one who knows what goes on on the inside

At least with WiFi Manager it's easy:

If auto-scanning is disabled then there are no wake locks at all. And then this auto-scan thing only works if you are running the app (I mean the main UI on the screen) and enable the "auto-scan" button.

The "best network switcher" deliberately uses the non-waking alarm type, the idea is that if the device is sleeping and not waking up, then there is nothing that could use the "better" network anyway.

---

But anyway, let it be thousands or billions, as long as it's not "kerjillions", if it makes those "detector" apps look more "interesting"

[Davey126]

Well - I can see where this is going and it's not a pretty place.

Focusing on WiFi Manager (hey why not; a good abuse of the AquaMail forum) something is generating events identified as wakeLocks by several respected tools that report remarkably similar results. Most have no motivation to amp the numbers: no paid version or excessive self promoting bling that suggest their app will solve the world's problems. Perhaps they all use a common code base that is flawed. Or perhaps something else is happening that is misaligning wakelocks with your apps. It is obvious WiFi manager and AquaMail are not a power pigs despite the ominous numbers (FUD alert). But one can't say all monitoring tools are generating inflated values for their own benefit. Someone would have called them out by now.

Time to disengage.

[Kostya Vasilyev]

Yes, I don't like this either -- because I do get users asking me from time to time about "thousands of wake locks in AquaMail".

Focusing on WiFi Manager -- I know the code, and grep'd it just now again.

There is only one place, one condition, under which it is "acquired", and so the "hundreds per hour" numbers don't make sense.

So from my, narrow, developer, perspective -- not a power user's -- the numbers reported by those app are just plain wrong.

But really whatever...

[Davey126]

re: So from my, narrow, developer, perspective -- not a power user's -- the numbers reported by those app are just plain wrong.

Having done my share of development I can appreciate the position: best practices, careful coding, attention to detail, meticulous testing, familiarity with every line/call/routine, etc. Then some power user (or average slob...my camp) presents a left field scenario that either exposes a soft underbelly, more commonly, falsely attributes evil to app/tool just going about its business.

I'll poke around and try to determine what combination of weirdness on my devices is generating pseudo wakelocks that get aligned with your apps. May be awhile as it's more of a passive vs active pursuit as nothing bad is happening. Blinking indicator light, wings level, engines on, nothing to worry about.

[Kostya Vasilyev]

I could buy this sort of "something happening that the developer isn't even aware of because the code paths and how they interact is just too complicated" -- for AquaMail.

For WiFi Manager, though, there really is one place where the app acquires a wake lock, the logic surrounding it is trivial, and based on what you wrote so far, you should not be hitting this case at all.

Unless, of course, there are some factors beyond my control -- such as Android internals acquiring wake locks on my behalf for whatever reason -- but those would be "implementation details behind the fence", and then I'd think they should not be "credited" to the app.

But in terms of my code directly acquiring a WakeLock, in WiFi Manager, it just doesn't compute...

[Davey126]

A bit more detail for WiFi Manager. A single AlarmManager wake lock is generated at an interval roughly corresponding to the timer setting in "best network switcher". Although this is a CPU wake lock no significant activity takes place...presumably because there is no receiver (or the receiver is not listening). So it amounts to nothing more than a heartbeat that turns the dials on apps that look for such activity.

Quick datapoints (12 hour period):
 - device #1: 1300 wake locks / 41s 'keep awake' time (WiFi radio on ~80% or 9+ hours)
 - device #2:   415 wake locks  /  8s 'keep awake' time (WiFi radio on ~30% or 3+ hours)

On both devices screen wake locks are only generated when auto scanning is active (1 per scan). Neither device attributed any wakeup triggers to WiFi Manager (as expected). AlarmManager wake locks only fire when the WiFi radio is enabled and connected.

Of possible interest (apologies in advance if this is insultingly basic; I'm not an Android developer): http://developer.android.com/reference/android/app/AlarmManager.html