The problem is the attack surface for an app on a device vs. in the wild is much, much larger and much, much less secure.
Once its on your phone, it can just screenshot things if nothing else.
Once its on your phone, it can just screenshot things if nothing else.
The other thing it does is with a tap and waiting for the same random number of ticks is to copy the value to the clipboard so that I can paste it into a browser.
Not perfect but its a version 1 at least.
It's the most recommended password manager on Hacker News.
Beyond what I described above, I need something that works on Windows and Windows Phone, and I need it to securely sync between the two.
https://discussions.agilebits.com/discussion/12133/1password...
[0] http://android.stackexchange.com/questions/10930/why-do-we-n...
======
Using hardware partners
Now we get into the solutions which require commercial action.
Talking to the Android chipset makers often presents a solution. Since they design the hardware, they have access to the framebuffer - and they often are able to provide libraries which entirely avoid the Android permissions model by simply accessing their custom kernel drivers directly.
If you're aiming at a specific phone model, this is often a good way forward. Of course, the odds are you'll need to cooperate with the phone maker as well as the silicon manufacturer.
Sometimes this can provide outstanding results. For example I have heard it's possible on some hardware to pipe the phone hardware framebuffer directly into the phone hardware H.264 video encoder, and retrieve a pre-encoded video stream of whatever is on the phone screen. Outstanding. (Unfortunately, I only know this is possible on TI OMAP chips, which are gradually withdrawing from the phone market3).
======
Probably not something an average crapware author can do, but certainly within reach of the NSA.
If it can't run, how can it screenshot things?