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.
Related
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.
I'm currently write Android HCE application. And I want to use my HCE application when the device is turned off. I found a way to "Access HCE when Screen off", but no information of power off status.
Is there any way to use HCE application when phone is turned off?
No you can't access because of security reason
One correction also its not accessible if screen is off as mentioned in provided link.
Current Android implementations turn the NFC controller and the application processor off completely when the screen of the device is turned off. HCE services will therefore not work when the screen is off.
It may work on some devices only if vendor implements the OS customized.
I am little confused about System.Global. According to this document (third point under Important Behavioral Changes) it says that few of the features like turning airplane mode on/off have been include in System.Global in Android 4.2 and higher so its now read only we cannot write it.
Along with airplane mode there is also Bluetooth turn on/off feature included in System.Global which means we shouldn't be able to toggle Bluetooth on/off programmatically since its read only.
But I have some app in my Nexus 7 which runs on version 4.4.2 where the app can easily turn on/off Bluetooth on voice command (one such app is 'Assistant')
How is it possible if the features in System.Global are read only?
Any explanation on this topic will be very much appreciated. Thanks in advance :)
System settings are generally read-only for normal apps. The "Assistant" or "Settings" applications are bundled with the platform and have special permissions. Bluetooth does expose the ability to turn a given "adapter" off and on via the BluetoothAdapter class.
Starting with Android 5.0, it's possible to access some of the settings.
You can use the method setGlobalSetting() in the DevicePolicyManager for that.
However, the caller app must be device owner which is not available to apps deployed on Google Play.
To deploy and activate a device owner, you must perform an NFC data
transfer from a programming app to the device while the device is in
its unprovisioned state. This data transfer sends the same information
as in the provisioning intent described in Managed provisioning.
Source: Android 5.0 APIs
I have an app running on Android that uses only a webview to display a mobile web-application and at some point uses the device's GPS to obtain their position.
I have a custom ChromeWebClient etc and it obtains their position nicely except for on devices where the Power Saving Mode is enabled?
Is there anyway in the SDK/API for me to be able to determine if the user has this enabled and to advise them accordingly?
I can't find anything in the docs so i am assuming not but worth a shot,
Cheers,
Lee
After reeding the comments
In my experience Samsung, as well as HTC, is one of the manufacturers that modify Android OS in most unpredictable ways. They add new functions and modes, like 4G switching launcher widgets and "power saving mode". They modify permission requirements for documented SDK methods, i.e. to switch on bluetooth on a Samsung device your app needs to have and additional android.permission.BLUETOOTH permission, while stock Android only needs android.permission.BLUETOOTH_ADMIN. And there's more.
Long story short, as #RaghavSood pointed out, "power saving mode" is not an official AOSP feature and there are no ways to detect it via official SDK. There is a possible way how you can work around it though. I believe it is most likely that your app misbehaves in power saving mode because this mode turns off GPS. You can confirm that by configuring power saving mode in settings to disable GPS disabling(can't phrase this better, sorry) - first link from google with steps. Then test the app. Does it work? If yes, then you've rootcaused the problem and now your job is to let the user know that your app won't run without GPS. You can put some code into your app to detect if GPS service is enabled an show an alert dialog if it isn't. The code in your activity can look something like this:
LocationManager lm = getSystemService(Context.LOCATION_SERVICE);
if(!lm.isProviderEnabled(LocationManager.GPS_PROVIDER)) {
//Show a notification prompting user to switch on GPS.
}
You can be even more elaborate and make your app detect device manufacturer to show a custom message on all Samsung devices.
Is it possible make an activity, that will lock the android device?
That device would be unlocked only after entering right PIN number.
During lock, user can't call,message, and can't view notifications,contacts,call logs,storage data,...
For this you can take advantage of the Device Administration API introduced in Android 2.2. This does require the user to accept that your application wants to have control of the device but obviously you would need to disclose that information anyway. Also it should be noted that on a phone (at least in the US) you must always have access to make emergency phone calls.
Using the API you can enforce a pin lock be set and also invoke the lock screen at will in addition to many other administration features.