Develop Reference

Disable power button in android didn't work

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 :)

Determine if screen is on or off on Android versions 15 - present

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?

Unexpected backwards compatibility or Why Isn't My App Crashing?

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.

Alternatives for setFinishOnTouchOutside for older android device?

I have an activity that using the dialog.theme in the manifest, but I don't want it to be destroyed when the user touches outside of the dialog. I did some search and found setFinishOnTouchOutside(false) to be useful, but it require API11 android 3.0 device. I want my app to be compatible on older android device as well, what is the solution??

You are lucky man, because on older android devices activity will not be closed on touch outside.
If you want to call setFinishOnTouchOutside(false) for newer devices, check API level before and call the method if API >= 11.

How to check if a phone has hardware menu button in Android 2.1?

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.