With Android platform fragmentation, what changes in different OEM handset attributes force developers to port from one platform to another?
Generally speaking, there are no "changes" that "force developers to port from one platform to another" within Android.
There are some bugs in some devices that require workarounds, but these tend not to affect large percentages of applications. Otherwise, the devices would not have passed the compatibility tests.
However, there are two cases where "changes" do exist:
Developers who elect to ignore the SDK boundaries and work with undocumented things will find that those undocumented things are undocumented for a reason, and that OEMs are welcome to change them.
OEMs who do not include the Android Market on their devices, and therefore do not necessarily pass the compatibility tests, may or may not produce devices that will work with third-party Android applications.
Related
i am confuse about android fragmentation. I know about memory fragmentation But unable to understand that What is android fragmentation issue. Although i find many definitions like
Android fragmentation refers to a concern over the alarming number of
different available Android operating system (OS) versions in the
market. The main issue is potentially reduced interoperability between
devices of applications coded using the Android Software Development
Kit (Android SDK).
Can somebody please explain this phenomenon simply. ??
Simply put, there are too many Android devices out there with different OS versions, screen form factors, varying hardware specs etc., all of which are expected to run every single Android app ever developed without there being any noticeable differences in performance, reliability and so on.
Examples:
The Fragment & ActionBar classes were introduced in API level 11. Multiple AsyncTasks would run separate threads in parallel between API level 8 and 10, and serially from API level 11 onwards. This required developers to take cognizance of app behavior on different OS versions. To assist developers, Google provided support libraries that would provide newer APIs' on older platforms that did not have those features. The latest version of the support library lets you have the new Material Design features on older platforms.
An app's UI needs to be uniform across tablets, phablets and handsets alike. This is why the Android framework compels developers to prepare layouts as an XML hierarchy: this is a self-scaling approach that automatically scales & positions UI elements on different screens with the correct proportion and sizing. Also, apps can display totally different UIs' depending on the screen size and OS version, and the Play Store even lets you upload different app versions for different screen sizes or different OS versions.
Apps that have specialized hardware requirements will also not run on phones that do not have those features. Games like Asphalt, for instance, require a pretty powerful processor/GPU & lots of memory, and cannot run on low-end devices. Some apps require certain specific sensors, and will not even be visible in the Play Store on phones that do not have those sensors. The Bluetooth Low Energy (BLE) functions were introduced on API level 17, and will not run on lower platforms.
The Android SDK is designed to help developers overcome the problem of fragmentation.
It's not a technical thing like memory fragmentation. In this context, the word "fragmentation" refers to the changes in user experience (menu items getting moved around, etc.) and developer experience (which APIs are available, etc.) from one version of Android to the next. Sometimes developer-facing API changes influence the user experience. For example, a user's favorite widget might stop working on the latest version of Android because Google decided to break some API that it depends on. Vendors and carriers make it worse with all the customizations they install, plus weird device-specific bugs. The end result is that there are effectively hundreds of different versions of Android instead of just a dozen or so. It becomes very difficult just to get an app to run on all of them, let alone provide a consistent user experience.
I don't think anyone has ever attempted to develop a metric for this kind of fragmentation, so it's hard to say whether Android is really more fragmented than other platforms. My impression is that it is, but my standard for comparison is the J2SE API.
(Let me begin by saying that a) I appreciate this is the wrong place to ask which version I should use, especially because my question is only locally relevant, and b) I am surprised this hasn't been done to death, but it appears it hasn't!)
At work, I have been tasked with writing an Android application for internal use, by largely non-technical users. We have an existing application (which is dire), and a bunch of devices (currently all 7" tablets, but this is not necessarily going to be always true) running Froyo and Gingerbread for which the manufacturer has no plans to release ICS updates. On the one hand, it would suck to obsolete that hardware (although we could go for non-supported ICS-based 3rd party ROMs), but on the other hand it seems crazy to restrict myself to the 2.2 API when ICS seems to offer a range of shiny new features.
Is there a good comparison reference out there, to see the key differences between API levels? Also, given the glacial adoption rate of 4.0, am I insane to even consider dropping 2.x just yet? And most importantly of all, what factors should inform my decision as to which API to support, that I haven't even mentioned above?
First Question you have to ask yourself is: Which feature do you want to use from ICS which is NOT available in 2.2/2.3 ? If the answer is "I don't know" then you absolutely should stick to 2.2. You have the option to use a SupportPackage, if you like to integrate some features of Higher Versions.
If you know a specific feature you'd like to use, check if it is inside the SupportPackage.
You can use this
http://developer.android.com/sdk/api_diff/9/changes.html
for differences.
I personally think that for phone apps support for new apps must be from 2.2 onwards. For tablet 3.0 onwards, because 3.0 and onwards are really tablet OS'es and 2.2,2.3 are phone OS'es. You can use support packages for lower versions if you need higher end features(not all of them, but important ones like fragments etc.,). But for Phones I d stick to 2.2 and for tablets well, since Android was customized 3 onwards for tablets, I generally would go for that, unless you have 2.2, 2.3 tablets in mind as targets.
I am trying to write an android application that uses several of the android apis(like policy manager, package manager, wifi apis etc).
The concern i have is, android being open, manufacturers/carriers are free to take any specific version of android as their start point and customize the same and ship it with the device.
Note:Please excuse me if this post is in anyway a repeat of earlier posts on the same/similar topic. In such a case, appreciate anyone sharing the earlier post.
Few things that bother me are:
Does android enforce/require manufacturers/carriers to retain the default apis and only over-ride/customize the look-and-feel?
even if manufacturers change the implementation/behavior of the basic apis that comes from android, do they adhere to the interfaces so that my code doesnt break?
how do i ensure/test that my code works on all of the android devices since there is a possibility that one or more customizations could break my whole application?
I know these are some naive questions for many of you who may have been on android for a while, but any pointers in this regard would be of immense help.
Any other information in general w.r.t cross version, cross device incompatibilities and strategies to deal with them would be very helpful.
Thanks a lot in advance.
Regards,
Deepak
Your concerns (and many other developers) are addressed by: http://source.android.com/compatibility/index.html
But this still does not guarantee that manufacturer will not change API and break your application.
The common approach is to initially target subset of devices that make up large percentage of market and then implement workaround for other devices (if necessary). Sample info about device market penetration can be found at:
http://opensignalmaps.com/reports/fragmentation.php?
Kind regards,
Bo
First off, I don't believe you should need to worry about this. Only after you have thousands of users will you end up needing to face the more complex issues caused by the great number of manufacturers offering Android devices. This should not discourage you from developing for Android.
Does android enforce/require manufacturers/carriers to retain the default apis and only over-ride/customize the look-and-feel?
No. But it would certainly work against them if they remove important APIs from the system. The core exists as a whole, though there really isn't anything preventing them from removing or disabling chunks as they wish. For example, AT&T had disabled the ability to sideload apps on Android devices some time ago (but I don't think they still do that). An example of a device with reduced functionality: Amazon Kindle Fire. It doesn't at all look like Android in the majority of its interfaces (except within third-party apps) and it doesn't offer the complete API set. Even with those dramatic changes, Android app developers still have great success building and selling apps that run well on the Kindle Fire.
Even if manufacturers change the implementation/behavior of the basic apis that comes from android, do they adhere to the interfaces so that my code doesnt break?
That's the idea, but there isn't anything in place to forbid them from breaking things. Nor is there anything that will keep them from introducing bugs accidentally.
How do I ensure/test that my code works on all of the android devices since there is a possibility that one or more customizations could break my whole application?
I know that some manufacturers will offer an emulator for their devices/configurations to help test against their systems. For example, Motorola offers MOTODEV Studio for this purpose.
I am pondering the idea of a Wine-ish compatibility layer on Android.
The idea is to run Symbian apps on it as both OSes share ARM hardware.
I have no knowledge of Symbian but I think that given the hardware capabilities of Android devices this could be done with less effort than Wine's windows emulation.
What would be the most significant difference to overcome in this emulator? (threading, storage, ...)
The real problem is not going to be code execution, but the API's to do things like graphics, interact with hardware, accept input, etc. If you have documentation of the original and android has the capability, API translation layers would be possible.
But android's security model outright prevents a number of things that are possible on other phone platforms, and combined with it's "java apis only" allows only inefficient means of doing things that can be done more efficiently on others.
This is of course all about application-level emulation/api translation. If you are willing to modify the android platform itself, supporting just about anything else for which you have documentation (and licensing?) within the hardware capability of the device should be possible.
Hardware capabilities of a device have nothing to do with complexity of an emulator to be hosted. It depends on Symbian's design and complexity.
And, even more, licencing. Even if one could make a Symbian emulator for Android, its legality would be questioned.
It's difficult to answer your question in detail, but since Symbian is open sourced (and Android too), if you've got the time, it shouldn't be too hard to see what sets them apart.
QT is used for the latest symbian OS, and has been ported to Android, you could write apps in QT build for each platform
the problem for writing an emulatir are variouss.
If the Symbian apps are written in in an interpreter language like Basic or similar then an emulator couldn't be too difficult to write. I did such stuff once to make the same code run on linux and windows, and I used a translation API for all calles coming from the software directed to UI, input/output.
I wound guess that the UI capabilities of Symbian are a subset of the Android functions so it would be not too difficult to write a WINE alike thing or an interpreter that runs the Symbian code on different hardware - IF it is only in high language.
But be aware there could be some machine code in the appps and that is processor specific. Most of the Android tabs nowadays run on Tegra, Tegra2 or (soon) on Tegra3, some may run on StrongArm or Arm, some may run on Intel Atom (x86 architechture), so this might get more or less impossible if the CPU isn't binary compatible like ARM / ATOM. Then you need to emulate the CPU as well and that might eat so much performance that you need a 4-5 times stronger machine to run that stuff smoothly.
It won't be too difficult to crack Android to execute Linux-alike binaries, but for sure this "mod" will affect the ability to use or download stuff from regular appstores.
With some apps you might have even more headache, e.G. my MP3 player from Korea runs on Strongarm, but it also executes Flash games from various sources. When there is no Flash player - and Google announced something like dropping support for Adobe Flash - it won't be usable.
The "most wanted" is obviously the Ovi Maps, probably that stuff could be easily converted to another app having offline navigation capability :-) People wrote "Gaia" some years ago, an open source viewer for Google Earth (and later forced to give up) so it can't bee too difficult to realize at least this.
I'm wondering if is possible to install/use Android with other phones? Will be nice to have it on such a piece of hardware like the new SH004.
Mobile phones are generally very hardware independent of each other and require a serious amount of hacking in order to do any sort of "moding".
I can barely find any information on the SH004, but I think it will have to be out for a few months before you will even start to hear people of moding it, yet alone installing another Operating system.
Your best bet is to find specialised forums such as CellPhoneHacks, (There are better around, but not sure if I should link to).
Android is actually designed to be portable, and to provide source code for most of the generic pieces. However, the possibility of running it on a consumer device intended for a different operating system/framework depends on three things:
1) The hardware must have sufficient capability - likely meaning it was originally designed to have comparable capabilities under whatever OS it shipped with.
2) Sufficient low-level documentation must be published or reverse engineered to adapt a Linux kernel, flash memory driver, user I/O drivers (touchscreen, etc), and anything communication related (wifi, mobile, etc) and optionally any extras (accelerometer, gps, etc)
3) It must be possible, either by design or by finding an exploit, to run arbitrary code on the device - ie, boot an image which has not been signed by an approved party such as the OEM.