Develop Reference

LOCK_TASK_FEATURE_GLOBAL_ACTIONS alternative for API 26

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.

How to display Unicode Characters in Android TextView?

My app works before with translation from English to Korean.
See screenshot below.
I don't have to configure things like right fonts among other things.
Now it won't work and would only show Latin based characters.
I know for sure that the API I use returns the translation I need since the correct translation shows on my logcat.
But android textView doesn't display it properly since I updated all of my android studio components such as the emulator. It doesn't work properly on API 17, 18 and 19 but works on API 16 which is rather odd since if it could work on API 16, it should work on much newer versions of android too. I've also Cold Boot all my emulators to reset it, but still no changes. It also works on API 21 as show below. But definitely not on API 17-19 as I've tested. :(. Please. help. Thanks.
[Edit]: I Changed the title from "How to display Korean-Chinese-Japanese Characters in TextView?" to what it is now since supporting most languages is under encoding foreign language in Unicode it seems.

After debugging for a couple hours more searching. It seems that the current updated Android emulators for API 17-19 are buggy. Since I noticed that it doesn't display Korean Characters not only my my app, but also everywhere else like my web browser.
The reason why my app displays unicode characters in an older android versions like Android 4.1. However, it turns out it could display Japanese Characters when I tried to translate to another language that is another Unicode character. It could also properly display japanese and chinese unicode characters in my browser.
I already created a fresh Android emulator for API 17-19, but it really didn't solved the problem. Installing a new keyboard didn't do the trick either. I could't not add another language too like japanese since its not in the options. But japanese works on the emulator, so I didn't bother trying to find one for Korean.
In the end, it turns out its really an emulator (Operating System related) problem and not an android app compatibility or problem on my code. Android 4.2-4.3 (API 17-18) is both Jelly Bean anyway. Since, it works on Android 4.1 that is Jelly Bean too, problems must be in the android image updates I had update a few days ago. for Android 4.4, must be the same case then.

Targeting the most appropriate API

Currently, I tend to target all my app development to API 8, so that I can hit the largest number of devices 'out there', basically from Android 2.2 upwards.
Do any experienced Android developers reading this have a perspective on what features, as a developer am I 'missing out' on, and more importantly, what are my users missing out on? In this day and age, what API is the 'best' one for my apps to target? Or is there no such thing, and each app should be targeted for a given API on its merits?
I'm not looking for pointers such as read the android developer docs (I have, or at least what I consider the salient parts), I'm more interested in the views of experienced developers as to how they decide which API to target.
Thanks.

if you set your target and minSdkVersion to 7 and use support (compatibility) library v4, then your app will support nearly 95% of all android phones, and still you are able to use modern features of newer APIs (by using support library).

I usually target the minimum API required by the apps functionality. If there is a minor feature needing a higher API, I make it optional instead of increasing the minimum for the whole app. In addition to using ActionBarSherlock and the compatibility libraries, I occasionally back port a few things from later APIs to keep the current basis.
While I decide the minimum on a per app basis, most of my apps target 2.1, as they were written almost one and a half years ago. Now days, I have new apps target 2.2, though I plan to change it to 2.3 very soon.
I guess my point is that there is no defined minimum API target. You should choose the one which offers maximum user reach, along with as much major functionality as possible. UI elements like the action bar and ViewPager can be used via libraries, and the ones not available in libraries can sometimes be back ported. However, it is usually not worth it to sacrifice users running a lower API version just for a better UI.

In Android, is there a way to set "android:configChanges" for an activity at runtime instead of in the manifest?

My app is set to run on minSdk = 5, but the vast majority of users are using SDK 8 (FroYo) and higher. I want to be able to use the android:configChanges="uiMode" for my main activity, but I can't do it because that mode wasn't introduced until SDK level 8. So, I was hoping that I could do it at runtime -- check which SDK level is running on the device, and then use reflection to add that parameter.
Is that possible?
EDIT:
The problem is that whenever a user's phone is connected to the dock, my app gets terminated, and then re-created. I'm trying to avoid that by including the android:configChanges="uiMode".

After much poring through the Android Reference, there is very little you can change from the manifest at runtime. This is due to security because through the PackageManager, one can gain very specific information about any application on the device. While it is easy to enable/disable a given Component, in most other circumstances, you can only read manifest information... not write it.
Alternatives
You could potentially make a separate APK with API Level 8 support.
You could manually check for configuration state and run your code when it changes. The object reference for configuration is here.
Edit: (new info)
While you cannot change the configChanges, I found this question that is closely related to yours. It turns out that you might not have to. It implies that you can use Android's backward compatibility mode when supporting new configChanges. In case the link above is broken, here is the URL: https://stackoverflow.com/a/7893148/501932
To put this to use for you, it suggests setting a new targetSdk while maintaining your original minimumSdk. It also requires that you have the updated SDK, itself. Apparently, this was a huge deal for users that utilized that AdMob API.

App Configuration for forward compatibility
The answer I provided is a simple what to do, but not much or the why, this should update the answer as well as act as apology to the SO community for sparring with the poster, which was pointless and added nothing to the conversation.
I think it’s an important point to expand upon this issue since these kind of questions come up a lot and developers in a hurry (aren’t we all) and we have a tendency to cut/copy/paste and worry about the why of it later which mostly works out but occasionally just adds to the problems.
If you understand how the android runtime actually works you can often solve these types of problems by applying a simple pattern of best practices by using the block in your manifest, and making good use of the Build Target when compiling your app, followed by some simple testing at the compile and run time levels.
Manifest
minSdkVersion =
Pretty straight forward it’s the lowest build target you will support on a specific device. If you don’t set this it defaults to 1.
The only caveat here is that if your Build Target is higher than your minSdkVersion than you can potentially call API’s that don’t exist on the device, more on that under Build Target.
This will filter you app from on the various market/play repositories for devices that have lower OS support.
How you make this determination is up to you, if you must have your app run on every device ok, but take a look at Platform Distribution to make an informed decision.
If you are willing to bypass 0.9% of the market then target 2.1 which seems reasonable but that’s a decision for a developer/company to make, if you can bypass 25% of the market then go with 2.3 which has significant advantages but is a bit hard to swallow for most general purpose app’s.
The linked chart is updated from time to time.
targetSdk =
If you don’t apply this value then it defaults to whatever minSdkVersion you set. This means that when you run on a device with higher OS support certain new looks and or behaviors that are implemented will be bypassed in favor of the older way of doing things.
For instance if you apply 10 to the minSdkVersion and then your app runs on a device with gingerbread (11) it will not attempt to use the holo theme, or disable screen compatibility mode. In general this might give your app a “Dated” look and feel.
If on the other hand you set this to something higher, like 11, then the system will use the native look and feel of the OS up to that value you set. Best practices is to set this as high as possible and then to test on the higher level device in the emulator to make sure this is acceptable.
Some of the changes that effect compatibility behavior between OS jumps are documented here Differences between OS's
This will not stop you from running on earlier devices, or effect those earlier devices look or feel (see ActionBarSherlock and the Android Support Library if that’s your goal)
maxSdkVersion =
In general this does just what it says it does, it restricts availability and deployment of your application on devices that have a higher OS level from Google market/play.
On android 2.0- it will also refuse to install the apk, and will even remove your app if a device is updated to a level higher than this setting, 2.0.1+ removed the second part of this behavior but the markets will still filter based on it.
In general there is no reason to usually set this value, so leave it blank.
Build Target
When you set a build target in eclipse (or otherwise) you are telling the complier which API’s, constants, etc. should be VISIBLE to your application.
In general it adds a jar file that has all of these definitions/declarations but of course not the actual classes/methods so that you can compile your application for any target OS you desire.
When your app runs on a device it links to the actual android OS/support jar file(s) (or blows chunks if they are not there)
If you select a build target higher than you are willing to support then bad things can of course happen when you try and call method that does not exist, or even a class that does not exist on the Older OS.
If on the other hand you are willing to carefully manage and test this then you can obtain forward compatibility in the sense that you can use the new API’s on newer devices so long as you don’t attempt to do so on earlier devices.
Best Practices – Short Version
This is what the poster is trying to accomplish and if best practices are followed it works out well, these are in general
minSdkVersion = lowest general API you will support
targetSdkVersion = highest behavioral model you are willing to allow
maxSdkVersion = leave it blank
Build Target = generally as high as is currently supported
The real caveat is that you have to avoid API mismatches between older and newer versions, and make sure your app looks and acts ok on the higher version.
In general methods/classes that are higher than your minimum targeted OS should be used sparingly and tested at both the compile and runtime level since it requires some effort to use them safely.
Here is how I go about it
minSdkVersion = 7 ( I can live with a 0.9% clip again your choice )
targetSdkVersion =15 ( highest as of this writing )
maxSdkVersion = ( blank )
Build Target = 15
When developing I never use an API not available on 7 unless I have a real need to do that, in the posters question he could have used a broadcast received to get similar functionality back to 6/7 (2.0/2.1) but he states he needs API 3 support so he has to support forward compatibility.
One tool you can use, and most don’t just to keep things straight is to set the API level on the developer.android.com website to your minimum SDK level, this gives you a heads up when developing that you will have to support forward compatibility.
It will still show the other API calls but it will gray them out telling you that extra effort will be needed to support them
If you do need to use a newer API you will need to do an if then else so that they are only called on the newer device, this will allow you to support the new functionality without getting a force close on older devices.
So in general if you support higher API levels those calls should be wrapped with something like this (note the .SDK_INT is a since API 4 test)
If ( Build.VERSION.SDK_INT >= API11_SUPPORT ) {
switch(newConfig.uiMode) {
case ...
}
Testing – manual method (CI integration methods are left up to the reader ;-)
Compile with the build target set to the minSdkVersion – this will give you compile errors on any newer API’s that you are using, check them out and if you handled them great, if not now is the time.
For every issue I see at step 1 I add two items to the code (manifests/xml )
// TODO Compatibility xxx
if (DEBUG) Log.i(“MyApp”,” Compatibility xxx”);
I can then use the eclipse TODO pane to check off compatibility issues before ship and test them against the lowest/highest and any significant in between OS versions
Test on minSDKVersion device/emulator, this is a bit tricky if you are not doing comprehensive testing, in general use step 1 above to make sure I exercise those blocks of code
Test on Build Target device/emulator to make sure look and feel work as expected
If you think it’s a bit of work it is, but when you need it you should do it right and make sure your app does not break.
Hopefully this is useful to someone trying to figure out similar situations, below was my second response to the poster, Cheers.
UPDATE:
I still have no idea what the author is asking, but if he is asking if there is a way to detect the configuration changes in regard to uiMode (docking stuff) on 7 and below using the onConfigurationChanged handler then no since that was only introduced in API 8.
There is a broadcast event sent in API 2.0+ systems, but apparently that has some issues and does not seem to be completely reliable
If he is asking if there is a way to support it on devices that are API 8 and above via the onConfigurationChanged handler by setting the flag in manifest for the activity then of course there is
Of course he may be asking about something totally different, it's hard to tell exactly what he is looking to do given his post none the less in the spirit of cooperation:
Select an API from project properties that is >= 8, best practices is to use the highest API available when you create your app for just this reason BUT care must be taken not to call any API's that are not available on the device.
Then in the manifest use (duh)
<activity
android:name=".myActivity"
android:configChanges="uiMode|orientation|keyboardHidden"
This compiles fine (and that is really the only issue and why you need to set a higher api in the eclipse project properties) this will run fine on 7 and below it just wont trigger any events because of course API 7 and below devices won't recognize the uiMode flag (duh)
API 8 and above of course will recognize it and send the proper event so on api 7 the log will be written, on api 8+ it will (if docked etc) of course the calls that are made if it does happen will most likely be 8+ related so you would need a OS check block before calling them.
#Override
public void onConfigurationChanged(Configuration newConfig) {
super.onConfigurationChanged(newConfig);
Log.i("myActivity","uiMode="+newConfig.uiMode);
}
If you compile and run on a 7 API emulator and fire a dock broadcast nothing happens, change to a 8 API emulator and it does
adb shell am broadcast -a android.intent.action.DOCK_EVENT --ei android.intent.extra.DOCK_STATE 2

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.