I have searched for references on this issue but all of my attempts have been unsucessful so far. I would like to know to what extent does Android supports the OMA DRM specification? Does anyone knows of a reference that states what can be expected from different versions of Android?
It seems that this specification is actually less supported with newer versions of Android (Eclair, Froyo) than it is with older version (Cupcake). For example, in my tests with download descriptors, the devices using Cupcake could download correctly while the devices using Froyo and Eclair showed the DD as xml.
In similar fashion, can we expect the support of the OMA DRM spec. to be the same for all devices running a given version of Android or does it vary with each device? (In different words: is the version of Android tailored for each device by the manufacturer)
You seem to be asking two questions here:
Does Android support OMA DRM?
This was previously asked around the time of Android 1.1 - at the time it was suggested that OMA DRM 2.0 was not supported except by third party libraries. [More recent posts in the google-platform discussion group] suggest that this is still the case.
Could manufacturers customize Android to add OMA DRM?
Yes. If you are planning on manufacturing an Android device that needs this functionality, I would suggest contacting one of the companies mentioned in the aforementioned question. If you are an application developer looking to add this functionality to your application, you would still have to find a manufacturer who has done this, hope that their device is development-friendly, and realize that only users of that specific device will be able to use your application.
Related
The hardware drivers for Nexus devices are provided on the android site. The android OS, is used on so many different devices by different manufacturers, that it was designed so that the many OS operates independent of the hardware (using the HAL).
So why isn't it simple for every nexus device to support future versions of Android, beyond the one that was last officially supported ? After building Marshmallow on Android a few times, it seems like the steps are:
Download source.
Add binary blobs for hardware (provided on android site)
Compile
For newer Android versions, at best I can imagine the missing step is that the old binary blobs may not be compatible with newer versions of Android API's. But the solution is just to use the blobs from newer devices (that have the same hardware) that do support a new version of Android.
Is that correct (just get the blobs from a new device with the same hardware) ?
Yep. You are right.
If there is no support for your device by the OEM, you can either shim the blobs with missing symbols (check logs for them) or update the blobs from latest device with same processor/hardware. Basically you need to update adreno, widevine and few more stuff and your device will be good to go.
Check https://github.com/LineageOS to check how to shim.
I hope it helps.
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 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'm starting to broad my developer skills also to the Android development.
I installed all the tools and configurations and every thing seem great, As a default settings I install the 3.2 SDK, but there is not too much docs on that one, mode of what is out there is on the 2.x SDKs.
Is it like IOS, does android have a good backward computability? Can I stay with the 3.x and count on it (with the features that are in the 2.x SDKs) to work on 2.x phones? What are the common version in the Android devices this days? I have lots of newbie develop questions like that, as i want to start from a good starting point and there are lots of materials and tutorials over the web that are not up to date.
Also, does any one know about a good site for this kind of Q&A?
Thank you,
Erez
As of July 5th the version with the largest market share (59.4%) is 2.2 (API Level 8) as shown here
http://developer.android.com/resources/dashboard/platform-versions.html so Consequently I would recommend using that as a starting point unless you are solely focusing on the new honeycomb tablets (<1% market share).
As for backward compatibility, android is completely backward compatible for the most part. Unless of course you use a new feature that is only available starting with a certain API level. Google's Android market is good about only allowing apps that will run on a certain API being visible to that phones user. This is enforced by the API level as recorded in the manifest file that is created with every Android app and set by the developer.
To help you with the API level, the SDK docs show what API a feature/object started with in the upper left hand corner. You can also view the specific changes in each platform and it's corresponding API level at http://developer.android.com/sdk/index.html.
As for a good website to get started I would recommend the developer site at developer.android.com and this website of course. Also the book Android Wireless Application Development by Shane Conder and Lauren Darcey (2 ed) Is very good. (I am not connected with the book just currently reading it). Make sure you get the latest edition.
Hope this helps,
George
Above is good info, but it would be advisable to develop for 2.1 and up at the moment, considering as of this answer's writing, 2.1 makes up 17.5% of the market and 2.2 makes up 59.4% of the market.
http://developer.android.com/resources/dashboard/platform-versions.html
OP should also be advised that version 3.x is specifically for tablets, so that may not be the best choice for a starting developer. My advice is to go with 2.1. Most of the documentation is up to date with that, and you won't have access to things you don't need yet (fragments, tablet-specific things)
Hope this helps!
You can read about application forward and backward compatibility in the docs.
Generally apps are forwards compatible but not backward compatible - new APIs introduced in one version are not available in an older version.
This pie chart shows distribution of devices accessing the Android Market and based on this I would try to target devices using 2.1 or newer to cover most of your users.
Your decision should be based on whether you need a feature introduced in a specific version. For example, if you want to add NFC to your app, you'll need Android 2.3.3 or newer, but otherwise there's no reason to exclude older devices.
I recommend learning about Fragments and using the compatibility package to use them on targets below 3.0. This will make it easier to reuse view elements on both tablet and phone devices. Note that if you only intend to develop for phones, 2.3.4 is the latest phone version of Android at the time of writing. Later this year, 3.0 for tablets will merge with the phone version to provide a unified OS version as with iOS.
Android 3.2 is just released publicly on friday, July 15th. You can start-off with Android 2.3.3 and 3.2 installation and development.
Android applications are mostly forward compatible. (But not always)
The best place to find all your answers is developer.android.com
I have been developing for Android 2.2+ for the majority of the year. But when I look at the "List of Android Devices" on wikipedia, I see a substantial number of Android 2.1 devices. A lot of these may have never received OTA updates and some were released not that long ago. I've seen the readily available statistics about Android 2.2 being the most widely used, but I can't help feel like I'm cutting a big audience out.
I've seen a few differences between 2.1 and 2.2 (like with TabWidgets) but if I just dropped my SDK down to 2.1 what differences should I be aware of?
Is this even less relevant now, thoughts and experience welcome, or links to informative sources
As always, it depends on the specific features of your application. I don't want to talk you out of supporting 2.1. I'm certainly not an expert. But you have to weight how much work it is to make your application available to the last 20% percent of the market.
Although I like the idea of maintaining a lot of backward compatibility, I think it makes sense to support the "current and future market" more than spending a lot of effort to support older devices. Of course, if your application works well with older API levels that's great and you should obviously set it as such. Who knows, maybe adding support for 2.1 will take you less time than it took me to type this. :)
You can see up-to-date stats directly on the Android Platform Versions website.
I think the more interesting graph is the 2nd one that shows "number of Android devices that accessed Android Market" recently. (current one inlined here). So if you support 2.2 it looks like you're supporting over 75% of the market (and that number is only going to grow).
One other thing to watch out for is performance. In addition to features the pre-8 API doesn't support, older devices sometimes just don't have the performance of the newer ones. (Not always the case since there are dozens of devices.) One test device I used didn't support Live Wallpapers, not because of the API, but because the device just didn't have enough horsepower.
I'd definitely target 2.1 to get the largest audience.
The changes you have to be aware of are not huge, but can definitely stick you if you don't catch them.
A couple of things:
showDialog(int) can't take a Bundle as an argument in 2.l. The 2.2 call is: showDialog(int, Bundle)
You use a different function to access the SD card (also note that the SD card paths are different in 2.1 and 2.2)
I suggest using the android dev's reference pages feature of filtering by version. It'll make coding for 2.1 much easier.
http://developer.android.com/sdk/android-2.2.html
Personally I think you should just use the lowest you can support without damaging your functionality, features or UX.