android:minSdkVersion="4" causing strange problems - android

I built my applications without specifying a minimum sdk in the beginning. However after I added that line to publish to market I found my applications are behaving very differently for example buttons are smaller, etc... In particular I'm having problems with an application that records sound which was working fine when no minimum sdk was specified, but crashes when I specify one. I've tried specifying the minsdk to that of my phone which is 7, but that doesn't seem to help.
What's the default minimum sdk when none is specified? I just want my application to run like it does normally.

If you don't specify a minimum or target SDK version you get a lot of compatibility mode behavior. The device you're running on is probably a HDPI device and you were probably looking at a UI scaled for compatibility mode before you added the minSdkVersion, hence the smaller buttons - your app is now running at the device's native resolution.
Apps that target SDK 3 and below acquire several permissions by default that must be explicitly requested by apps targeting newer SDK versions. Check your exception message when your app crashes, it might be a security exception for a permission that you need to explicitly request in your manifest.
See the following link for more info: http://developer.android.com/guide/practices/screens_support.html

Related

Regarding the new requirements for updated Android apps in Google Play

Google Play recently issued a heads up to Android developers to update their apps with three new changes : https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html
I have a question regarding updating the targeted SDK to version 26. When I made this change for one of my apps, the Developer console showed me a warning saying that this new APK would not support an x number of devices, since it does not fall into some SDK version criteria. Since the app did not have too many active installs, I went ahead with it.
Now I need to do this for another app of mine which has quite a good number of active users. Would making this change of targeted SDK version have any impact on user having low end Android OS or older device models?
Could somebody please explain what might be the problems one might face while making such a change, from perspective of existing and new users?
Would love some clarification from anyone who has some info, but particularly from android app developers who have already made these changes.
From a user perspective: no problems, because changing the target SDK does not mean changing the minSDK.
For you as a developer: depending on the gap between current and future target SDK, there may be quite a lot of work to do because the runtime will handle things differently under the hood depending on the target SDK (e.g. permission handling, use of certain libraries, rendering of UI components).
Quoting from documentation for <uses-sdk>
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. You can disable such compatibility behaviors by specifying targetSdkVersion to match the API level of the platform on which it's running. For example, setting this 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 many compatibility behaviors that the system may enable based on the value you set for this attribute. Several of these behaviors are described by the corresponding platform versions in the Build.VERSION_CODES reference.

How to make sure that your application will be compatible with range of devices?

In Google play (app market), if an application is not compatible to your device (for some reason, say small screen size, etc). Then it is not even shown in the list.
Now, as an app developer I never want to unintentionally add a limitation in my app that forbids it from a range of devices.
So, while developing how can I make sure that the application will be able to run on atleast the type of devices that I intend.
Also, right now I'm developing an app & testing it in on my phone with version 2.3.5. And every now & then Google changes some method names & flags.
For newer android releases, I CAN test it on emulator, but testing it on phone/tabs/etc. is a different thing.
Please suggest.
how can I make sure that the application will be able to run on atleast the type of devices that I intend.
In manifest file you can mention, which type of device you want to run your app. And for testing you can create emulators for different devices to test your app. Try to make app UI such that it runs on all devices.
Google changes some method names & flags
Whenever Android changes any thing it will always be upward compatible means if you have made app for 2.2 it will run on 2.2 and above (screen size or resolution is other thing)
Regarding UI see my answer here
Layout for 720*1280 devices
By default apps will be available to as wide a range of users as possible.
There are certain limitations you can define in your manifest file, such as not being available on small screen sizes, but they are at your discretion.
The only limitation Google imposes on you is that any user who has a lower Android version than your minimum SDK version cannot see your app. To get around this, you can either design the app for lower SDK versions (I believe building for 2.2 and up gives you access to about 95% of the user base) or maintain multiple versions of the APK.
Read this. It will really help. Next Eclipse will help you a lot, firstly you can define what you wish to support (screen sizes and hardware requirements or even if they're not necessary but may be used) in the manifest. You can run a version check and implement APIs dependent on which version of Android you're running on. That's personally what I do, I check the API level and if it's greater than or equal to the API I wish to run I run it, otherwise I attempt to find compatible code (often using the compatibility library) or alternatively drop support for that feature, for example JellyBean notifications there's not really any work around for expanded notifications but I can use the NotifcationCompat builder.

How to decide what will be the target android version?

I'm new in the android developing.
I need to write some simple application - and i need to decide what will be the target version.
I don't know how to decide this - because i want to support the most newer version with all the new abilities - but i also want to support the maximum devices ( there are few devices that have old versions )
So, How to decide what will be the target version ?
In the Android Manifest.
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
Set your android:targetSdkVersion to whatever is the last Android SDK version.
Quote from Bruno Oliveira at Google IO:
targetSdkVersion does not affect the minimum SDK level required to run your application. It should always be the latest version that you are aware of.
The only reason you could have to use a lower version would be to detect incompatibilities, but that is not a good reason because Lint does this better.
BUT set your android:minSdkVersion to as low as your app will run on. That's the important one.
For instance, my app uses very new features, but I set android:minSdkVersion to 3 (which means Android 1.5). My code detects Android 1.5 devices, and uses less-shiny controls on them, but still runs correctly.
Detection code sample:
if (android.os.Build.VERSION.SDK_INT > 4) {
ActivityTransitionAnimation.slide(this, ActivityTransitionAnimation.UP);
}
So, here is my suggestion:
Set android:minSdkVersion to 3
Everytime you discover an API is not present at that level, ponder whether the loss of potential users associated with increasing this number is worse than spending the time to implement a workaround.
I would say just start off with the lowest possible target and then as you encounter stuff that you can only do with a higher target you will have to change the target to the higher one. Using APIs that only work on for example 2.3 will show errors if your target is lower (because the APIs won't exist there).
Also you should consider the current state of the "fragmentation" to se what targets are actually being used out there. Looking at this chart (from October 5) maybe it could be worth just starting with 2.1 and se if it is high enough for all the things you want to do:
http://cdn.devilsworkshop.org/files/2011/09/android-OS-fragmentation-report.jpg

Cannot run the Map Example

I'm trying to run the google maps
example but it keep giving me in the console:
"WARNING: Application does not specify an API level requirement!"
"Device API version is 7 (Android 2.1)"
The application never starts,
instead, it shows that frame with:
"The application (...) has stopped unexpectedly..."
Can Anyone point what might be the the problem?
Thanks
I agree with Jay. That warning is not the source of your error. However, you do want to take care of that warning.
In general, you should build your apps to work on the lowest version of the API possible that supports everything you need (I don't go below 1.5 since 0.1% of current devices out there are that old). However, a large chunk still use 1.5. By using API version 2.1, you are severely restricting the devices you will run on. However, if you really need that version you should specify it as a minimum. This will prevent people who have earlier versions of the SDK from downloading your app. In your manifest you want:
<uses-sdk android:minSdkVersion="7" />.
For more info, reference this article in the developers guide.
Open up the LogCat view and you should see more details on the error. I don't think your Warning is the cause of the application not starting. The warning just says that you have not specified the minimum sdk version in your AndroidManifest.xml. It is a warning, not an error. This is good practice, but should not cause the app to crash if you don't do it.
Edit:
If nothing is in LogCat, you might consider running the app through the debugger and see if any issues show up there.

Android - how to design an app that targets all platforms (1.5 and higher)

I have been developing an Android app and testing with a 1.5 AVD and the manifest setting of
<uses-sdk android:minSdkVersion="3" />
My goal is to make this app available to all phones running 1.5 and greater. I had thought that as long as I develop to 1.5 then that was basically all I had to worry about and any phone running 1.5 or higher would see my app in the market and be able to install it. The following documentation however has me concerned that the app may not in fact be visible to all phones in the market unless I go through the following steps to manage various screen sizes and densities.
My layout is very basic and I do not manage any alternate layouts for high resolution, I just let android manage the scaling. Do I need to follow these guidelines in order to have my app visible to all phones 1.5 and higher? Or is this only necessary in certain circumstances?
From
http://developer.android.com/guide/practices/screens_support.html
Strategies for Legacy Applications
If you have already developed and published an Android application based on Android 1.5 or earlier platform version, you need to consider how you will adapt your application so that it is deployable to
* Existing devices, which may be running Android 1.5 (or lower) platform version, as well as to
* Newer devices that are running Android 1.6 (or higher) and offering various screen sizes and resolutions
To support the newer devices and the different screens they use, you might need to make some changes in your app, but at the same time your app may be very stable and so you want to minimize the changes. There are a variety of ways that you can extend your existing application to support new devices with multiple screens and existing devices running older platform versions. You should be able to make these changes to your application such that you can distribute a single .apk to any and all devices.
The recommended strategy is to develop against the most recent version of the platform you are targeting, and test on the minimum one you want to run on. Here's how to do that:
1. Maintain compatibility with existing devices by leaving your application's android:minSdkVersion attribute as it is. You do not need to increment the value of the attribute to support new devices and multiple screens.
2. Extend compatibility for Android 1.6 (and higher) devices by adding a new attribute — android:targetSdkVersion — to the uses-sdk element. Set the value of the attribute to "4". This allows your application to "inherit" the platform's multiple screens support, even though it is technically using an earlier version of the API.
3. Add an empty <supports-screens> element as a child of <manifest>. If you need to enable size or density attributes later, this is where you will add them.
4. Change your application's build properties, such that it compiles against the Android 1.6 (API Level 4) library, rather than against the Android 1.5 (or earlier) library. You will not be able to compile your application against the older platform because of the new manifest attribute.
5. Set up AVDs for testing your application on Android 1.6 and higher releases. Create AVDs that use the screen sizes and densities that you want to support. When you create the AVDs, make sure to select the Android 1.6 or higher platform as the system image to run. For more information, see How to Test Your Application on Multiple Screens, below.
6. Set up AVDs for testing your application on Android 1.5 (or earlier platform). You need AVDs running the older platforms you are targeting, so that you can test for compatibility and ensure that there are no functional regressions.
7. Compile your application against the Android 1.6 library and run it on the AVDs you created. Observe the way your application looks and runs, and test all of the user interactions.
8. Debug any display or functional issues. For issues that you resolve in your application code, make certain not to use any APIs introduced in API Level 4 or later. If you are in doubt, refer to SDK reference documentation and look for the API Level specifier for the API you want to use. Using an API introduced in API Level 4 or later will mean that your application will no longer be compatible with devices running Android 1.5 or earlier.
9. For resource-related issues, you can try resolving them by:
* Adding a anyDensity="false" attribute to <supports-screens>, to enable density-compatibility scaling.
* Creating any size- or density-specific resources you need and placing them in directories tagged with the correct qualifiers. Qualifiers must be arranged in a proscribed order. See Alternative Resources for more information.
* Note that if you add size- or density-specific resource directories tagged with any of the resource qualifiers listed in this document, you should make sure to also tag those directories with the v<api-level> qualifier (for example, -v4). This ensures that those resources will be ignored when the application is run on Android 1.5 or lower platform versions.
10. If your application does not offer support (such as custom layouts) for large screens and you want the platform to display your application in screen-compatibility mode on larger screens, add a largeScreens="false" attribute to the <supports-screens> element in the manifest. See Screen-Compatibility Examples for illustrations of how the platform displays your application in this case.
11. If your application does not offer support (such as custom layouts) for small screens (such as on a QVGA low-density screen) and you do not want Android Market to offer the application to users of small-screen devices, you must add a smallScreens="false" attribute to the <supports-screens> element.
12. Continue testing and debugging until your application performs as expected on all of the platforms and screen sizes your application will support.
13. Export, zipalign, and sign your application using the same private key you used when publishing the previous version, then publish the application to users as an update.
From this answer:
Save your keystore file.
If you lose it, you will not be able to update your app.
Use <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4"/> to be compatible with 1.5 and newer devices.
Make your icons based on the Icon Design Guidelines.

Categories

Resources