6

SECURITY ISSUE: I don't now how it happens, but readers of this questions come up with idea that solutions to this problem is a security threat. So please keep in mind, all data I am interested in is measuring time of user in/activity. That's all. What user did -- I am NOT interested at all!

What I need is very simple concept, but I cannot find a solution. I would like to run a process (in the background) and have a listener to user interaction.

So, user touches screen --> my method is triggered.

User unlock phone --> my method is triggered.

User types on physical keyboard --> my method is triggered.

So in short my method is NOT triggered when the phone lies still on the table :-) Please note, that the interaction is with entire phone, not with my app, and I am not interested that user typed letter "K", I am not even interested that user typed something, all I care is the user used the phone in some way.

Btw. the state when user is walking listening to music (phone in the pocket) -- it is NOT interaction.

What I am looking for is a trigger -- something like INTERACTION_DETECTED, or (conversely) a callback method which is set like reportInactiveUser(10*1000) and it would be called if user was inactive for 10 seconds.

QUESTION how to detect user interaction?

Purpose: to measure the time of using manually the phone.

(lack of) PROGRESS

I found out that BatteryStatsImpl could hold the data I need. The instance of it is kept by BatteryStatsService, which however does not let any access to it, only IBatteryStats which in turn has only one interesting method -- getStatistics and the output does not include user activity counters (or they are all zeros; I set all permissions on). So, so far -- bad luck.

All calls have to be made by reflection, because those classes are not available anyway ;-).

greenoldman
  • 16,895
  • 26
  • 119
  • 185
  • 1
    have you tried looking at this quesition? http://stackoverflow.com/questions/3757220/android-reading-user-input-in-a-service – maxko87 Aug 02 '12 at 17:19
  • @maxko87, doing it now, thank you very much, looks promising! – greenoldman Aug 02 '12 at 17:29
  • 1
    It's a basic design goal of android *not* to let background tasks have awareness of what the user is doing - with some specific exceptions where the involvement of a background task is considered legitimate. – Chris Stratton Aug 02 '12 at 20:58
  • 2
    @Macias - it is no way absurd. Because you aren't considered to have a legitimate reason for knowing what the user is doing, the hooks that would let you know that they are doing something (even without knowing what) are few in number, and those that do exist are gradually being closed off in newer versions. A lot of apps that depending on parsing the log as a workaround for things in conflict with the android designers' vision just got shut out in JellyBean for example. You don't have to agree with the design philosophy (hardly anyone does in its entirety) but going against it is not easy. – Chris Stratton Aug 02 '12 at 22:20
  • Blaming people of things here will not get you anywhere. Read your question one more time. You say: "user touches screen --> my method is triggered. User unlock phone --> my method is triggered. User types on physical keyboard --> my method is triggered." I am not the one making them up. I directed you to libraries you can use to intercept that and told you you can only use them within an application context. Now you are coming back, claiming you didn't want any of it and I am imagining things in my own world. People here are trying to help you by telling what you cannot do. – Erol Aug 03 '12 at 06:57
  • Also, a screen saver is not the same as what you desire. Additionally, Android doesn't have a screen saver, it has a lock screen and if you want to design a custom one, it is called a "hack". So Android, in NO WAY provides official means for you to intercept any type of user action you desire outside an application context. You are on your own after this point because you are too stubborn to accept the help people are offering you and taking them as dumb instead... Good luck on your endless journey. – Erol Aug 03 '12 at 06:59
  • @baba tenor, yes you are imaging things -- entire question counts. And I explicitly wrote that I am not interested if user typed K, or even if user typed anything. All what counts is the fact user interacted with phone -- so any kind of interaction (phone unlocked, screen touched, text typed) should trigger my method. – greenoldman Aug 03 '12 at 08:25
  • I am not helping someone who turns things around to blame people who are trying to help him. Good luck with your journey macias, hope you will find some help with this attitude. No surprise you didn't get any replies to your question, other than mine. – Erol Aug 03 '12 at 15:16
  • @greenoldman: Hi.. Have you figured any solution for this?? – Aada Apr 10 '13 at 12:06

1 Answers1

0

You want to intercept physical interactions with the phone for that.

For screen touches, this package will come handy. *You can use this to listen for gestures on the screen.

For physical button touches, I suggest you have a look at this.

Erol
  • 6,478
  • 5
  • 41
  • 55
  • I don't think you will be able to detect it without your application running in the background or a service of your own. Otherwise, it would be a very suitable environment for taking control of the phone and you don't want that. – Erol Aug 02 '12 at 20:43
  • No, the security threat is not about the user playing with the phone but with the application you design, taking control of actions you do outside your app. How would you welcome it if I had an application on your phone that intercepts every hardware key touch and connect you automatically to my spamming website. You would be able to detect this malicious behavior if it was happening when you were using my app but if there is no app around and I am still able to read your system-wide gestures and dig your hole in the background, how will you identify the threat? – Erol Aug 02 '12 at 21:43
  • 1
    To keep things short -- as you already pointed out, your approach cannot work because of security reasons. If I am wrong, please correct me. – greenoldman Aug 03 '12 at 08:15