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.
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?
How can I access this through code? So I can open it for the users automatically and they don't have to hunt through the Security settings to enable it.
I am unable to find it in Android Studio using startActivity(new Intent(Settings.<>));, where <> is the list of setting screens.
Image courtesy of Android Police
There is an outstanding bug in Android 4.3 where the notification listener screen action is not listed in Settings. The current workaround is:
startActivity(new Intent("android.settings.ACTION_NOTIFICATION_LISTENER_SETTINGS"));
The bug that #CommonsWare mentioned has been fixed as of Android 5.1 (API 22). You can now use this to bring the user to the Notification access screen:
startActivity(new Intent(Settings.ACTION_NOTIFICATION_LISTENER_SETTINGS));
I've tested this across multiple Genymotion instances (4.3, 4.4, and 5.1) as well as a Galaxy S3 running 4.3, and this solution has worked perfectly in each case.
Strangely however Android Studio does give me a warning when I use this field on pre-API 22 projects, despite the fact that it works without problems:
Field requires API 22 (current min is 18): android.provider.Settings#ACTION_NOTIFICATION_LISTENER_SETTINGS
I believe that this warning should be able to be safely ignored, similarly to how you can use values from Build.VERSION_CODES on any version of the platform.
Link to the documentation: Settings.ACTION_NOTIFICATION_LISTENER_SETTINGS
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.
Made an app targeting API8 and it's running fine
on all emulator images all the way up to API15.
I cannot test the app on other higher apis so I'm not
setting the android:targetSdkVersion.
What about this deprecated warnings:
android.view.Display.getHeight()
This method is deprecated.
Use getSize(Point) instead.
Can I ignore this and just keep on using Display.getHeight()?
I read about reflection or programmatically testing what Android version the device is using.
Why do people do that when it's working for me?
I cannot test the app on other higher apis so im not
setting the android:targetSdkVersion.
If you are testing "on all emulator images all the way up to API15", then you are "test[ing] the app on other higher apis".
Can i ignore this and just keep on using Display.getHeight()?
In Android, "deprecated" usually means "we have a better solution that you should consider using, but we will keep the deprecated one working as long as we can". Sometime after you drop support for API Level 12 and down, you might wish to move to getSize(). For now, getHeight() should work fine on all Android API levels.
Why do people do that when it's working for me?
They do not do that for deprecated APIs. They use version checks and the like for accessing things that simply do not exist in older versions of Android, so they do not try referring to non-existent APIs on older devices.