I'm writing an Android app that mostly communicates with the user via status bar notifications. However, I would like to not bother the user if s/he is not really directly interacting with their phone. For example, if the user is using the navigation app or watching a movie. I think that the commonality between all (or most) of these kind of apps is that they keep the screen on. I believe an app can keep the screen on by using a WakeLock or by specifying a keepScreenOn parameter on their activity, there might be other ways.
I wanted to know if, before I am about to show a notification, I can check if another application is keeping the screen on so I can avoid bothering the user. I'd like to cover all options. I can see that WakeLock has an isHeld() method, but will that detect the other method?
Thank you,
I think the best you can get is PowerManager.isScreenOn();
Acquire screen bright wakelock with ACQUIRE_CAUSES_WAKEUP flag. U have to acquire this wakelock bcoz it will force the screen to turn ON if its not. Even if the screen is already ON, one can not guarantee it will remain ON till ur application is running unless u acquire the wakelock. Dont forget to release the wakelock when u r done.
I think you can just post notifications on status bar regardless of state - applications requiring full user attention will typically disable display of status bar altogether -
so no harm will be done by your updates.
Related
I'm trying to display a view that the user must dismiss each time they unlock their phone (it's intended to be annoying). It should be able to take a small amount of keyboard input, save it, then return to the previously open activity. I tried having a BroadcastReceiver listen for ACTION_USER_PRESENT and launch my own activity, but then I found out we can no longer listen for implicit intents, or have background services launch activities.
I'm not an Android developer (just trying to build something for my phone), but I did some looking, and I see a few options:
Display a full-screen intent. I think something like scheduling a job to raise a notification whenever the phone is locked, so that the notification appears first thing when they unlock the phone.
Use SYSTEM_ALERT_WINDOW and draw my view as an overlay whenever the phone is unlocked. My only concern with this is how apps like Twilight (which I believe draws an overlay to redden the screen) might interact with it. In those cases, I'd like my overlay to appear at the very bottom.
Are either of those options viable or recommended? Any other suggestions or approaches for how I could accomplish this would be greatly appreciated too. I'm just looking for some guidance on what direction I should pursue.
I'm writing a Kiosk app that, along with having some UI elements, also has a service that sits around in the background while the user explores other features on the device, and wish to re-launch the UI portion of the kiosk when the user has walked away. I figured that the most reliable way to do this is to listen for the screen to go dim and react to that event. However, I'm not seeing anything in the documentation about a system wide broadcast that I can listen to that the screen state has changed. Curious if I'm just overlooking it, or if it doesn't exist.
Take a look at this answer:
android.intent.action.SCREEN_OFF
FYI there is a full list of broadcast intents available in your sdk/platforms/android-xx/data/broadcast_actions.txt if you want to have a look. I found these two quickly, which led me to the answer I linked:
android.intent.action.SCREEN_OFF
android.intent.action.SCREEN_ON
I have a very simple question. Can you force an app (from a development point of view) to run while the phone is off and plugged in. I know with my phone there is a battery display that shows while the phone is off and charging which I assume is controlled by software but I was wondering if that is possible with an app. After research my gut is telling me no but I want to make sure.
I know with my phone there is a battery display that shows while the phone is off and charging which I assume is controlled by software but I was wondering if that is possible with an app.
This is not possible from an app, only from firmware.
If you are not looking to update the screen, you can use a WakeLock to keep the CPU on. Or, use a different WakeLock and keep the screen on all of the time. Neither of these will make the user very happy, unless it is done completely under their control.
You will need create Service and on create or when you are about to do whatever your app does, create and acquire WakeLock. Once it's done you can startForeground to let user know that you are doing some important job and let Android to keep you alive/process and let your app finish work.
In Android, you can go to system settings and enable screen locking whereby you can require a password, PIN, or some other means of unlocking the screen. This is typically used if you put your device into standby mode or it goes into standby mode after the screen dims out.
What I would like to do is to re-use this screen locking within my app but to prevent access to a particular activity. I would have a button that when pressed brings up the screen lock activity where the user must enter their PIN. If they enter it correctly, I then let them have access to the activity, otherwise they cannot use it.
Is it possible to re-use the screen locking activity in this scenario? If so, what API do I need? Would be nice if it worked on Android 2.3
EDIT:
Some of you are assuming that my app REQUIRES a PIN or password to operate. That is not the case. Users who want to protect certain data in my app can require it to have a PIN or password in order to view it. But why write my own password/PIN activity or dialog when the system already has one.
That kind of security is only available to inbuilt system components, like the settings app. Third party apps cannot request for the password dialog to be shown, and only continue working if the user enters the correct code.
Additionally, a decent amount of users simply do not have a pass code on their device.
You could look at KeyguardManager and KeyguardManager.KeyguardLock. There seems to be a change in how this functionality works starting in API level 13, but I'm not familiar with the topic in general, so you'll have to investigate that if you plan to go this route.
You are probably better off implementing something self contained in your app. It's very easy to cover the screen (perhaps with another Activity) or to hide UI elements programmatically and show an alternate UI with a password input field or something.
You can use the Screen locking feature from Android 2.2 itself.So, it will work in 2.3 easily.The method to use this feature can be done in basically two ways.
1st one is.
There are two way you can lock the screen:
PowerManager manager = (PowerManager) getSystemService(Context.POWER_SERVICE);
manager.goToSleep(int amountOfTime);
The second one is
PowerManager.WakeLock wl = manager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,Your Tag");
wl.acquire();
wl.release();
The permission is also needed.that is
<uses-permission android:name="android.permission.WAKE_LOCK" />
I have a Service that keeps the display on at a dim level at certain times, and it uses a 'dim' WakeLock to accomplish this. It works well... except that the screen never locks. That is, while the dim WL is held, the lock screen never appears requiring the user to swipe and authenticate.
Note that I'm developing on a platform that may have vendor changes to the low-level Android Java framework code, so this might not be standard Android behavior. But also, I have access to the framework code and can change it, if necessary. I just can't figure out where this policy is enforced in the code.
When the device is on external power, we want to keep the screen contents visible - but we still want it to lock.
The only way I can think of to do that is for you to maintain your own timer for when to trigger the lock, then to use DevicePolicyManager and lockNow() to lock the device at that point. This requires extra permissions and extra setup work (enabling your app as a device manager).