Develop Reference

AndroidStudio 4 says enterPictureInPicture is depracated as of API 26 - this is incorrect, right?

AndroidStudio screenshot showing the warning:
Yet what I find here is:
Android 8.0 (API level 26) allows activities to launch in picture-in-picture (PIP) mode.
PIP is a special type of multi-window mode mostly used for video playback. It lets the
user watch a video in a small window pinned to a corner of the screen while navigating
between apps or browsing content on the main screen.
Nowhere can I find where this is now depracated. Am I missing something or is AS in error? I want to be sure I'm not coding down a dead path.

enterPictureInPictureMode() was introduced in API 24 and deprecated in API 26. It has been superseded by enterPictureInPictureMode(PictureInPictureParams), introduced in API 26.
Documentation here: https://developer.android.com/reference/android/app/Activity#enterPictureInPictureMode(android.app.PictureInPictureParams)

Accessing the new Notification Settings in Android 4.3 through Code

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

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.

Menu button and related API deprecated as of API 11 and higher - how to handle that?

I quote from the SDK docs:
"Beginning with Android 3.0 (API level 11), Android-powered devices are no longer required to provide a dedicated Menu button. With this change, Android apps should migrate away from a dependence on the traditional 6-item menu panel and instead provide an action bar to present common user actions."
Further more:
"If you're developing for Android 2.3 or lower, users can reveal the options menu panel by pressing the Menu button.
On Android 3.0 and higher, items from the options menu are presented by the action bar as a combination of on-screen action items and overflow options. Beginning with Android 3.0, the Menu button is deprecated (some devices don't have one), so you should migrate toward using the action bar to provide access to actions and other options."
So, if I understand correctly, on devices with Android 3.0 or higher, which do have a Menu button, the depraceted code will still work, while on device with Android 3.0 or higher and no Menu button, the depraceted code will not work.
5 questions arise:
Can these compatibility issues be handled through the Android compatibility library?
If yes, how?
If no, does anyone have a list of devices with Android 3 and higher and no Menu button?
How high is the market share of these devices currently?
Specifying a max SDK, will exclude all devices, no matter if they have a Menu butto or not. Is there are better way, to ensure an app is only installed on compatible devices?

Can these compatibility issues be handled through the Android
compatibility library? If yes, how?
Set your target API to 11 or higher (It's recommended you set it to the latest available version: So, set your target API to 15). Then enable an ActionBar in your application. What used to show up via a menu key now shows up in the overflow menu of the ActionBar, or shows up as individual actions on the bar itself if you set each one's "showIfRoom" true.
If no, does anyone have a list of devices with Android 3 and higher
and no Menu button?
Trying to code special cases is the wrong approach. On devices with a menu button, it'll work with the menu button. On those without a menu button, there will be the overflow menu. There's a blog post about this on the Android Developer Blog.
How high is the market share of these devices currently?
Small but growing.
Specifying a max SDK, will exclude all devices, no matter if they have a Menu butto or not. Is there are better way, to ensure an app is only installed on compatible devices?
Yes: The method I described will handle both scenarios, and it'll work across all devices :) No reason to use maxSdk.
EDIT: To address questions from the comments:
So, if my target is 8, the devices with 11 will not handle the Menu button properly?
If you set your target to less than 11, devices without a menu key will have a "legacy" menu button next to the other soft buttons, like here: http://android-developers.blogspot.com/2012/01/say-goodbye-to-menu-button.html
On the other hand, if I set target to 11, eclipse will not warn me, if I use features > 8?
If you set your target to 11 and min to 8, Eclipse won't warn you if you use 9+ features- You'll need to test your app for that. Easy way to do that: Move your target SDK temporarily back to 8, see where the compiler yells at you, make sure those code paths never get hit on devices that can't handle them.
What consequences does it have for distribution on Google Play Market?
Only good ones. If you set a Max SDK, your application would be compatible with fewer and fewer devices as time went on. Having a min version of 8 (instead of scrapping backward compatibility alltogether) means your application is installable on Froyo and Gingerbread devices, instead of only Honeycomb and up.

Can these compatibility issues be handled through the Android compatibility library?
No.
If no, does anyone have a list of devices with Android 3 and higher and no Menu button?
Pretty much all of them. Devices that were running Android 2.x and are being upgraded to Android 4.x will have a dedicated MENU button (e.g., Nexus S). Devices being build new for Android 3.0+ will rarely have a dedicated MENU button.
How high is the market share of these devices currently?
Android 3.0+ represents 8.2% of the devices accessing the Google Play Store as of early May. Most of them will be devices that lack a MENU button.
Is there are better way, to ensure an app is only installed on compatible devices?
The only reason for a compatibility issue is if you relied upon a MENU button for doing things other than displaying the options menu. Simply rewrite that code to no longer rely on a MENU button, and the compatibility issue goes away.

Your deprecated code will work on devices with no menu button. If your target SDK is less than 3.0, devices with no menu button will show a software menu button at the bottom of the screen.
This looks fine on the Galaxy Nexus and other devices with persistent software buttons, but is ugly on devices like the HTC One X, which does not usually have a software button bar.

They have a sample of using actionbar on older devices here. There is also the option of configuring different layouts and activities/methods based on android version, so you can use normal menu on older devices and actionbar in devices that support it. (see here for how to check platform at runtime, and here for using different layout folders based on platform)

Android dalvik problem

Please i have different platforms installed. I just wanted to know what am supposed to do. If i develop with 3.0 platform, would those with a 2.2 be able to use my app??..
The second question which is the main question is I always get this error when i create android projects..
[2011-05-16 16:32:21 - Hello World] Dx no classfiles specified
[2011-05-16 16:32:21 - Hello World] Conversion to Dalvik format failed with error 1
What do I do to it?

There are several reports out there for that error (e.g., this one. All the solutions point simply to reload the project (select it in the tree at your left, and press F5).
Regarding the first question, unless you want to support Honeycomb-only features, then set up the api level to 8 (Froyo).
Eclair, Froyo and Gingerbread are android versions 2.1, 2.2 and 2.3 respectively (also referred in the documentation as API levels 7, 8 and 9). See the table here. If you want to support just mobile phones, set your target to 2.1 or even lower. That way you will be able to target most of the phones in the market. Your app will also run in Honeycomb (3.x) devices.
Honeycomb has new features to support larger screen devices, so if that is your main target, you might consider taking advantage of those features and drop cell phone support. All will depend on what is your objective.

you should have a look at the minSdk and targetSdk features of a manifest file :
<uses-sdk android:minSdkVersion="4" android:targetSdkVersion="8" />
This will help you target a android sdk version and precise what is the minimum sdk level that can run your app.
Regards,
Steff

Developing for Honeycomb or non-tablet version of Android, is different in various things. Your 2.2 application should run correctly on a tablet, but if you want to optimize the graphical interface and use all the notification and other things included only in Honeycomb, then you must use the appropriate API. Until Ice Cream Sandwich is released, we have to develope two different application for the best result.
Regarding the error you get with android projects (I suppose under eclipse?) you'll find some detail at this link, but if you follow all the instruction provided by google in the developers page, you'll be able to write and run your Hello World application.