I was searching the net for an official list of supported locale(language) for each android SDK version from Google. Unfortunately, I can't find one and I was hoping someone can help me. The only list I can find that is somewhat official is the IANA Language Subtag Registry. Here is the link: http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
So you mean just because two devices have the same OS version, it doesn't mean that both of them have the same set of supported locales, am I correct?
Correct. This is particularly true for low-end and older devices, as locales take up space. The Android Open Source Project (AOSP) ships with translations for its apps and for core OS messages. Device manufacturers then elect what locales they want to support for their device. In some cases, they remove locales, to save space. In some cases, they add locales, to cover some market that Android itself does not cover (though this is far less common nowadays, since the AOSP has a fairly robust set of translations).
So, all an OS version indicates is what the baseline set of locales is. What a given device running that OS version has may vary from that baseline.
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.
We're developing a mobile website, which we want to say will be accessible by users with Android & iPhones/iPads. I know websites are accessed via the browsers, of which there can be many on a phone, but we want to test them on older operating systems. We want to support a range of users, many without the latest versions of the operating systems.
So I am being asked what devices we need to go out and buy. Now I am assuming most come with the latest OS, and I'm pretty sure you cannot downgrade an OS on either Android or iPhone/iPad without "jailbreaking" the device. Surely there must be some other way of doing this?
How do people test their sites on older systems?
This would apply to Windows phones as well...
A service like this might actually save you some money in the long run:
http://www.browserstack.com/
Other than that, iOS has a significant market share in iOS7, a little in iOS6 and a negligible amount in lesser versions:
https://developer.apple.com/support/appstore/
Covering the last two versions should be good enough for you.
Even if you could find emulators, why not just buy these older devices used? They could be had relatively cheaply and they would also give you the same performance characteristics, which would help in performance benchmarking.
Also, if you use a good mobile library, it should provide sufficient backwards compatibility -- not that this is a replacement for testing :)
You might look into Eclipse. I use this for developing my Android benchmarking apps, mainly via Linux, but some via Windows. It is capable of emulating a wide range of phone and tablet sizes, different CPUs and Android versions, including old ones. It is slow, but the emulated devices have browser and email apps. I don’t know how real the OSs are. It seems that there might be a version for Apple, but I have not studied the detail.
I've gone a long way to find a method, that, ultimately, doesn't work. But read on.
You can download old versions of WebKit. That's not the same as having the real phone, but can help you with some rendering issues.
To do this, you need to figure out which version do you need to test your device. Go search for devices' user agent strings. For example, this string:
Mozilla/5.0 (iPhone; CPU iPhone OS 8_4_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12H321 Safari/600.1.4
Means that iOS 8.4.1 uses Webkit version 600.1.4.
Then you have to figure out which Webkit revision number corresponds to that version. WebKit tags list is helpful here. You can also try searching Google for webkit trac release 600.1.4. For my example, it's revision 171707.
Now go to http://nightly.webkit.org/builds/trunk/mac/1 and find the right (or closest possible) revision of WebKit, download and use it for your testing.
Now I've really found and downloaded it, it says that my new OS X is not supported for this old build. :(
I found there are no RTF-8 and RTL language support on Android OS 3.2.
I use Sony tablet S, current system is Android 3.2
There are 10 million Uyghur people are living in this world.
but I fount Uyghur language and some Arabic fonts become very strange mark on this system.
If I use like "ROOT" to change system language , I may disable to continue SONY system guaranty.
So, is anyone can help with this problem?!
Is there any official support possibility for this problem.
Bidirectional text support is a very popular feature request but it is not yet supported in the base platform.
I am using the default simulator, Can I make simulator identical to some common device
I mean one identical to HTC, one identical to droid motorla, one of samsung, dell, acer,..etc
Here identical I mean all the features that it provide.
Thanks
Yes labbeb Brother, you can download the various devices skin as Htc, samsung and mortolo droid from the following url
http://teavuihuang.com/android/
and unzip the skin which is downloaded and put in the android sdk directory/platform/android3/skins.
Like that do the same for android4,7,8 too
These different devices can be determined by the sets of capabilities that they have as well as which version operating system they support. That's what the "Android SDK and AVD Manager" is for. When you create a new device in the manager, you can select the target API version, screen resolution, and hardware supported in order to emulate a certain type of phone.
For instance, if I was developing on an HTC Hero I would want to ensure that I specify the target API as Android 2.1-update1 - API Level 7 since it is the highest that the Hero supports without a custom ROM at the moment.
Another example is the upcoming Motorola i886. It is an Android OS phone that does not have a touch screen, so for it's hardware you would add the property "Touch Screen Support" = "No".
Generally speaking, a simulator is just that -- it can't provide full and true emulation of the target hardware. To get all features, nuances, bugs, skins, add-ons, pre-installed apps, and whatnot that the target hardware comes with you must acquire the target hardware. There's no full-proof alternative to this yet.
You can, however, simulate many of the important characteristics of the target device. Tilsan linked to a good resource for downloading a whole bunch of skins. You can create your own, too (see
http://mobile.tutsplus.com/tutorials/android/common-android-virtual-device-configurations/).
The default or generic simulator is to display the general functions and may not be specific to any present or future model in the final form. Only authorised developers, manufacturers and industry organisations like OHA the open handset alliance are permitted to develop for specific models as some of the internal hardware including the processor may be proprietory or patented for use in specific countries and open access to the internals could be a breach of rights protection. When using API and APP type environments as application programmers and hobbyists then the development kit can be specific to models and is provided by the brand name or manufacturer by download or on CD and is a concession to the user community.
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.