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.
Related
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.
I am looking to source some testing Android and iOS devices for React Native apps. I've looked at the official docs, but there isn't a specific section for it.
I don't think there is a set of 'minimum requirements' per se. React-native applications should work on most modern smartphones, and even some very old ones.
The caveat I would raise here is that it's more about how the app is written, there are many things you can do inside react-native that will kill performance on older devices, such as avoiding unnecessary UI element frame updates. (This can happen if you are hooking into the state changes non optimally)
I suggest having a look at some common anti-patterns when it comes to RN, a good place to start would be here: https://facebook.github.io/react-native/docs/performance (this page goes over common reasons why apps will be performing slowly.)
For your scenario there is no any official smart devices which are recommended to use to test React Native applications.
You can use any of smart devices of both Android and iOS to test your applications.
For testing your applications on Android :
Android 4.1 (API 16) or newer. ( You can find minSDKVersion from android studio app gradle file)
So you can run your application any smart device on or above Android OS 4.1
For testing your applications on iOS :
iOS 9.0 or newer ( You can find Target min OS version from Deployment Info on XCODE )
So you can run your application any smart device on or above iOS 9.0
Note :
My solution is to find devices with different screen sizes.
If you are going to test iOS application try to use different screen sizes and different os Apple devices like -> iPhone SE , iPhone 6s , iPhone 8 Plus , iPhone X
For iPhones try to test both notch devices and normal old devices because you need to avoid notch issues with height and width.
For Android try to use different android os running devices which have different screen sizes with different brands.
As example try to use both low end budget and high end flagship models.
You can find requirements from official git repo here
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.
What is the best method to support older Android devices running stock browser without owning multiple physical devices?
Im interested in Android 2.x ... 3.x. Is it maybe possible to install older versions to newer devices?
It don't think it is possible to install older versions of the browser, but it is possible to run any version of android that you would like using the AVD Manager (Android Virtual Device). Using a virtual device on your computer allows you to control the screen size, software version, and many other factors without having to own a physical device. It can be a little slow if you try to run one on an older computer, but it is definitely worth looking into. It can be downloaded with the Android SDK.
Good luck!
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.