Im using Zebra TC25 DWDemo profile for our app, after enabling broadcast intents for bar code reads. all works well when my app is on the foreground and the screen is on. but once i close the screen with the device power button it stops getting broadcasts and the scanning barcode hardware is not responding. (the red laser read lights dont respond to clicks on the side buttons anymore).
I made sure to successfully acquire a partial wake lock (by logging mssgs on logcat while the device screen is off) and have registered a WakeFullBroadcastReceiver for getting the hardware's broadcast intents.
What to do in order to keep the hardware active and getting barcode reads and broadcasts to my app while device's screen is off and the CPU is kept awaken?
The DWDemo app is using DataWedge to capture scan data, specifically the 'DWDemo' profile and you can see this if you go to the settings screen from within the app. DataWedge is a separate service on the device and just because your app has a partial wake lock I'm pretty sure that does not prevent the DataWedge service from still sleeping when the screen turns off, plus you would need to consider other scenarios like the device entering doze mode and clearing existing wake locks. DataWedge is designed primarily to change the scanner configuration when different applications appear in the foreground; when the screen turns off the app goes to the background as far as Android is concerned so DataWedge would also likely switch out of the 'DWDemo' profile anyway.
For your needs I think it would make more sense to access the scanner directly via the native SDK, EMDK which is available for both Android (Java) and Xamarin. Another future option I notice is Zebra are introducing a 'Wakeup sources' parameter (http://techdocs.zebra.com/mx/powermgr/#wake-up-sources-enabledisable) however that requires MX8.0+ which is not (yet?) available for TC2x since MX8.0+ would require Oreo, based on the naming.
For clarity, I work for Zebra.
Related
I need to detect when the android smartphone goes into lock screen mode and when it comes out.
I need it to be able to bring a service respectively in start foreground and stop foreground so that the location sensor continues to work both when the smartphone is off (on lock screen) and when it is on.
Is there a fast way to do this detection without having to use the kastri library?
Prefer not to be dependent on the kastri library. That's why I asked for this.
I am creating an Android app (Java code) that has an audio call feature.
I managed to make it work using the webRTC framework.
I wanted to make my audio call behave like WhatsApp and Messenger, where those apps keep the audio call running even if the user stops the app from apps history, or starts using another app.
So, I decided to migrate the webRTC code from an Activity to a Foreground Service.
My Audio Call Activity handles the UI, displaying friend photo, name, call timer ...
So I had to make communication between my Activity and my Foreground Service through binding and sending android.os.Message object.
Everything works fine when using SAMSUNG devices, if I kill the app, I could return to the Call activity by clicking the foreground service's notification, and the audio call keeps working until I hang up.
My problem appeared when i used a Xiaomi device (redmi note7), if i kill the app, the audio call stops, cause my Foreground Service is restarted.
Even after enabling "Autostart" from settings.
I searched in here for a solution but all the answers i found didn't satisfy my need, cause i can't just accept my Service being restarted.
If i want to resume the audio call, i have to re-call the friend again !
So, the question is :
How to prevent Xiaomi, Huawei, Oppo ... devices from restarting Foreground Service ?
Which is the case with WhatsAPP, Messenger, Instagram and others.
It's a tricky question since it really depends on the vendor. There is a site which document and rank the vendor according to "how bad" they're handling services and processes. From the site:
...With Android 6 (Marshmallow), Google has introduced Doze mode to the base Android, in an attempt to unify battery saving across the various Android phones. Unfortunately, vendors (e.g. Xiaomi, Huawei, OnePlus or even Samsung..) did not seem to catch that ball and they all have their own battery savers, usually very poorly written, saving battery only superficially with side effects.
The solutions differs from vendor to vendor and from ROM version to another.
For example for Huawei you can overcome the issue in Huawei P20, Huawei P20 Lite, Huawei Mate 10 by Phone settings > Battery > App launch and then set your app to “Manage manually” and make sure everything is turned on. Also for reliable background processes you may need to uninstall PowerGenie (which is a power mgmt. application by Huawei). On the other hand for EMUI 9+ devices you'll have to uninstall PowerGenie via adb
I am running an accelerometer based android app that will run for a few months while phone is on and does nothing else. Some phone allow display not to go to sleep at all which allows my app run fine infinitely. The screen also has only a black display and nothing else apart from background accelerometer listener and occasional http posts. My question is if I remove the display screen while the app is running, would that stop the operating system and/or my app?
My question is if I remove the display screen while the app is running, would that stop the operating system and/or my app?
In short, it depends on your app architecture (otherwise i.e. music players would require to keep screen on to work). Depending on task you are really doing you may use Alarm Manager to periodically fire your code, or use Service.
My question specifically concerns the Samsung Galaxy Camera devices. It ships with a customized camera application. I guess Samsung developed their own. Since this device can be seen as a camera instead of a phone with a camera they seem to decided that their camera app should start on boot, in contrast to other devices which take the user to the home screen after boot completes.
Now, in our szenario we ship the device with our own application that has its own camera interface. We could run our application in kiosk mode but we want to allow the user to use other apps that might be helpful for his daily work as well.
So ideally, the device should start the home screen after boot completes. The user could then decide to start our app or another app. But if this isn’t possible it would also be ok if our app would start on boot instead of the home screen (since the user would reach the home screen with the home button)
Since I don’t see any chance to force the home screen to appear after boot completes, I tried to start our own application by default. To implement that I created a receiver with the following filter:
<intent-filter android:priority="1000">
<action android:name="android.intent.action.BOOT_COMPLETED"/>
</intent-filter>
When the intent is received, I start the main Activity of our application.
In the result, after booting the device, Samsungs default camera app will start first. You’ll see their main Activity and the most annoying part: the camera lens will be fully extended. A split second after this our app starts automatically.
My guess is, that Samsungs camera app also reacts to the boot-completed-event. Is there any chance that we could prevent their app from being started?
I believe this can be achieved - albeit in a convoluted manor - without rooting using DevicePolicyManager. By making your app a device administrator and disabling the camera the built in camera app won't launch on power up (nor camera button press). Once your app has launched re-enable the camera and have fun.
I haven't had a chance to create the code (and will update this answer when I have), but I have tested to an extent using the DisableCameraDevice app from the play store. With this app setup the camera app doesn't launch at startup and my app which receives BOOT_COMPLETE launches after a few seconds of homescreen time.
It also doesn't stop the camera button events (but does stop the camera app) so you can do the same for this (which also seems to ignore android:priority values).
If you wanted to go further you could even make you're camera app respond to the ACTION_MAIN, CATEGORY_HOME intents mentioned by CommonsWare and persistently select it as the homescreen app.
Combined with a full screen app which doesn't display the home/back buttons you're locked down pretty well for a fool proof camera to give customers.
The camera app uses the BOOT_COMPLETED permission attached to a receiver. It is a system application, so you would need root to modify it on the system level. If you are packing your own firmware, this would not be an issue. The standard launcher does not have the standard boot permissions, but your app would. This would avoid the issue of not booting to anything by simply removing the permission. Also, a priority of 499 is better to fall within the limit of 500.
For this question I'm going to quote another user who got no response to their question:
I've written an Andoid app that uses the hardware Volume buttons for another purpose.
It works fine if the app is running and visible, but when I turn the
screen off or let it time out, the button clicks don't get into my
handlers.
Does anyone know if there is a way to detect these button clicks when
the screen is off?
Source: AV695's question
I'm working on an app myself that makes use of the volume buttons, but as this user also noted, the normal behavior of checking buttons with onKeyPress stops working once the screen is off. This is because the Activity gets paused on screen off.
Is there a way to keep the activity running while the screen is off, or check for the usage of the volume buttons when the screen is off? I tried using a Service for this before but it's impossible to check for the volume keys like that as noted by Commonsware.
I doubt that this is supported (without resorting to a battery-draining wakelock) at either the platform, kernel, or underlying radio firmware levels without modifications to the last to bring volume presses during sleep to the attention of the kernel.
Within the realm of reasonable system-ROM modifications, a more reasonable one might be to modify an existing open source ROM for the device to insert some custom platform level code into the handling of the power button usually used to wake up the device preparatory to unlocking it - that at least we know does get the attention of the kernel. That code could then inform the user by sound or vibration if there are unacknowledged notifications.
You could optionally wait briefly, check device orientation, or look for another key press to avoid doing this in an annoying way when the user is holding the device outside their pocket and trying to unlock it.
Or you could not use the volume key and just set a timer to wake up every 15 minutes and vibrate if there are unacknowledged notifications, avoiding the need to fumble in ones pockets.
You mention it's a custom request: if implies it's one off or low-volume, another option to consider would be that a few vendors have "bluetooth watches" out with an SDK that lets you push notifications from an android device.
If you can capture the notification when it's generated, you could push it to the user's wrist, and then let the phone go back to sleep.
You cannot intercept the key while your application is in background, but instead of listening to the KeyPress itself. You can register a ContentObserver, as described in this question.
As Chris Stratton mentioned, the only way to keep your App alive is by using battery-draining wake locks.
However, since I found myself in the same situation, I came up with another solution. Unfortunately, you'll need a rooted device as well as the Xposed framework.
With Xposed, which replaces the zygot process so you can hook yourself into any constructor and method of the system, you will be able to catch the raw KeyEvents before the system handles them.
This is done in PhoneWindowManager.interceptKeyBeforeQueueing(). By using a XC_MethodHook, you can use beforeHookedMethod() on the afore mentioned method to catch every hardware button event, even if the device is in deep sleep.
After catching events you are interested in, you can create a temporary wake lock to do your things but don't forget to release the wake lock after you finished your work.
A good example of how to accomplish this is the Xposed Torch Module.
If you, however, rely on a non rooted system, the bad news is that it's simply not possible without draining the battery...
I was also trying to implement volume button press detection in my app and I left that part to be developed later once the core part is done. I was able to detect volume key press while screen is on even when phone is locked, from a background service.
Background Video Recorder 2 (BVR2) (and possible BVR1 also, I did not try) is one of the apps that can detect volume key press even when screen is off. While trying to implement volume key detection while screen is off in my app, I installed BVR2, hoping to find how it works. To my surprise it gave my app the ablity to detect volume keys even when screen is off. My app had a ContentObserver to monitor volume changes, but was not working when screen is off. When BVR2 is active my app also could detect volume key press when screen is off. Still digging.
But BVR2 has its own trigger action, that is to record video, an action you may not want to occur just for the sake of you application detecting volume key presses.
Another app is QuickClick. This app can give your app what it lacks, the power to detect volume key presses even when screen is off, without extra unwanted actions. Just install QuickClick and do not configure any action. Create a ContentObserver to monitor for stream volume changes and you are ready. You app will now be able to detect volume key presses even when screen is off.
Please note that my app runs as a background service.
Both of the apps mentioned above are meant for other uses, but uses volume key detection to perform action. I am in no way connected to any of the apps mentioned.
If these apps, and possibly dozens others, can detect volume key press, it can be done. I request experts to find out how to do it, so that we can implement in our app without relying on another app.
If you find this answer useful, please up-vote.
I am not sure if it is as simple as this but check this android blog:
Allowing applications to play nice(r) with each other: Handling remote control buttons
It explains the usage of a broadcast receiver that receives the up/down volume controls and other music controls.
In summary you should use registerMediaButtonEventReceiver