I’ve been a very happy Dashlane Android user for many months now — I’m ecstatic to have a password manager that just works between all my devices, encrypts my passwords in transit and at rest, and has a responsive dev team. First, some background on In-App Login.
The killer feature
When I first migrated from Lastpass, I noticed that Dashlane was missing one critical feature: In-App Login. If you’re unfamiliar, when you are at a login screen in any app, Lastpass will pop up a dialog (using an Accessibility Services plugin) to fill in the username/password for you. Dashlane was missing this feature, and when I asked for it in a Play Store review, the devs were quick to respond that it was in the works and coming soon.
Sure enough, they added it in a couple months later, circa May 2015. It looks like this:
I bumped my review to five stars, and all was right with the world.
Months of Molasses
But there was trouble afoot. My phone, a Nexus 6 flagship, was slowing down, and it seemed to have gotten even worse since the 5.1.1 update. The battery life, already straining to get through a full day, was sucking even more. As is usually the case with battery life and performance problems, I couldn’t pinpoint the cause. But when I began developing daily on my phone at my new job (Android fulltime, yo #whatup), I noticed something peculiar in the phone’s logcat:
It was filled, absolutely packed with this spam:
08-24 20:34:53.896 12798-13163/? D/DL﹕ Analyzer - Starting Analysus 08-24 20:34:53.909 12798-12798/? D/DL﹕ Analyzer - Analysis finished, result:null
08-24 20:34:53.912 12798-12798/? E/DL﹕ Linking NOT approved, forwarding call to In-App login popup
08-24 20:34:53.973 12798-13210/? D/DL﹕ Analyzer - Starting Analysus 08-24 20:34:54.017 12798-12798/? D/DL﹕ Analyzer - Analysis finished, result:null
08-24 20:34:54.022 12798-12798/? E/DL﹕ Linking NOT approved, forwarding call to In-App login popup
08-24 20:34:54.053 12798-12839/? D/DL﹕ Analyzer - Starting Analysus 08-24 20:34:54.070 12798-12798/? D/DL﹕ Analyzer - Analysis finished, result:null
08-24 20:34:54.072 12798-12798/? E/DL﹕ Linking NOT approved, forwarding call to In-App login popup
08-24 20:34:54.164 12798-12849/? D/DL﹕ Analyzer - Starting Analysus 08-24 20:34:54.165 12798-12798/? D/DL﹕ Analyzer - Analysis finished, result:null
08-24 20:34:54.169 12798-12798/? E/DL﹕ Linking NOT approved, forwarding call to In-App login popup
A few questions:
- Who or what is
- What’s it analysing?
- Why is it doing this almost 20 times a second?
- Who misspelled “Analysis”?
Sherlocking towards a solution
After some fruitless google searches for these log messages, I was left to rely on the few clues I had. “Analysus”? (Hmm, probably not a system app, that wouldn’t make it past Google’s code review.) In-app login? (Wait a sec…) DL? (Download? Hmm.. DASHLANE?)
Sure enough, I ran
top inside a terminal emulator on the phone and scanned the output. A Dashlane-related process was sitting at a constant 2-10%.
That was enough probable cause for me. I went into the Dashlane app and disabled the In-App login plugin. The log messages stopped, and my slow, underpowered, overheating phone became as quick and spry as the day I got it. I could almost hear the CPU sigh in relief as months of busy tight-looping came to an end.
Dear Dashlane dev team:
Rework this implementation. At the very least, the In-App Login plugin should not be checking so often for input fields (which is what I presume the “Analysus” involves). Once every 3–5 seconds should be plenty and result in a 99% decrease in CPU usage. You could cut it back even further by maintaining a whitelist of apps you support and only running the analysis when those apps are foregrounded.
It’s worth mentioning that even with In-App login disabled, Dashlane still blows every other password manager out of the water. You’ve built a great product, and the In-App Login feature is still relatively new. With a more mature implementation, it could be unstoppable.
Oh, and while you’re at it, could you please change your logcat tag to
Dashlane instead of
Dear Google Android dev team:
Please improve the Battery Usage screen to better display consumption from these background processes. I would have caught this way, way earlier if the
DL process weren't unhelpfully glommed together with a bunch of other stuff under
Android OS and
Android System. When each of those are using upwards of 16% battery each, it leaves the user helpless to figure out what to disable to stop the battery drain... how about a
top-like display of total cpu-time used per process since the last charge?
Originally published at www.aphex.cx on August 25, 2015.