I am developing an Android application for the deaf using the accessibility service
The problem is that deaf people do not need a power button because they will use another device
I tried to call this code
val commandLine = "input keyevent KEYCODE_POWER"
Runtime.getRuntime().exec(commandLine)
And it didn't work.
Moreover, the device didn't hook the power button press
I may use the GLOBAL_ACTION_LOCK_SCREEN, but only supported from API 28, but a minimum of 21 is needed
Getting the root and changing the system settings is not a good choice, because not for developers, the root can break the security
Tested on these devices:
Samsung S8+ API 29
PIXEL 2 API 28
PIXEL 2 API 27
This ... doesn't works according to user privacy :)
Related
I'm looking for some way to block users from turning kiosk device off with only touch screen. Unfortunately, all devices I'm programming for run on api <= 26, so I can't simply use setLockTaskFeatures, with LOCK_TASK_FEATURE_GLOBAL_ACTIONS. How else can I stop users from powering the kiosk device off using the power button in the navigation bar?
Actually there is no way to do that, the setLockTaskFeatures() is added in API 28.
If it was there in the previous APIs it would be implemented by setGlobalSetting(), which it's almost deprecated now and neither does have any parameter corresponding to power-button.
I am writing an SDK that will be used by Android devices with API level 15 and up. I'm currently targeting sdk version 22. What I'm trying to accomplish is to determine whether or not the screen is on or off. Sometimes I will be doing this while the app is in the foreground or background and sometimes I will be doing this when the app is closed, by using an Alarm. What I want to be able to do is ask the framework if the screen is on or off, but it doesn't look like that's possible for android versions <= 19.
It looks like sdk version 19 allows a device to use PowerManager.isScreenOn() to determine the state of the screen, but when version 20 came out that method was deprecated and now you can call PowerManager.isInteractive() but that only works on devices running API 20 and up. If you try to call isScreenOn() using a device running API 19 or less the call really just wraps isInteractive() and you end up getting a method not found in your logs and don't actually get the data you desire.
So it seems like if I always want to know the current state of the screen for devices <= 19 that one work around is to start a background service that is basically always runs and that registers a broadcast receiver that looks for the ACTION_SCREEN_ON and ACTION_SCREEN_OFF Intents. That obviously isn't desirable because then I have to have an always on service which is not recommended.
I suppose another workaround is to compile agains sdk 19 when I build, which would make the isScreenOn() call available (and make the isInteractive() call unavailable). That might be a possibility but seems like a poor workaround because I'd essentially be stuck at this sdk level until either the framework backports this functionality or sdks 15 - 19 are used by few enough users that it no longer makes sense to support them.
Am I correct in my assessment of the situation?
Can anyone comment on the two work arounds proposed or suggest alternatives?
Android 5.0 (API level 21) introduces two new keycode symbols to KeyEvent, namely KEYCODE_11 and KEYCODE_12, which ostensibly map to the "11" and "12" keys on the keyboard. I have never seen a keyboard with an 11 or 12 key.
I had thought it might have something to do with watch faces, but then I noticed that there is no KEYCODE_10, making this all the more puzzling.
If I remember correctly, they are used for the HDMI-CEC standard. Since some Android devices have an HDMI out, they can control TV's etc. with this standard. Also check out this commit for Android made last year.
I'm developing an application with a minSdkVersion of 9, a targetSdkVersion of 17. I am performing some Bitmap pixel manipulation, so at one point I call the function Bitmpap.setHasAlpha() to enable the alpha channel for the Bitmap so I can set certain (and only certain!) pixels to be transparent.
The problem is that Bitmap.setHasAlpha() was only added in API 12--and this is where the mystery comes in. Lint is not complaining about my usage of this call (well... as a general rule. Every once in a while Eclipse will complain about it, and then when I restart it everything goes back to normal), when I run my app on a couple of different Gingerbread (2.3.3 and 2.3.5) devices everything runs properly.
So... as strange as this question sounds, why isn't my app crashing?
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/2.3.5_r1/android/graphics/Bitmap.java?av=f As you see mate the function existed before but not documented
minSdkVersion is a check designed to prevent download and installation of the app on older devices that do NOT have even framework corresponding to the minSdk.
targetSdkVersion is used to determine if any compatibility "workarounds" need to be enabled to ensure the behavior is as close to what is seen in targetSdk
By setting minSdkVersion=9 you signal that the gingerbread devices be allowed to download and install your app. By setting
targetSdkVersion=17 you signal that any workarounds be invoked to allow the device to retain as much functionality as possible from the later sdk.
Also as mentioned in Pulkits' answer the setHasAlpha() API seems to be present even in the 2.3.4 Android framework, albeit not officially documented at that time.
I'm trying to figure out if an Android phone has hardware menu button, I've searched and found this method:
ViewConfiguration.get(getApplicationContext()).hasPermanentMenuKey();
But this doesn't seem to work in Android 2.1, and I'm trying to create an app that works on Android 2.1 and higher. Is it possible to detect if there is an hardware button on a phone with Android version less than 3.0?
Every compatible 2.1 android device had a menu key as it was part of the CDD:
http://source.android.com/compatibility/2.1/android-2.1-cdd.pdf
See section 8.7:
"The Home, Menu and Back functions are essential to the Android navigation paradigm. Device implementations MUST make these functions available to the user at all times, regardless of application state."
Therefore, if the device is running android 2.1 it's safe to assume it has a menu key. If it's running a later version you can use the API you found.
hasPermanentMenuKey() was introduced since API Level 14 because from Android 3.0 the devices were allowed not to have a menu key. so I assume that you can safely assume that a 2.1 device will have a menu key. Check the android documentatin on this for more. Android view Configuration hasPermanantMenuKey
hasPermanentMenuKey() became available at API level 14 (3.0). I would believe it is safe to assume there is a key on devices running below 3.0. Above 3.0 you can call this method to determine if you need to provide an alternative method.