I have an app that keeps the screen off when calling via bluetooth. It's a long story but for more context please visit http://www.rejh.nl/callscreenoff (not trying to spam, it's just to avoid the "why would you build an app for that?!" question)
Anyway. I have a problem. Everything works fine except that my Moto X turns on the screen a couple of (variable) seconds AFTER I hang up which makes it hard to determine if my app should lock the device (it could be the user who, after the call, immediately pulls his phone out of his pocket and wants to unlock it).
What I'm looking for is a way to detect which app caused the screen to turn on. Since I'm using a broadcastreceiver to detect USER_PRESENT and SCREEN_ON it would be nice if I could get this info in the receiver. Is there some data in the intent I receive about way I can find out which app caused the intent to fire screen to wake up?
Thanks in advance!
According to this answer it is not possible. The intent sender could put extras in the intent, which would give away the indentity of him, so your best bet would be either catching the intent in the debugger and inspecting the extras, or using an app for that, for example: Android Intent Intercept
Related
I know the android broadcasts an Intent to start an activity. I can use a Broadcast Receiver to receive that intent. But what is the actual way of receiving an intent if an app starts in Android as I don't know what can be the actual intent for an app be (Means I can get the list of installed android applications but how to know what intent will be broadcasted if a particular app starts) .
EDIT :
I'm just adding this as a feature in my phone that if a game launches, then the Immersive mode will automatically be opened. I've system priveleges as well (as I can make the changes in SystemUI or frameworks as well). I don't want to touch the Launcher though.
by this way . But it's still a little bit weird as solution . I don't think there's any simple way to do it...
some context:
I have an alarm app I use for myself that locks the screen when the alarm goes off for the duration you request prior. Essentially your phone is a ringing brick for x minutes. The only problem is my sleepy self is very irrational and in the morning I figured out that if I turn off the phone and get to the app location and uninstall it before the receiver gets called (boot completed) then I can bypass it bricking my phone. This didn't use to be a big deal when my LG G2 was on 4.2.2 because of how fast the receiver was called I would usually have to restart my phone about 5-8 times to uninstall the app before it was bricked so I just gave up and quit trying. Now, I upgraded to 4.4.2 and the receiver is called about a full 10 seconds later letting me delete the app on the first try every time. Making the app completely useless.
What I have tried:
I have tried using quick_boot in the manifest but I believe that this is only for HTC because on_boot doesn't get called for that OS for some reason. I have also tried the user present which only seems to work after the boot is completed when doing things like unlocking your phone.
Is there really no way to make onReceive be called quicker than onBoot? It would make sense if there isn't , I'm just hoping someone could provide a definite answer either way.
In some cases it is. I'm not 100% sure but i think (some) systemapps have higher priority then the ACTION_BOOT_COMPLETED event. AND there is ACTION_SCREEN_ON which should be triggered before ACTION_BOOT_COMPLETED.
I should have answered this a week or so after I asked this question because I found a pretty useful workaround, although, it is a little sloppy.
I made a new activity(homeLock) with the intent filter . homeLock extends activity and my old main activity(alarmMain) extends homeLock now instead of activity. All homeLock does is start the overlay service(so you can't stop the alarm/use the phone) that will be turned off by alarmMain when it determines whether an alarm should be ringing currently or not. In alarmMain there is a button now that says "change home" which lets you make homeLock the home application. Now, when you turn off the phone and restart to try and delete the application before onBootReceived is called which starts the broadcast receiver(triggers alarm and overlay) the homeLock activity is called which puts an overlay on the screen until it can be removed after the application determines if an alarm should be playing or not (after onBootReceived).
Basically, before you go to sleep just set this application as your home application from within the app or through settings. Now, it should be impossible to delete the application or turn off the alarm once it has started ringing until it has rung its duration because there will always be an overlay on the screen even when restarting the phone.
Obviously this addition is only needed for phones that boot slowly or extremely degenerate sleepers, or both like me. While it is unlikely this will help anyone because it is such a unique problem I thought I should post the workaround I have been using just in case someone does end up finding it useful.
I am trying to collect the starting time of different apps, that is the time when the user tab some app's icon.
I guess there may be an intent was sent to respond this event, if so, how to catch this intent, so I would know an app was just starting, and record the current time?
I guess there may be an intent was sent to respond this event
No, sorry. startActivity() only uses an Intent with the starting activity (and perhaps a chooser). There is no broadcast Intent regarding the start of an activity.
I am trying to collect the starting time of different apps, that is the time when the user tab some app's icon.
That is not really possible.
A classic workaround for this was to keep tabs on LogCat. This technique has been blocked as of Android 4.2.
Beyond that, you are welcome to try polling ActivityManager or some script-kiddie solution like that, if you don't mind blowing a lot of battery and don't need good accuracy.
I am not satisfied with any of the app locker programs for Android that I have found and would like to create my own, but I am having trouble figuring out how to implement the actual lock. How does one go about implementing an app locker for Android?
There are two issues:
Detecting an Intent, usually from the launcher calling startActivity() or from an ad launching the market app (I'm not talking about broadcast intents -- I need to handle explicit Activity Intents).
The permissions for the locker apps I have seen all have "read system log files" and/or "retrieve running applications" which suggests they might use polling to look for app launches. I think I could do this, but I would like to find a better solution if possible.
Preventing the locked app from processing the Intent. I would prefer not to allow the locked app to run at all until the passcode is entered since it is impossible to tell what it might do when it starts up.
When running my current app locker, logcat shows "ActivityManager: Starting activity" first with the Intent for the locked app, then again with the Intent for the app locker, with nothing in between (separated by 10-20ms). If I enter the correct passcode then I see "ActivityManager: moveTaskToBack".
I have experimented with a test app which demonstrates that, using my current app locker, none of the Activity callbacks are invoked if the app is locked and I do not enter the correct passcode. So it appears to be preventing the app from starting (but I don't know how).
I could use ActivityManager.killBackgroundProcesses() to stop an app, but I have no guarantee that the app hasn't already started running by the time it gets "killed".
I might be able to use PackageManager.setApplicationEnabledSetting() to prevent an app from being instantiated, but I don't think that will take care of apps that are already running (which shouldn't be allowed to process new Intents or come to the foreground). I might be able to use killBackgroundProcesses() to stop all running locked processes so they would have to be re-instantiated. But I don't like this approach because other apps could mess with the Enabled settings and defeat the lock.
Optimally, the system would send every Intent to my app for inspection and allow me to stop or let it pass through, but I'm pretty sure that's not possible (at least, not for explicit intents to start activities from a launcher).
Does anyone know how app locker apps are implemented, or have any bright ideas on how it could be done?
I would look into the lifecycle. Once the app in question begins to load, some activity from that package will be added to the forefront activity.
A scan of the changes in forefront activities might do the trick.
http://developer.android.com/reference/android/app/Activity.html#ProcessLifecycle
I am running into a critical conflict of sorts. My app is a remote service which essentially starts an activity when the screen goes to sleep. How it does this is very simple via screen off broadcast receiver and then an explicit intent to start the activity as a new task. The activity is basically in charge of responding to key events and displaying some simple text.
Thanks to a few window flags added in 2.0, activities can do this. They can be created in a way that either puts them on top of the lockscreen, or completely dismiss the lockscreen. This way they basically have focus without the lockscreen having to be dismissed by user. The alarm clock in 2.0 uses the flags to wake up the device and show the alarm dialog. I use them to place my activity when the screen sleeps so the user sees a custom wakeup lockscreen. The reason we create it at screen off is to get rid of lag the user experiences at wakeup involving first seeing the lockscreen, then seeing the activity appear. Also doing it immediately at sleep allows it to have focus so it can handle key events effectively.
The process works perfectly except in certain apps. So far, it seems the bug is consistent while browser (and even dolphin browser) as well as the facebook app are running. The bug never happens in GTalk or Launcher. It is rare but can still be duplicated in the messaging app every so often. I can't figure out why my activity doesn't get created at sleep while these apps are active. My remote service still gets the screen off broadcast and does the startActivity for the explicit intent, and that's all I get in the log. My onCreate is not being called. Instead it gets called when we wake the screen up again.
I have tried, as a control, to hold the partial wakelock starting when my remote service gets created, and the issue persists. So I don't believe it is a problem that the CPU has gone to sleep. Since only these particular apps cause the issue to duplicate, I can't imagine why the activity start fails. What could those apps be doing to interfere with another app's ability to get created? I use singleInstance as the launch mode so that I can ensure that the activity will never be able to be recalled by user process. I want it to go away when user unlocks and it is working fine like this, as long as it is able to be created. The singleInstance ensures I can have the same lockscreen handle an intent to do something specific based on user actions that the remote service monitors.
my source code can be viewed on my project page. http://code.google.com/p/mylockforandroid/source/browse/#svn/trunk/myLock/src/i4nc4mp/myLock
the issue happens to both my CustomLockService and NoLockService variations. These two services will start Lockscreen or ShowWhenLockedActivity and the bug is witnessed. The build illustrating the bug's end result-- user has to try to unlock 3 times due to the bug because on wakeup when the oncreate finally succeeds, user is seeing the activity when normally it would have auto-dismissed thanks to key event logic that also isn't seeming to happen due to the delayed onCreate, so they have to send it to sleep again. Now that the activity is properly done being started, and screen is asleep, the expected functionality happens at next wakeup-- can be downloaded also from the downloads tab.
This seems like an extremely irrational thing to be caused only by specific apps. I am quite baffled and out of ideas for a solution unless I've made some critical mistake in my activity definitions.
The answer is actually a bug in android that has been in review for a while. It has to do with the home key. For some reason start activity calls as new tasks are getting stopped after the home key has recently been launched. I never noticed the connection during the testing of this. The bug was not consistent and the factor of consistency was whether home button had been used during the wake in question
Here is the bug report: http://code.google.com/p/android/issues/detail?id=4536