Develop Reference

Android BluetoothChat example: bluetooth connection lost upon screen rotation

I have just imported Android's BluetoothChat example into Eclipse. In the Android manifest, I can see that the option android:configChanges="orientation" was already there. However, when I tested the app on two real phones, the connection was always lost whenever I rotated the screen.
In another thread, a user reported that the connection was not lost when the android:configChanges="orientation" option was there, but this is not what I have experienced.
The only modification I have made to the code is to add the line
getWindow().requestFeature(Window.FEATURE_ACTION_BAR);
right after super.onCreate() in the onCreate() method. This change was made to fix a null pointer exception and I don't think it has anything to do with the screen rotation problem. Does anyone know what is the cause of lost connections and how to fix the issue?

Can you try this one? Should be able to do the trick.
android:configChanges="orientation|screensize"
Caution: Beginning with Android 3.2 (API level 13), the "screen size"
also changes when the device switches between portrait and landscape
orientation. Thus, if you want to prevent runtime restarts due to
orientation change when developing for API level 13 or higher (as
declared by the minSdkVersion and targetSdkVersion attributes), you
must include the "screenSize" value in addition to the "orientation"
value. That is, you must decalare
android:configChanges="orientation|screenSize".
From http://developer.android.com/guide/topics/resources/runtime-changes.html

define the targetSdkVersion depending on the device

I have defined in my manifest android:targetSdkVersion="15" and I would like to test with a device with API level equal to 17.
The minSdkVersion is set to 15.
<uses-sdk
android:minSdkVersion="15"
android:targetSdkVersion="15" />
I know it will work since minSdkVersion is set to a lower version than the device's one but my question is should I change the targetVersion whenever I change the device ? Isn't the targetSdkVersion supposed to be always equal to the one of the device I am testing with as it is said in the reference
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html ?

You shouldn't change the target version with every device, but with every new API level that is released.
As the webpage that you've already posted states:
As Android evolves with each new version, some behaviors and even
appearances might change. However, if the API level of the platform is
higher than the version declared by your app's targetSdkVersion, the
system may enable compatibility behaviors to ensure that your app
continues to work the way you expect.
and a few lines further:
To maintain your application along with each Android release, you
should increase the value of this attribute to match the latest API
level, then thoroughly test your application on the corresponding
platform version.
Every new API contains new features, but will also deprecate old ones; some may even get removed completely! So devices running with a higher API level might not support the same features anymore that you used in your app, which forces them to enable compatibility mode to once again be able to run the app properly.
In short, no, your targetSdkVersion should just be as high as the highest API goes. The minSdkVersion should of course be as low as possible, and you should try to avoid using maxSdkVersion, as that one will decrease the mobility of your app over time.
Even if your minSdkVersion is 1 and the targetSdkVersion is 19, new devices won't have to enable compatibility mode to run the app.

Google Developer Console optimization tips(minSdkVersion) for tablet design

Find below what google has to say for making an application tablet optimized in its latest Google IO-13 initiatives. My question is :- Why do my app has to have min sdk version greater than 11 to make it tablet optimized? This means my application is not for tablets if I am supporting gingerbread phones which is still active in lot of devices.
At a minimum, check the element to make sure that:
targetSdkVersion is declared with value 11 or higher (14 or higher is recommended), OR
minSdkVersion is declared with value 11 or higher.
If a maxSdkVersion attribute is declared, it must have a value of 11 or higher. Note that, in general, the use of maxSdkVersion is not recommended.

From the <uses-sdk> documentation:
[...] setting [the targetSdkVersion] value to "11" or higher allows the
system to apply a new default theme (Holo) to your app when running on
Android 3.0 or higher and also disables screen compatibility mode when
running on larger screens (because support for API level 11 implicitly
supports larger screens).
There are a few key things to note here.
You don't need to set minSdkVersion to 11. They suggest setting either minSdkVersion OR targetSdkVersion to 11. Doing either will have the same effect for tablets.
You can have an application that runs on tablets just fine without doing this. It simply will use screen compatibility mode, which is not optimal.
If you aren't targeting a higher API version (or implicitly doing so with minSdkVersion), then your app will also not use Holo (without a library), which is a standard UI expectation for apps on newer (3.0+) devices.

targetSdkVersion vs. minSdkVersion: configChanges

I want to avoid Activity restarts when screen orientation changes. In older sdk versions it was done by configChanges="orientation" (in the manifest). In newer versions screenSize was added.
My minSdk is 8, the targetSdk is 17 and I find myself in a weird situation: I cannot put screenSize into configChanges (because of the minSdk) but my phone (4.1) will then destroy any activity on orientation change (because of the targetSdk).
Is there any way out? Can I somehow prevent this destruction without having to target an outdated Sdk (but still keeping it as an option in the minSdk)?

You may leave your android:minSdkVersion and android:targetSdkVersion as you currently have them (8 and 17 in your example).
In order to be able to put screenSize into configChanges, change this line
target=android-someapinumber
in the project.properties file. Choose someapinumber as the android version where screenSize first appeared (e.g., API 13).
Although you asked for a specific "screenSize" problem, this solution applies to all similar situations where you want to support older devices, but at the same time you must use newer features. In this particular case, "screenSize" will be ignored by older devices that do not know this property, so you don't have to worry about backward compatibility. In other cases, you may have to add conditions in your source code like shown below to ensure in runtime that your app will not use features that are not available in a given (older) android version.
if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.LOLLIPOP)
{
// Code that uses features available in LOLLIPOP and newer
// versions of android, while the app also runs on older versions
// and supports them because of android:minSdkVersion.
}

Ah I finally figured out solution:
As far as we cant affect "known suggested solution" with screenSize property as eclipse fires xml parse error on screenSize when we specify android:configChanges="screenSize", if we specify in targetSdkVersion 12 or less android os will not restart activity on orientation change. (Also I did now know and was using targetSdkVersion for identifying maximum supported sdk version. But as I researched again for this there is maxSdkVersion.)
So by this settings:
uses-sdk android:minSdkVersion="10" android:targetSdkVersion="12"
android:maxSdkVersion="17"
...
android:configChanges="orientation|..."
Os will not restart activity on orientation change and application will still support minimum and maximum sdk versions but will run in compatibility mode with sdk 12 which is highest version of sdk not restarting activity which will solve the problem above.

Equivalent sensorLandscape screenOrientation for api level 7

I have an activity that requests a landscape mode.
However with some tablets, the reverseLandscape should be used.
That's why I'd like to use the sensorLandscape screen orientation, but it is only available for API 9+.
Mine is level 7, and if I change it I will loose a big part of users.
How is it possible to do this feature with API level 7 please ?
Thanks...