Can Android 2.3 SDK cross compile to earlier versions? - android

I have an Android app that's been on the market since v1 of the OS. I haven't touched it since and thus forgot all that there was to forget about developing for Android.
With the new Android 2.3 SDK, can I compile my app so that users of previous OS releases can also use it (say 1.6 or 2.1)?

Sure. Just put minSdkVersion in your Manifest.

Android has changed A LOT since the very first version.
many things have been deprecated or aren't supported anymore.
You should check what's you application is using that's not being supported now.
2.3 has got major changes in everything including the Dalvik.
The things it has stopped supporting will crash if your app uses them.
I would suggest a revamp of the APIs that your app is using.

Related

Android benefits and drawbacks of build target upgrade?

I changed the build target from 7 to 16, with the only reason that I want to compile with the newest SDK. I still want to target versions starting at 7.
My project compiles and ran without problems on 2 devices. But I'm not sure if this is safe. I don't want to realease and that it crashes on some devices, because some things I'm not aware of.
Does it anyways make sense to upgrade the build target, without any specific reason?
Edit: Just to make it clear - I'm not doing it to target newer versions or support new features (I'm already using the compatibility library). It's just, because, maybe with newer build targets the internals have been improved - like performance, etc.?
If you do not use any functionality of the new SDK version(s) it does not make sense to update this requirement 'just for upgrading it'.
When running your application on a device, it will use that version, so it already makes use of the newest internals.
The android library is backwards compatible (meaning it is compatible with older version). The support library provides forward compatibility (meaning it adds functionality to match the newest android library version), the support library is provided with the application (in the APK), so it is available when required. The application first tries to use the android library (so it always uses the newest internals for that device) and if functionality is not present, it tries the support library.
If you require some new functionality then you should upgrade to that SDK version. And (eventually) add code to check the running version and provide an alternative for devices with a lower SDK version.
To find out the SDK version at run-time, for providing alternatives, use android.os.Build.VERSION.

Admob requires api-13 or later can I not deploy on old API-8 phones?

Google Admob requires that I have to compile my project with API-13 or later. To be able to use admob sdk.
My application is meant for mobiles with api-8 or later.
Does it mean if I compile my app with Api-13 or later I have to abandon my app support for older phones before Api-13 ?
My understanding is that since admob requires minimum api-13 to compile , it means it calls functions which are not available on old phones, so I am confused that potentially It won't be able to run my app for Api-8 to Api-12 and probably crash ?
Please advise me on this,
Does it mean if I compile my app with Api-13 or later I have to abandon my app support for older phones before Api-13 ?
No. If you read the AdMob documentation, "The Google AdMob Ads SDK for Android requires a run-time of Android 1.5 or later (set android:minSdkVersion to at least 3 in your AndroidManifest.xml). This means you can develop with the latest version of the Android SDK and your app will still run on an earlier Android version (1.5 minimum)."
My understanding is that since admob requires minimum api-13 to compile , it means it calls functions which are not available on old phones
It conditionally "calls function which are not available on old phones". This is fairly commonplace in Android development -- you use Build.VERSION.SDK_INT to determine if you are on a newer device and do one thing with newer APIs, but do something else on older devices.
in the android manifest i left the mini sdk as 8 . I then used ADT .. right click on project went to properties and set the target API to 13. tested on both devices with different API, works.

How can I use PhoneGap 1.7 for deployment on Android 2.x devices?

I am currently using PhoneGap 1.7, just having created the HelloWorld app, per the instructions at their site. However, I believe it requires Android Revision 15 or higher (4.0.3). I will eventually be wrapping a jQuery Mobile app with PhoneGap and I need it to be runnable on Android 2.x. Android 1.x and 3.x would be nice but are not required. How can I create a deployable app that will work on 2.x and 4.x versions of Android (with 1.x and 3.x being optional)? I hope I don't have to have different versions of PhoneGap and thus different deployment app versions. I'd like to have one deployable app for all versions.
Thank you very much for any help.
I am not familiar at all with phonegap. But with native development the API levels are backward compatible. So you can build the application with API 15, but set the android:minSdkVersion in the manifest to something lower. I imagine this is how phonegap works also, so even though you are using the newest API level it should still be backward compatible.
i.e. in the manifest of a native app
<uses-sdk android:minSdkVersion="7"/>
would indicate that the application is able to run on any devices that are Android 2.1 or newer. Even though you've added the 4.0.3 android jar file to your project the system is smart enough to make sure that it still works on the older devices as long as you set this in the manifest.
It is also worth noting that if your app takes advantage of any newer API's then you'll have to come up with a way to ensure those features get turned off if the app detects that the OS version it is currently on is too old to support the feature.

Android Developer: change version

Is there a way to change the Android version on my app without redoing everything? I just realized that Nook Color only has version 1.4. Well, I have my app set at 3.2 ... so those who have the Nook Color will not be able to access it. Why on earth did I do this to myself!
I am using Eclipse.
You can certainly create multiple .apk files for different versions. See this article about it. However, you may not need to if you haven't used any 3.2 API calls. You may be able to just change the minimum sdk level in the manifest file, update the version code, and republish your app.
You don't have to redo everything , but you can't use 3.2 API on nook color. You'll have to lower your minSDK version in your AndroidManifest.xml to the nook and test your application. If it doesn't compile you can look at using the compatibility libraries allow your app to run on older versions of Android if you are using API calls that aren't available on whatever the nook runs. 1.4 isn't a real version FYI.
http://developer.android.com/sdk/compatibility-library.html
Now you might run into bugs that exist in earlier versions that have been fixed in 3.2. Those bugs might require you rework your features.

Should I compile my Android apps against the latest SDK?

My app requires that devices are running at least Android 2.0 OS. Would it make more sense for me to compile my project with the 2.0 SDK or does it make more sense to always compile my project using the latest SDK, even if it's well beyond 2.0...?
The problem with compiling against 2.1 for example would be that I don't know if an Android 2.0 device would even run an app compiled with 2.1...?
You can target a later SDK version using android:targetSdkVersion while still permitting your app to be run on earlier versions (since apps are filtered out based on the android:minSdkVersion). If you use API's that aren't supported, your app will force close. So, you'll have to pay attention to the API level annotations in the documentation for all functions, and test your app on an emulator set to use the minimum SDK version.
However, the Android Developer's Blog has some good advice on how to write applications that support earlier SDK versions - at a cost of some added work, of course. Whether it's worth it depends on whom you want to reach, obviously.

Categories

Resources