Is it expected (or what is the likelihood) that newly produced Android devices to not have GLES 3.2 support? We're developing children apps so we're trying to see what are the odds we get new devices on the market in the future that can cause us problems...
What we need is floating point render textures in unity.
Google publish data here (googling 'android distribution dashboard' will find it in case the link goes stale)
Currently, 78.61% of Google Play users are on devices that support GLES 3.2.
Going forward, I'd say it's a certainty that some newly produced Android won't have 3.2 support, but I think they'll be relatively rare devices and aimed at the cheaper end of the market.
Related
Is possible to run ARCore on older devices?
I want to detect a vertical surface and render 2D image from user gallery on it.
Just it.
Maybe you have other libs for it?
For developing apps using ARCore you need at least Android 7.0 or later (even if you want to detect vertical planes). Some smartphones require Android 8.0 or newer versions. Here's a list of supported devices.
It's impossible to use ARCore on older devices. If we assume that you can use older devices – there are software and hardware issues you will run into. Older smartphones and tablets have weaker CPU/GPU, less RAM, and have no definite OS layers necessary for performing tasks for ARCore.
However, you can try Vuforia Engine 'cause it still supports some older Android devices.
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.
I would like to publish my app on the Android store but I can not get my app to work in the emulator. I cannot figure out why I cannot run my app when so many have published with the same tools as me in the past.
I have downloaded the lastest Android SDK and installed all the API's. There are alot of 2.3.3 devices and my app supposedly supports as far back and API level 3 so I am assuming my app should be working on API level 10. However my app complains that it has been built for ARM5TE and that the device supports ARM5T.
I cannot figure out what this implies and I am able to build with ARM5T but have no idea if that would then mean my app would not work on ARM5TE. I know that most devices are ARM based but I have no idea how many are ARM5TE and ARM5T. I wanted to support the 90% of devices that use the app store that support open GL 2.0.
To improve the ARM architecture for digital signal processing and multimedia applications, DSP instructions were added to the set.[30] These are signified by an "E" in the name of the ARMv5TE and ARMv5TEJ architectures. E-variants also imply T,D,M and I.
The new instructions are common in digital signal processor architectures. They include variations on signed multiply–accumulate, saturated add and subtract, and count leading zeros.
(source)
Most Android phones released in the last couple of years are based on ARMv7-A, which also supports these DSP instructions.
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
For testing purposes I need to buy an android device. Can I get a tablet device with android 3.1 honeycomb and use this to test apps developed on older android versions? Are new android versions backward compatible with older apps?
Not entirely. In many cases yes, but there are exceptions:
There have been some api changes, and more importantly, there are a lot of apps out there which did things that weren't entirely proper, but worked on the devices they were developed for.
Some older apps were written to use input devices not present on recent phones or tablets - hardware trackballs or dpads, buttons, etc.
Also no small number of older apps will display in a phone-sized area leaving the rest of the tablet screen blank.
Unfortunately, the flip side of the vendor customizability of android is that if you really want to do comprehensive testing you need access to a variety of devices, even for a single api version.
Can I get a tablet device with android 3.1 honeycomb and use this to test apps developed on older android versions?
Yes.
Are new android verions backward compatible with older apps?
Yes.
Back version is compatible with android 3.1 but only simple application means without any animation (Like Games) and some special features etc.