AquaMail Forum
English - Android => How do I... => Topic started by: das1996 on March 12, 2016, 04:05:52 am
-
Hello.
Have aquamail setup up to view 2 accounts, 1 folder each. Imap works fine if I open the app at least once after reboot.
However unopened, it doesn't appear to receive after rebooting the phone.
I've messed with the various keep alive options and network settings but can't seem to make this happen.
Note, I'm not using any polling or other timed sync. All I want is imap functionality only.
Thoughts, suggestions?
Thanks!
-
From you implicit description, I assume you enabled PUSH.
You want to enable scheduled check in the background.
Push only keeps the connection alive after the connection is opened.Scheduled sync does that.
(BTW, that all is done via IMAP)
-
Yes, push is enabled.
What settings do I choose under the scheduled sync once it's enabled?
Specifically for mail check interval, custom check interval, and time reference point?
As you point out, the connection needs to first be opened after a reboot.
I've already tried the scheduled sync with
mail check interval : 24 hours
custom check interval: not specific
time reference point: 12:00 am
settle in delay: 15 sec
Only screen is off: unchecked
wifi in sleep mode : unchecked
Imap is checked in the next section.
-
mail check interval : 24 hours
To me, the combination of this with PUSH enabled sounds like: "I don't want my mail checked, but I'd like to know immediately when it arrives". While, depending on the server, it may work, but it seems to me unstable, or at the very least, unreasonable. (I will avoid boring you with the technical details, especially since I am too sleepy at the moment to describe them.)
If you want immediate information about the arrival of messages (hence the PUSH) at all times, I'd set the mail check interval to 15 or 30 minutes and keep the PUSH enabled.
As for other parameters, in Aquamail, the default values are pretty reasonable, especially for people who do not have experience with fine-tuning an e-mail app. In your case, (if you really want the immediate notification about message arrival), I would start from all the default settings and just enable PUSH (for details on that and other topics, please see the FAQ http://www.aqua-mail.com/?page_id=227 ).
But be aware that PUSH (compared to just scheduled checking at some reasonable interval, say 15-30 min.) will increase your battery and data consumption.
-
I've been using k9 for years, and more recently k-@ mail. Both of those allowed me to configure the client such that no periodic syncing was needed, only push email (imap) was configured and worked. In fact, the whole reason for going to k9 was because the stock android email clients offered very little configuration.
This is the type of functionality I'd like to get out of aquamail.
I've configured countless email clients, so generally have a good idea of the workings behind the scene. Aquamail gives ultra fine granular control of many aspects of an email client. This was part of the reason for switching over.
I did enable scheduled sync with a 24 hours mail check interval. This didn't work. It failed to retrieve a message that was sent as the phone was rebooting.
Assuming it did work, it seems like enabling periodic sync is more a bandaid for a simple function such as "enabled at boot". I don't want it to check every xx minutes, rather I want emails delivered instantly as they're 'pushed'.
I wonder if the fact that device is on android 6/marshmallow is somehow affecting all of this.
I understand push may cost more in terms of battery or data, I'm ok with this (to an extent).
-
I have a domain on a shared server at mddhosting.com (s3.supportedns.com is the mail server, port 993, encrypted connection).
Appears to be dovecot.
Gmail might be handled differently as it may involve GCM.
-
I think I found the problem. I used titaniumbackup to duplicate the settings to a 5.0.1 phone. Rebooted. App started properly on it's own as expected with only imap enabled.
So, appears to have something to do with the way marshmallow handles app initialization at phone boot up.
Under LP, in settings, apps, aquamail, under permissions there is "run at startup" present.
Marshmallow won't show me the full list of permissions, just showing calendar, contact storage permissions.
------------------
Edit: settings, developer options, running services. After boot, no entry for aquamail. Refresh running services after running the app now includes it, along with 2 services (syncstart being one of them).
-
It might be indeed that in your case, something is preventing Aquamail from starting (or starting properly). I don't know that part.
If that's the problem, then setting syncing would not matter. You need to find the reason why Aquamail does not start upon booting. Sorry, I don't use Marshmallow, and don't know all its intricacies.
As for setting periodic sync, from what I know (and Kostya, Aquamail's developer might shed more light on this), some IMAP servers might not maintain the connection beyond certain period of time (30 min? 1 hour?).
I don't remember for sure, and I don't feel like search for it now, - it might be that IMAP IDLE (aka PUSH) specifications do not require the server to maintain the connection indefinitely.
So, even if the setting for PUSH in Aquamail is set to a long time, the server may drop that connection. That's why it just makes sense that Aquamail starts the connection every so often (and not once a day). And, of course, when you switch to a difference network (Wi-Fi vs mobile network) you connection can also drop (as you change the IP address).
That's the reason why it makes sense to do periodic sync. That's my view on it. I might be overly conservative. But in any case, - I do not see any downside for periodic sync, and I don't see any rational why you do not want that to happen.
-
One issue at a time. Your point on periodic sync is valid. Once this startup issue has been resolved then I can focus on whether or not the server in use requires the periodic sync enabled.
I can't say I've been overly impressed with MM. Sure it brings some new features, but also breaks a number of things - IE, if portable storage is used rather than adopted, apps can no longer be stored on the sd. In the case here, it forces the developer to in essence re-invent the wheel to comply with the new OS requirements otherwise things don't work right.
The phone in question is the moto x pure (style). I'd gladly go back to lollipop but there's few custom rom or kernel options available. Given the nature of motorola's almost stock android UI, I'd prefer to stay stock based rather than going with something aosp. These days most development has been MM based.
I'll await to see the developer's comments.
-
Re: I can't say I've been overly impressed with MM. Sure it brings some new features, but also breaks a number of things
Just wait for N, they're continuing down same path.
Re: Gmail might be handled differently as it may involve GCM.
And they're having widespread issues where it falls behind server state by hours. I'm seeing it on my Nexus 6P too.
---
And the issue at hand.
In general, I don't recommend turning off scheduled sync (or making it so infrequent) even if push is enabled.
- Scheduled checks act as a safety net for push code
- Typically you will only have push enabled for some of the folders -- and so scheduled mail checks will get the rest
---
Now that being said... Push should start after a reboot.
Does your phone have some sort of "fast reboot" feature, where the device doesn't really reboot, it just kills all apps and restarts the launcher? HTC used to do this, and it was even enabled by default.
With "fast reboot", the system does not send the usual "a reboot has completed" broadcast to the apps.
So if you do, please try turning that off.
---
And ultimately, I'd like to see a debug log capturing the issue (please see the link in my signature).
You will want to enable logging, then reboot the phone, and wait for 3-5 minutes before starting up the app's UI (I assume that push will start up at that point).
-
@Kostya
Re: fast reboot. I'm familiar with this restart method and no, it is not in use on the moto x pure. All reboots are complete.
Raw log as requested is available @ http://pastebin.com/ixgGXnLp
I've obfuscated any and all personal identifying information for privacy reasons. Hopefully it sheds some light as to what's happening after the reboot.
Edit: From my uneducated log reading, I think this "conn. null" entry that appears several times before the app is actually launched may have something to do with it.
Further down, after the app is launched, around line 471, there's no longer a null after conn.
-------------
Unrelated, re MM:
Among other things mentioned I'm finding sleep patterns to be less than desirable. Phone loses ~8% battery over night with airplane mode on. I'm still tweaking various things, but almost seems like it does better with wifi on. I have a feeling it may be wise to just downgrade to 5.1.1 and call it a day (assuming that works correctly and sleeps well).
-
Thank you. You can delete the log from pastebin.com now if you wish.
Yes, the reboot is proper, not "fast".
2016.03.13 09:30:13.644
Android notifies the app that there is now a network connection
The app schedules an event for 15 seconds later (to actually start up push mail)
This event is not received.
I wonder if the device is in Doze mode (initially) after the reboot?
-
In doze mode with the screen on?
Reboot process goes something like this:
Reboot phone, unlock once the lock screen shows, then wait a min for it to settle. Once settled, send a test message.
How are you determining the event is not received?
-
I just did same test on my Nexus 5x (6.0.1 stock), with your settings (scheduled sync off, push on).
2016.03.13 13:48:14.011 -0400 PushConnectivityReceiver [][][][][] onReceive ConnectivityManager.CONNECTIVITY_ACTION: ni = [type: WIFI[], state: CONNECTED/CONNECTED, reason: (unspecified), extra: "Despotica", roaming: false, failover: false, isAvailable: true]
2016.03.13 13:48:14.012 -0400 PushConnectivityReceiver [][][][][] Currently active network info: [type: WIFI[], state: CONNECTED/CONNECTED, reason: (unspecified), extra: "Despotica", roaming: false, failover: false, isAvailable: true]
2016.03.13 13:48:14.013 -0400 PushConnectivityReceiver [][][][][] Scheduling the delayed alarm
2016.03.13 13:48:14.014 -0400 AlarmCompat_api19 setWindow: 0, 1457891299013 (2016-03-13 13:48:19) 5000, PendingIntent{4ea362b: android.os.BinderProxy@bab7e7a}
2016.03.13 13:48:19.045 -0400 PushConnectivityReceiver onReceive: intent = Intent { act=org.kman.AquaMail.ACTION_CONNECTIVITY flg=0x10000014 cmp=org.kman.AquaMail/.core.PushConnectivityReceiver (has extras) }
2016.03.13 13:48:19.046 -0400 PushConnectivityReceiver [][][][][] Starting the service to start watchers
This is the "delayed alarm" above.
In your log, the line where the app sets this alarm is present:
2016.03.13 13:48:14.013 -0400 PushConnectivityReceiver [][][][][] Scheduling the delayed alarm
2016.03.13 13:48:14.014 -0400 AlarmCompat_api19 setWindow: 0, 1457891299013 (2016-03-13 13:48:19) 5000, PendingIntent{4ea362b: android.os.BinderProxy@bab7e7a}
but the alarm does not go off (does not trigger):
2016.03.13 13:48:19.045 -0400 PushConnectivityReceiver onReceive: intent = Intent { act=org.kman.AquaMail.ACTION_CONNECTIVITY flg=0x10000014 cmp=org.kman.AquaMail/.core.PushConnectivityReceiver (has extras) }
-
I see what you mean.
I've got a few xposed modules running (gravitybox and amplified). I don't recall setting any entries for aqua in amplified. I don't think there's any settings in gravitybox that would affect aquamail.
Maybe there's some other glitch or corruption. It'll be easy enough to do a factory reset and restore several apps at a time from titaniumbackup, reboot and test.
-
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.
-
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".
-
^^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@.
-
K9's IMAP IDLE code is missing a certain crucial piece :)
-
^^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.
-
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).
-
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.
-
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.
-
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.
-
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" :)
-
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.
-
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...
-
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. :)
-
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...
-
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
-
Re: AlarmManager wake locks only fire when the WiFi radio is enabled and connected
Then those are internal to Android code.
Re: A single AlarmManager wake lock is generated at an interval roughly corresponding to the timer setting in "best network switcher
And those are too.
Re: http://developer.android.com/reference/android/app/AlarmManager.html
If you look at "constants" there you'll see "RTC":
"This alarm does not wake the device up; if it goes off while the device is asleep, it will not be delivered until the next time the device wakes up."
And my code in "best network switcher" is like this:
mAlarmManager.setRepeating(AlarmManager.RTC, now + interval, interval, operation);
So I suppose what may be happening -- since it's a "no wake up" alarm type, the system will not wake up the device just for that.
OK, but if the device already is awake (for other reasons) the Android "alarm handling" code might acquire a wake lock, *while it's delivering this alarm to the app* to avoid possible "race conditions" -- i.e. the device being awake, the system code deciding to deliver the alarm, then the device falling asleep in the middle of that.
---
Getting back to AquaMail -- I suppose there could be wake locks internal to Android implementation of some things.
One thing comes to mind is -- even though the app does not use "system settings -> accounts -> various "sync" things" to actually check mail, it does trigger a "sync" there (just so the "last sync time" there updates, for the user to see).
The sync operation (as far as "system settings -> accounts" goes) is "dummy", a "no-op", takes a few milliseconds, but I suppose Android could acquire a wake lock while processing it.
-
I refrained from immediately commenting as I wanted to observe behaviors on several different devices over an 'extended' period (in this case 1 week).
In the end I come back to what was said at the top of the wakelock conversation:
- Android (not some random app) attributes numerous wakelocks to WiFi Manager and AquaMail..fairly or unfairly
- In the case of WiFi Manager these wake locks have NO ADVERSE IMPACT on device performance or wake time
- AquaMail wakelocks can keep the device awake for brief periods but for good reason as the device is executing functions requested by the user. If you don't like the wakelocks turn off IMAP push, scheduled sync and event based sync actions
Of course the developer already knew this but I felt it important to close out the discussion as I was the one who initiated the wakelock distraction in response to a comment from the OP who suggested AquaMail generated more wakelocks than other mail clients (see Post by Davey126 on March 16, 2016, 04:25:25 pm).