High battery consumption

[kennylevinsen]

Battery statistics show very high network usage, and a resulting 7% battery responsibility over 16 hours. Kryptonite an Google Play Services are the only apps that high up the list (not counting Phone Idle, Android System and Android OS psuedo-apps), with the next app in line having less than half the battery blame of Kryptonite, despite being a much more used, always-online app.

Within the time counted by those statistics, 1 machine has been paired, and about 5-6 logins have been made, all while on WiFi. Key were already generated. There's definitely no activity that sensibly should keep the mobile radio active for 40 minutes, or send 6000 packets over WiFi. Analytics was disabled before any pairings were made.

I haven't read into the source enough to know if there's other connections than the one to Amazon SNS. It's definitely way too high for an idle notification channel.

Attached screenshot of statistics.

[kcking]

Indeed that is high, thank you for the report. We don't keep any persistent connections to SNS (that happens through Google's already-established notification socket). When the app is in the foreground it polls SQS, but should stop polling when sent to the background. I'll investigate this asap -- it seems to stop polling just fine on my pixel. What type of phone are you using?

[kennylevinsen]

Xperia X Compact running a stock 7.0 build (which is a fairly vanilla Android build).

Ah, I assumed that you were using SNS/SQS instead of GCM/Firebase, and thus had to maintain a connection for push yourself.

[kennylevinsen]

Do you log polling state by default? If so, I could keep an eye on logcat while playing with the phone after work. If not, I can add it myself, I just need to find your SQS poller and dust off Android Studio.

[kcking]

We do, right here: https://github.com/kryptco/kryptonite-android/blob/ae4001e408d67bac249ba5e79677ffe765cee95f/app/src/main/java/co/krypt/kryptonite/transport/SQSPoller.java#L36

Let me know if you see any odd behavior / find a way to reproduce it reliably.

[kennylevinsen]

Thanks for that pointer - I'll have a look at it later. I also had a quick glance at Silo, and the start/stop management seems to be fairly sensible. Nothing that immediately caught my eye at least.

[kennylevinsen]

A quick update: I have not had time to thoroughly test, but have also not seen the same battery consumption as in the above picture, as Kryptonite hasn't made it to the battery blame list at all since those screenshots were taken.

I have not had the app open at all, but have accepted a few login requests (not a whole lot, only using it for fun right now). While this means that I haven't exercised MainActivity lifetime, and therefore silo, it does at least indicate that Kryptonite shouldn't use a lot of battery in the normal use-case where you generally only interact with notifications.

[kcking]

Ok great to hear! I'll keep the issue open in case anything crops up

[kennylevinsen]

I just made a very unscientific test about how much Kryptonite consumed when open on the "Me" page. Kryptonite can easily be opened accidentally while poking with a request notification, so it's not unreasonable to assume that the app will end up open for a few minutes.

I took a snapshot of the battery statistics prior to the test, and after having the test open for 1 minute and 18 seconds, based on the "CPU total" measure (I was aiming for 1 minute, but oh well):

Type	Before	After
CPU total	5m 36s	6m 18s
CPU foreground	1m 35s	2m 27s
Keep awake	10s	10s
Wi-Fi running	0s	1s
Mobile packets received	11	11
Mobile packets sent	12	12
Mobile radio active	8s	8s
Wi-Fi packets received	597	683
Wi-Fi packets sent	648	737
Camera	3m 17s	4m 51s
Computed power use	40mAh	57mAh

The camera consumption seems very excessive, even compared to the first statistics I posted, and seems to indicate that the camera is almost permanently on while the app is open. I have not used the QR code scanning functionality at all during this statistics period, and have at most swiped past it while going from the "me" to the "devices" tab.

Network activity also seems quite high for a minute of polling. Perhaps polling is a bit too aggressive?

I have unfortunately not have had time to connect logcat and play - sorry about that.

[kennylevinsen]

I have opened #56 with an analysis of the camera problem, #57 opened for slightly suboptimal SQSPoller management.

[kcking]

Thank you for the stats! I think we can safely attribute most of the power consumption to the camera always being on when the app is open, which I have just pushed a fix to. For the time being I am going to close this issue, and continue discussion of #57 there.