My application has an activity that is launched by a BroadcastReceiver when android.intent.action.BOOT_COMPLETED broadcast is received.
The activity should be shown full screen over Keyguard (secure). Activity is using Theme.NoTitleBar.Fullscreen theme, set in the app manifest and WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED to put the Keyguard behind.
I am not trying to replace or disable keyguard any way. The activity should just show some diagnostics info about the device and it should remain active until user closes it.
So, the device boots up, keyguard usually appears and the after few seconds activity is also launched. Activity is displayed nicely over the keyguard in full screen mode without title bar. All this worked fine on my Sony and Samsung test devices.
Today I was testing the app on LG G2 device (Android 4.4.2) and noticed a strange issue. The problem is that the fullscreen activity is dismissed (paused) and keyguard is brought up again.
I spent half day going through the code and trying to figure out what is causing this behavior. Then finally I noticed that my activity is dismissed every time when system notification is shown in title bar. In my case the notification is "Battery full" and "Unplug to save battery". I did not had a chance to test, but probably same will happen with other notifications.
Is there a way to suppress system notifications or ignore, so the full screen activity won't be paused?
Try with below code snippets,
Intent intent = new Intent(Intent.ACTION_CLOSE_SYSTEM_DIALOGS);
this.sendBroadcast(intent);
This is broadcast when a user action should request a temporary system dialog to dismiss. Some examples of temporary system dialogs are the notification window-shade and the recent tasks dialog
Refer ACTION_CLOSE_SYSTEM_DIALOGS
Related
If I set a timer in the default Android clock app, then it has the following behavior when the time runs out:
If the phone is unlocked, a pop-up comes up allowing you to stop the alarm or navigate back to the app.
If the phone is locked (including if the screen is off), the screen turns on and you're taken to a special Activity to stop the alarm.
What is the best way to reproduce both of these behaviors in my own app? I've been copy-pasting various magical incantations involving AlarmManager for the second, but nothing is working. None of the questions that have come up when Googling things like "bring Activity to front" or "wake up phone" seem to be what I need.
This can't be done, and it's by design. There are 2 separate problems, and they're both impossible to implement.
Google has progressively disabled the ability to launch activities without user interaction in all recent API versions. They also disabled "springboard" behavior, where background services and/or receivers try to start activities from the background. You're supposed to use notifications to let the user know what you're trying to do, and when they interact with that notification, then your activity can be launched
There is absolutely no app, unless you have a custom ROM or a rooted phone, that can bypass the lock screen. It's a security issue, and the idea is the same as in the previous case -- you need to notify the user, and if they interact with the notification, they can be prompted to unlock their phone and your activity will launch
I have an weird situation regarding an alarm app. I have an app that is "awake" the all night and at certain point the alarm starts and is the user press the back button or a button in the User Interface (UI) the alarm sound stops and move to the next activity (until here everything is Ok!)
The scenario is: The screen is deemed, the alarm starts so the activity is launched and the user press the power button. After it press the power button again (the activity starts again) and press Home button.
Pre-Lollipop
The app is running in background and the alarm is still ringing(normal behavior)
Lollipop
The screen becomes black, the user can't do anything on his phone until he reboots and the alarm is ringing
Did you have experienced this before? I see there are lots of black screen issues with lollipop but I only see "solutions" from user point of view and I would like to make my app avoiding this issue.
This issue was related with the keyguard, I was disabling the keyguard when the intent of the alarm was received because I wanted to disable the lock screen, but I realized the best place to do that is in the method onResume.
So I move the disable keyguard to onResume and enable keyguard to onPause and that made the trick
My app wakes the phone from standby and turns on the screen (SCREEN_BRIGHT_WAKE_LOCK). I can't use the WindowManager-flags approach, as my app may already be running in the background.
The problem is that once the user dismisses my app and the WakeLock is released, the screen turns off immediately, even if the user was interacting with the app (or the homescreen, which briefly shows while the app is being closed).
Would using the ON_AFTER_RELEASE-flag help?
Yes, you want to use the ON_AFTER_RELEASE flag.
When this wake lock is released, poke the user activity timer so the screen stays on for a little longer.
I am trying to disable the keyguard when SCREEN_ON is trigged. The following code is in a service run by the broadcast receiver of ACTION_SCREEN_ON:
KeyguardManager myKeyGuard = (KeyguardManager)getSystemService(Context.KEYGUARD_SERVICE);
myLock = myKeyGuard.newKeyguardLock();
myLock.disableKeyguard();
startActivity("xxx");
This seems to work, but there is a problem. After the screen is on and my activity is displayed bypassing the keyguard, if the user presses the home button, the lockscreen is displayed, and if the user unlocks the screen, the next time the screen switches on, the keyguard is not disabled. I have to manually unlock the phone, and the activity is indeed running behind the lockscreen. So only the disablekeyguard() seems to stop working.
Any help with be appreciated:)
Apparently there is ambiguity in how the Home key events handled by Android. The OP of a post here seems to be facing the same problem. No answers to his query yet.
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