I'm having some errors with running a developed application on a device with android 6.0.1 that runs perfectly on a device with Android 2.3.6. I'm using the same built application (compiled for an Android API 10) for both devices.
The errors are about the application being closed when a new Activity starts and when a contact is selected, I know how I could solve those problems for that device, but problem is that from what I had read I thought that android had no problems with being functionally backwards compatible (maybe there could be some graphical issues but nothing that would make the application crashing, as it is happening to me).
So I'd like to know if this is just some exceptional event that has happened to me, and the most likely thing is that, once I check these errors in some more android versions and fix the code of the app to run on them, something like these errors is not going to happen again, or if events like that are relatively common. If that's the case it sounds pretty painful to have to check and maybe develop accordingly for a lot of versions, so I'd like to know if there's some shortcut which, even if it doesn't offer 100% security of having the application correctly functionally developed, it gives a good percentage of security.
I think in general an app is forward compatible, but only if you ensure that you don't make use of private or undocumented api's.
For example when I first started playing with android there was a bunch of info on the web on how to send and received text messages that were not mentioned at all in the google documentation. Using that info (undocumented api) would have caused my app to break when KitKat came out and introduced and officially documented api for that particular purpose, since at the same time they removed the functionality that was available in the undocumented api. See here for details. of the above example.
Here is a link to some info on compatibility:
https://developer.android.com/guide/topics/manifest/uses-sdk-element.html
And a snip-it of the relevant section
Application forward compatibility Android applications are generally
forward-compatible with new versions of the Android platform.
Because almost all changes to the framework API are additive, an
Android application developed using any given version of the API (as
specified by its API Level) is forward-compatible with later versions
of the Android platform and higher API levels. The application should
be able to run on all later versions of the Android platform, except
in isolated cases where the application uses a part of the API that is
later removed for some reason.
Forward compatibility is important because many Android-powered
devices receive over-the-air (OTA) system updates. The user may
install your application and use it successfully, then later receive
an OTA update to a new version of the Android platform. Once the
update is installed, your application will run in a new run-time
version of the environment, but one that has the API and system
capabilities that your application depends on.
In some cases, changes below the API, such those in the underlying
system itself, may affect your application when it is run in the new
environment. For that reason it's important for you, as the
application developer, to understand how the application will look and
behave in each system environment. To help you test your application
on various versions of the Android platform, the Android SDK includes
multiple platforms that you can download. Each platform includes a
compatible system image that you can run in an AVD, to test your
application.
Related
Do they share the code base and version number?
Does Google release the same piece of code for both and just use different flags for mobile phones and Android Things?
This may be a strange question, as I am particularly interested in Android Application Framework.
Do they share the code base and version number?
From an Android application developers's view point there is not much difference between Android OS and Android Things. I.e. you can successfully deploy an Android app developed for Android (OS version 7+) on a platform running Android Things.
Does Google release the same piece of code for both and just use different flags for mobile phones and Android Things?
No "flags" at all. It's rather a matter of adding new system (C/C++/Java) services specific to the supported platforms with its underlying hardware or removing the old ones, needed for mobile devices and not related to embedded systems. Actually Android Things is pretty much an inheritor of Brillo.
As a quick look consider the following overview of Android Things OS to see how it differs from Android.
With regards to the Android Application Framework, you can expect the vast majority of APIs to be the same on Android phones and Android Things. Specifically, this page details the APIs that are not available:
CalendarContract
ContactsContract
DocumentsContract
DownloadManager
MediaStore
Settings
Telephony
UserDictionary
VoicemailContract
Additionally, a few Google Play Service APIs are not available.
In terms of whether Google releases "the same piece of code for both" the answer is a bit complicated. Android's framework is a combination of a lot of files, some of which only make sense for specific form factors. Different build configurations state what files to include, which to not include, and how exactly to build the correct system image.
I had an idea for my first Android application and it involves Android application talking to a remote server using some API. Now remember, the API here will be used by other web/Android applications as well.
Now the problem is that, the API will be updated often, but the apps installed in my clients mobile, might not be updated frequently. Sometimes, I might also have to introduce a backward incompatible change, which is not supported by older versions of my Android app. What's the best way to do it.
Should I be forcing my clients to update their app?
I see a whole bunch of platforms / SDKs, everything from 1.x to 4.x.
Does this mean I have to build my app separately for all different versions?
My goal is to wrap my HTML5 web app and make it available as a native app in app stores.
You typically build against the latest SDK that you plan to support and test against. This usually means "the current SDK" and is represented in the manifest as "targetSDKVersion". Another value called "minSDKVersion" that indicates how far back you support in terms of the API level. Google maintains the API consistency across past versions of the SDK, so it's usually in your best interest to test against what is current.
However, in newer SDKs, there may be things that cause your app to look or behave differently, so when you update the SDK, tools, and targetSDKVersion, you may have work to do to keep your app looking like it belongs.
Usually you can write an application targeting android 1.6 and deploy it to every device which supports a higher API level. You can compile an application which targets android 4.0 and it will still run on 1.6 as long as you're writing code which doesn't depend on API which isn't present in 1.6.
Since there are a lot of changes since 1.6 there is a compatibility library which you can use. This library doesn't include the actionbar. Therefore you could use Actionbar Sherlock.
With these two libraries you should be able to write applications for 1.6 without having the pain to pass on new techniques.
If you still depend on leatest API features, you could request the API level on runtime and implement features for new devices only. You should avoid to ever use this API on old devices. You can compile it but it would crash on runtime if you do.
I plan on creating an application for users to view their stats of a game I am currently in the process of making but my question is like the title. I am not sure if phones with Android 3.0, Android 2.0 or lower can use the apps? If not, how would I work around this? Would I just not be able to use the new API features such as NFC etc? All in all, if I start developing with Android 4.0 SDK, will all android phones be able to use my app?
My understanding of android development, is that you can build against a lowest common denominator if you build a single package, and it will run on that version, and most likely any newer version. But not the other way around.
The compatibility library (which we're now just calling the support library) doesn't use any special magic to pull this off. You can check Build.VERSION.SDK_INT at runtime and use classloader guarantees to access newer functionality when it's available. Some examples are here: http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-it-too.html
We recommend taking a graduated approach to supporting different platform versions. Provide a simpler version of your UI on older versions and layer features on top as they become available. The link above gives some examples of how to do this, and we're going to continue expanding the support library with more *Compat classes that do the version checking for you when using newer features that may or may not be available on all devices you want to support.
Chris is right. However this can be limiting. What if you want to be flexible and use features of the 3.0 and 4.0 android in you app if the device you're running on has them and then gracefully fallback if they don't? Enter the android compatibility package. You can do development using really old api's (all the way back to 1.6) and still have access to new api features.
I would like to know whether the Android provides any sort of compatibility i.e either forward or backward. It means as in Blackberry if develop an Application with JDE 4.2 then that application will work on any handset with OS 4.2 or higher which means it has forward compatibility. Is there anything similar in Android?
Suppose I develop application with Android SDK 1.5 then will that application work on any handset having OS 1.5 or higher.
Hope to get a reply soon.
Thanks & Regards
Sunil
Forward compat is somewhat assured on major versions. On Android you target a minimum api spec. As long as your are not calling private APIs, Google keeps compatibility going forward on devices that join in on their Open Mobile Alliance.
It doesn't mean someone can't get the Android source and release an Android based OS of their own that breaks all compatibility. These devices wouldn't get Google's Market Place because only licensed devices that Google tests get to use that. If that is where you are releasing, you probably won't have any trouble.
Because the Android documentation is licensed under the Apache license, I'm comfortable quoting a large section:
Android applications are generally forward-compatible with new
versions of the Android platform.
Because almost all changes to the framework API are additive, an
Android application developed using any given version of the API (as
specified by its API Level) is forward-compatible with later versions
of the Android platform and higher API levels. The application should
be able to run on all later versions of the Android platform, except
in isolated cases where the application uses a part of the API that is
later removed for some reason.
Forward compatibility is important because many Android-powered
devices receive over-the-air (OTA) system updates. The user may
install your application and use it successfully, then later receive
an OTA update to a new version of the Android platform. Once the
update is installed, your application will run in a new run-time
version of the environment, but one that has the API and system
capabilities that your application depends on.
...
Android applications are not necessarily backward compatible with
versions of the Android platform older than the version against which
they were compiled.
Each new version of the Android platform can include new framework
APIs, such as those that give applications access to new platform
capabilities or replace existing API parts.
-- From: http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
Though they are forward compatible, Android apps will not be able to use features of the SDK that were introduced after they were written, not surprisingly.
That's not what "forwards compatibility" means. You are thinking of "backwards compatibility". "Backwards compatibility" means that new versions of the platform (i.e. Android) will still run old software developed against an older version of the platform. "Forwards compatibility" is the precise converse -- older software developed against an older version of the platform will still be able to leverage new features of the new platform.
An example of backwards compatibility is that they rename one of the methods in ICS but still implement a deprecated version of the old method and have it forward to the new implementation.
While backwards compatibility is almost always guaranteed, forwards compatibility is only guaranteed in certain scenarios. An example of forward compatibility would be a situatation where they implement a new feature in the OS (for example, "pinch to zoom") and applications written before that feature existed are still able to enjoy this feature.
I think Android System is backward-compatible, and that ensures the forward compatibility of Android application.