I have an application that runs as a kiosk using Android Management API - some of my customers prefer to use MDM platforms such as Intune and Airwatch.
We use the Samsung XCover Series for our dedicated devices.
It appears that with Android 11 there has arisen a new issue.
When the phone is running, be it as a single use Kiosk app locked to my application, or a multi-app setting using a third party MDM Platform, the screen will time out after a period of time. Once the screen times out, the Android 11 device enters the "Swipe to lock", but shows the app or MDM kiosk on top of this (hence the user has no knowledge this is happening). This is causing NFC to stop functioning as the device is essentially locked.
This can be reproduced and verified as follows:
Take two phones, one Android 11 and one 9.
Provisioning them to run as kiosk using any application
Wait for the screen to timeout on both phones.
Finally update the policy to run as "force_installed".
The Android 11 phone will return to "Swipe to unlock", the 9 phone will not.
The same issue occurs on Android 10 but was easily fixed by turning the Lock Screen to Off in the device settings. Unfortunately, on Android 11 it appears that disabling this feature has no affect on the lock status of the device while running as a kiosk.
I have come up with a temporary solution for devices that are locked to our application, by keeping the screen alive when the app is running in the foreground. This however does not suit our customers who also use other apps within their environment.
Maybe disabling the Keyguard via the DevicePolicyManager works?
DevicePolicyManager dpm = (DevicePolicyManager) getSystemService(Context.DEVICE_POLICY_SERVIEC);
dpm.setKeyguardDisabled(yourAdminComponentName, true);
A public ticket is open for a similar report to your reported issue. We've passed your use case on in the internal engineering ticket as part of the ongoing review on Google's side. To keep up to date on a possible resolution, I suggest following the public ticket for updates.
Related
Right now I'm developing client application for Android that works with physical locks with our controllers. User can open lock via Bluetooth using this application (connection -> secure session creation -> sending some user key).
All works fine except one feature: opening lock when Android device screen is off.
I am using following approach:
Foreground service that periodically scans for nearby BLE devices and when scan is successful (nearby lock device found using BLE filters), application tries to connect and send lock key to lock device.
So, there are two problems:
Android kills foreground service in few minutes after screen off. After setting ignore battery optimization it works ok, however I can't find universal way to navigate user to those settings (because those settings are vendor specific, see https://dontkillmyapp.com/ and android open battery settings programically).
Background limits for BLE scanning are tricky.
I know one application that achieved same thing without foreground service: https://play.google.com/store/apps/details?id=eu.hoermann.ast.bluesecur, this application seems to work good in background without user interaction with battery usage optimization menu.
So, question is:
what is the best way to trigger background process (device screen is turned off) when nearby suitable BLE device available?
Your requirements perfectly describe the scenario of a companion app. Disadvantage: it is only available from Android 12 (API level 31) onwards.
I think you shoul add a wake lock with the service:
https://developer.android.com/training/scheduling/wakelock
https://developer.android.com/training/scheduling/wakelock#cpu
I have a security system where moving a Bluetooth LE device causes my android application to do some work. After some of the newer Android updates, I believe API 26, I could no longer get these updates if the Android device's screen was off. I was trying to think of a way around this and came up with an idea:
What if I paired the Android device and the Bluetooth device - would this allow for the message to be received when the Android screen is off?
Previously, all my BLE devices were part of a mesh, so I would regularly have the Android app check for changes in the mesh and turn the screen on to notify the user if needed. Now, because of the background execution limits introduced, I must require the Android device to have the screen on at all times, which leads to the death of display over time.
I'm not that great at programming in C, which is the language the BLE chips are programmed in, so I wanted to ask this first before spending hours just to see this NOT work. So, just to repeat the question: Will having a BLE device paired with the Android device allow a message through these restrictions when the Android screen is off?
If not - is there a way I can make this work?
Thank you for any info!
Use notifications instead of advertisements. This will deliver data instantly and works even if the screen is off. Newer versions of Android have introduced more restrictions for BLE scanning when the screen is off.
Use connectGatt with autoConnect set to true to automatically connect and reconnect in case the connection drops.
Use a Foreground Service in your app process to prevent the app process from being killed. If your app process exits, all Bluetooth connections are dropped as well.
You could use CompanionDeviceManager to gain some extra permissions.
You don't really need to be paired but it has some benefits such as faster connection setup and correctly remembering the address type (flaw in the API that this is missing).
I have a Philips Android TV and I'm looking to power on / power off (standby) the TV screen from the code of an Android application.
Is it possible?
Which API allow to activate the screen?
Which API to set the TV back in standby?
I've searched Android API documentation and on internet but I've not found an API for that.
According to Declaring permissions that imply hardware features there is no permission that would enable such a function, and I think it makese sense since a user application should not be able to control an external device screen, that runs in an protected context, different from connected devices such as gamepad, camera, etc.
That said, this does not mean that it's not possibile in any case
What an app can do is to keep the screen device on i.e. not lock the screen while the app is being used that is Keeping the Device Awake.
This is all related to the device policies handled by the DevicePolicyManager i.e. the interface for managing policies enforced on a device.
It's working well on most Android devices.
Other device's screen gets locked after 1 minutes BLE device gets disconnected,if device without charger.
Thanks for any suggestions!
this might come from the Keep Wi-Fi on during sleep option (which might affect all radios) - as it seems this only exists in 8.0 but not in 8.1 (at least on the Pixel 2 XL, according to this article).
You might be having this problem because your app is not properly configured to handle Doze mode.
While there do not seem to be any restrictions on using BLE itself, doze mode might be messing with the control mechanism for your bluetooth connection (ex: a background service).
To see if this is the issue, you can whitelist your app manually via Settings > Battery > Battery Optimization and disabling optimization for your app.
Furthermore, as of Android 8.0, there are restrictions on background services when your app is not in the foreground. So, you may need to create a foreground service to handle the connection.
Together with a sub-company we try to develop an android app which simulates an automotive HMI system. There is a functionality to changes the color-theme in case of connected mobile-phone (via Bluetooth). In general this is working: If a known paired phone is in range the theme switches... if the phone loses connection the theme switches back...
Problem: Currently the app polls the paired bluetooth devices for every second and checks if a known phone is paired.
After ~1h and 20min (+/- 5min) the app freezes (reproducible).
Our sub-company told us, that the reason is a problem in android bluetooth device - A timer overflows and android refuses the requests of the app after this time. Thats the reason, that the app freezes.
I´m not familiar with android development and I have to believe in this statements.
Could you tell me if there are other possibilities?
Is it necessary to poll the bluetooth device? Is there nothing like an system event which could be used?
Is this problem (refused bluetooth pooling after defined time) known?
Hint: The problem occurs only with power supply. In battery usage the app runs till battery is empty (longer than 80min).
Samsung Galaxy Tab Pro with android 4.4 (same problem with android 4.3)
It would be nice if anybody is able to help.
Many thanks