In latest Android releases, the AOSP release typically comes with tinyALSA and tinyCompress. In this question, Simon has mentioned that all Nexus devices shall support tinyALSA.
My question is why is android not integrating libasound which has all features required for an audio sub-system as compared to tinyALSA? Is it mainly due to the licensing issues as indicated in source.android.com site?
I can't speak on the behalf of the Android developers, but if I had to guess it's because ALSA has a very old API that hasn't changed due to backwards compatibility reasons.
If you're choosing an audio system where backwards compatibility isn't a concern, the best thing to do is start with a clean slate and a more modern API.
This is consistent with their approach for X.Org Server - completely throw out the system and replace it with something better although one could argue that this was done because X.Org wasn't built with touch screens in mind.
Lastly as you mentioned, Google recommends tinyALSA over ALSA because of the license.
Related
Well there are many tutorials and post about this, but I am not getting exactly how to deal with libOpenCL.so file. Many vendors does not include it inside phone, but my app needs to support maximum available phones today, so do I need to get compatible libOpenCL.so file for each of them?
OpenCL is not officially supported by Android Open Source Project
See: Why did Google choose RenderScript instead of OpenCL
However it appears that Device Manufacturers are including support by adding in the driver.
See: Does Android support OpenCL?
Realize that OpenCL is at a similar layer in the hardware stack as the graphics driver and any particular implementation will depend on the manufacturer and would be specific to that device. You can't just take a libOpenCL.so from one ARM64 device and expect to work for another due to system-on-a-chip specific customizations (number of cores, DSPs, GPUs etc.)
My recommendation from: C++, OpenCV and "what" for cross-platform GPU programing
If you want maximum support - stick to C/C++ code.
If you need OpenCL to make your app performant even with parallelized code, your option is to check if the library is there and warn the user about the lack of support. Ideally then fall back to the parallelized code on those devices without OpenCL.
Until Google makes OpenCL part of the Android Compatibility Definition Document and requires some metadata property, only by the app checking on the device can the app know that OpenCL is even available.
Adding to the answer of #Morrison Chang:
You can not rely on all version of OpenCL in all devices to have everything supported. So I would do a dinamic library loading, and query at runtime for the OpenCL methods are available.
Regarding the library with OpenCL support, sometimes is not even called like that. For example libGLESmali.so has OpenCL symbols and can be used directly.
I am a beginner on android programming. I am at the first at all. I wanna learn some important point.
Now, I am installing the programs and platforms which I need to develop Android Apps. On the SDK Manager there are few options to download Android API.
Which one should I prefer? I want to that, my app will run on all android roms and versions like ICS or JellyBean.
Thanks!
In order to support as many users as you can, you should opt for the lowest version API, since apps written for an older version of Android will work for future versions as well (although they may not be optimal). Once you need a feature in a later version, you can increment your minimum SDK version.
I would look through the different SDK versions (e.g. 2.1) and see which features (and/or permissions) you need for your app.
Keep in mind that older phones may not have certain capabilities, and you may not be able to support them. Therefore you should weigh if what you're adding is worth alienating the users you will no longer be able to support. Android provides a table of market share per version.
You mention that you want to support ICS (4.0) and Jellybean (4.1 and 4.2), which together control a little less than 50% of the Android market. It is worth looking into supporting Gingerbread (2.3) as well for another 45%.
Another option of course is to branch your code depending on the user's OS version, but this requires a little more maintenance work. However, if you are supporting pre- and post-Holo-themed versions (ie for the action bar), it may not add that much overhead.
It really depends on your target market, purpose, and familiarity with Android.
Android maintains forward-compatibility which means an app designed for 2.1 for example will work on later versions (in most cases). However there are some features added in later versions which are only supported starting with a certain SDK version.
This page may be helpful for you
As discussed in other posts, most Android devices don't support recording calls.
Recording AudioSource.VOICE_CALL does though work fine on my Samsung Galaxy S2.
Does anyone know if supporting this is Google's new trend, or it's just a feature specific to SGS2?
I don't believe that Google is moving towards recording voice calls. In fact, I think they are probably working on ways not to allow this due to large security issues. Speaking of which, some recent news that happened a few days ago reports of such security flaws. I don't think that using AudioSource.VOICE_CALL was meant to be used in this way. Hope this answered your question.
Update: News link from 2011 is unfortunately broken now. Sorry about that.
Google doesn't have any control over this (unless they start mandating that devices must / mustn't support voice call recording in their Compatibility Definition Document).They have provided a way for applications to request the voice call audio by adding the VOICE_CALL AudioSource, but the actual implementation of this feature is platform-specific and is handled by the platform vendors and OEMs.
It may, however, be the case that you see more platforms having support for this feature now than you did back in 2011 (or 2010, since it takes a while for new platforms to appear on the market in consumer products).
I've worked with about half a dozen different mobile platforms over the last couple of years. Of these, every single one has had support for recording voice calls, although on two of them the software support was unfinished.
TL;DR: No, it's not an SG2-specific feature, but it's also not universally supported. And it doesn't really have anything to do with Google.
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.
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.