We have a Android CPU dependent code and I would like to see how many devices used by customers are ARMv6/ARMv7, if there are still ARM v5, how many of ARMv6 have VFP, what is the Tegra or Neon percentage. Any tips where such statistics could be found?
BR
STeN
If you want to collect such data, simply do "cat /proc/cpuinfo" and feed googleanalytics account with this data :) ( i am doing a lot of research this way ).
If you are looking for already made statistics i think that any of them is outdated :)
Normal smartphone user change his handset every year or two, dependant on his carrier policy,
i would forget about armv6/armv7 and neon on your place, armv6 is currently sold only in some chinese crapphones :), and neon is very nice but for example tegra 2 is incompatibile with it,
the other side is that tegra2 has about 0.05 percent of market share, vfp is supported in every armv7, and arm v7 is about 95 percent of market or more. I doubt that anybody who use google play or actually is paying for apps use armv6 or antyhing older,
most of google play users are using samsung galaxy for example about 20percent of overall downloads of my apps are downloaded on galaxy s2, 10 percent on nexus, and it looks like supporting all/older devices its not a good idea at all, its takes a lot of time, and paying users are usually using highend handsets.
In the end I don't think that this kind of data can change the way you write your application, because no matter what report says the situation is:
the Play Store application do not check for this kind of features
considering the previous statement, the only way to run your application correctly is to check at runtime for the support for that technology, for example you have to check if the device supports NEON, and it's your problem to do that as programmer, the Play Store doesn't check for that.
if you are not using a particular instrunctions set you don't have this problem so this question should be erased in 3, 2, 1 ... !
Another consideration is the fact that ARM is an architecture that can have multiple forms and with that i mean the fact that if you pick 2 commercial product like the Tegra 2 and OMAP 4430, they are both ARMv7 devices but the Tegra 2 doesn't support NEON while the entire OMAP 4 family support this kind of registry, so not even the label about the instructions set can really tell you about the real potential of the device itself.
In the end all that it's worth to know is that the Play Store tells you nothing about this, knowing about the most used platforms won't really help, and in the end you always have to do the same task and the check for this kind of features is up to you.
Related
What are the next Android smartphones to be compatible with ARCore?
Is there a known list of future compatible devices yet? Maybe a general project schedule?
We are about to purchase some units for AR development assessments, at first we thought about trying one of the Tango devices out there (we already had a good experience with Tango), but our current bet is that the ARCore platform will beat it in terms of market share.
Currently, the compatible devices are only:
Google Pixel
Samsung Galaxy S8 (the non-plus version)
But obviously, we would prefer to choose from a wider variety (e.g. S8+, G6...)
I know that there is a known hack to make it work on other devices, but it is better to start on the right track with a compatible one while we still can.
Also, is there a way to run ARCore on emulator that connected to webcam?
For test purpose.
(I don't think this answer deserves the bounty, and I also don't think you'd get a worthy one any time soon. But let's roll anyway:)
So I did a bit of a research as to why are these the only devices supported. It's a tough question to answer of course, but we can speculate.
I read through the reddit on the subject (among other sources) and it seems that ARCore does not require some special hardware, but it does require a "calibration profile" per each specific set of camera, sensors, and builds. I.E. each device.
I've found this Medium article about what Apple had to do in order to calibrate their own ARKit coupled with some speculation about Google's calibration process.
WOW! Turns out it's a really heavy task. And it seems that Google has chosen these devices specifically because they've already undergone some initial calibration for other purposes. So it's even harder to start the calibration from scratch.
OK... So?
So... There seems to be mixed news here:
The good news is that ARCore does not rely on some fancy new hardware platform with some fancy new standards that are gonna be hard to enforce in an already highly fragmented market.
The bad news is that unless an automatic calibration process is invented, each device SKU needs to undergo a costly, lengthy and manual process. It's very hard to estimate the costs involved, and even harder to estimates the rewards.
Which brings us to where we started: My guess is that device manufacturers will not be quick to jump on the ARCore bandwaggon. Yet.
It seems that it's gonna take some time before you'd get a reliable answer to your question.
The current list of ARCore supported device manufacturers and models can be found here:
developers.google.com/ar/discover#supported_devices
To your last question around testing on the emulator, as of this week, you now run ARCore in the Android Emulator with a virtual AR camera:
https://developers.google.com/ar/develop/java/emulator
When you are using Android Studio 3.1, and Android Emulator v27.1.10, just create a new Android Virtual Device (AVD) for the Android Emulator that targets Android 8.1 Oreo (API 27) and verify that the back camera is set to Virtual Scene.
You will get the current list of ARCore supported device manufacturers and models below link.
ARCore Supported Devices
Here is a list of ARCore 1.4 Compatible Devices (last updated October 19th, 2018).
I hope this question is relevant in SO. I posted it in Android forums like XDA Developers but I don't get any answers and at the same time, I believe my question is specific and it is hard to target people that might know something about it.
To introduce the context of my question, I think I will need to describe a bit of my job. I am currently working in a company that needs to transform a phone into IOT device that run our C/C++ library (like JanOS). The idea is to modify a phone to take off the screen and only keep its board with all its features (camera, wifi, sdcard, battery, usb connector ...) that we needs.
I am myself a C/C++ developer and I optimize algorithms. My work is basically to make everything faster using libraries like OpenMP and NEON if I work on an Android platform. I am currently working on two phones that are rooted:
Huawei Honor 5C (4x2.0 GHz Cortex-A53 & 4x1.7 GHz Cortex-A53)
Huawei Honor 8 (4x2.3 GHz Cortex-A72 & 4x1.8 GHz Cortex A53)
I want to bench the library we are developing in my company on these phones. The thing is I can never get to 100% CPU usage using C code or bash script. The CPU usage cannot go higher than 50% letting me think only 4 cores are used. This is where I tried to understood more the platform. I think each phone is based on a big.LITTLE ARM platform to optimize battery saving (I have a doubt about the Honor 5C as it contains two identical cores running at different speed only). The idea is to build 4 group of 2 cores (1 big and 1 LITTLE) so the scheduler can target the right CPU to use depending on the task needs. But my aim is to overcome that and use ALL the cores like a classic multicore platform.
OpenMP can see 8 cores in my platform. But it seems the phone cannot let the thread migrate from 1 group of cores to another. My guess is the cores being seen as pairs by the scheduler, only 1 of them can work even though OpenMP can see 8 cores. I think Global Task Scheduler is disabled and it could overcome if I understood it well. But I'm not an expert of Android development so I might be wrong here.
Do anyone has any idea how I could enable the Global Task Scheduler ? How can I even know if it available in my platform and if it is really disabled ? Or how could I setup my OpenMP pragmas to use 8 cores at once ?
I basically tried to activate the "Performance mode" directly in the phones settings, but it didn't work. That would be too simple
[EDIT]
I went through interesting information lately. I will share them with you as someone might be interested by them and might help me with the kernel building.
I found this git in the OpenKirin project which I think helps building a custom Android kernel. At least I can see the arm64 architecture among the ones possible to configure.
I also saw there is a guard checked called CONFIG_SCHED_HMP which seems to enable the Heterogeneous Multi-Processing scheduling which I think is the subject of my question.
This CONFIG_SCHED_HMP should depend on the configuration. I think the one under arch/arm64/ called Kconfig is the one I should modify and it seems the SCHED_HMPconfiguration isn't activated.
I think this belongs here, as it's about the programming of android phones, but I'm happy to be corrected.
Does anybody have good data on what the marketshare of various cpu speeds are for android? Eg 20% fast dual cores, 30% ~= 1Ghz Single cores, etc. Not so much exact speeds, but the general bucket that they fall into.
I'm developing an app which doesn't run well on the older armv6 ~=600mhz cpus, which I think are a pretty small market but It'd be nice to have actual data to base that statement off of.
appbrain.com/stats should help you to know which devices are dominant and android dashboard tells which android version is. I guess, most of the devices which support (factory-installed) gingerbread are ARMv7 devices as its more adequate to run on such processor. but we shouldn't over rule this fact that ARMv6 can also be upgraded to run gingerbread.
Not a bits, bytes, algorithm and syntax question... but a technology development and business one. Hope that's ok.
At CES 2011, mips.com unveiled new MIPS-processor based smart phones running Android. By what I've read, it sounds like these either might be Chinese-market only (which, lets face it... is huge) or part of a big push by MIPS to elbow into ARM's territory.
Here are problems I see:
- Google only provide first-class support for ARM. Their SDKs are ARM-only. Does anyone know if they have plans to adopt MIPS?
- The Android Market is ARM-only, as far as I can tell. It looks like companies like Velocity Micro (and their little MIPS-based Cruz tablet) have their own "Cruz Market". I think that's awful. Is the Android Market going to be the one-stop shop for Android, or are things fragmenting even more?
- The JNI breaks the processor-independence of the VM. Can multiple processor-specific JNI libraries be packaged into a single app? MIPS binaries aren't exactly small.
Does anyone out there have a crystal ball on these things? Let the assumption be: MIPS won't just go away.
TL;DR: Anyone know WTF is going on with MIPS?
Their SDKs are ARM-only.
The Android SDK is processor-agnostic, outside of emulator images.
Does anyone know if they have plans to adopt MIPS?
The verb "adopt" is too nebulous for anyone to answer this question.
The Android Market is ARM-only, as far as I can tell.
I am not aware of a non-ARM device that meets the Android Market compatibility requirements. This is not a chipset thing, it's a compatibility thing. For example, at present, all Android Market-compliant devices must have a touchscreen, which eliminates MIPS-powered set-top boxes.
Can multiple processor-specific JNI libraries be packaged into a single app?
Yes. That is a key feature of the NDK.
I am pondering the idea of a Wine-ish compatibility layer on Android.
The idea is to run Symbian apps on it as both OSes share ARM hardware.
I have no knowledge of Symbian but I think that given the hardware capabilities of Android devices this could be done with less effort than Wine's windows emulation.
What would be the most significant difference to overcome in this emulator? (threading, storage, ...)
The real problem is not going to be code execution, but the API's to do things like graphics, interact with hardware, accept input, etc. If you have documentation of the original and android has the capability, API translation layers would be possible.
But android's security model outright prevents a number of things that are possible on other phone platforms, and combined with it's "java apis only" allows only inefficient means of doing things that can be done more efficiently on others.
This is of course all about application-level emulation/api translation. If you are willing to modify the android platform itself, supporting just about anything else for which you have documentation (and licensing?) within the hardware capability of the device should be possible.
Hardware capabilities of a device have nothing to do with complexity of an emulator to be hosted. It depends on Symbian's design and complexity.
And, even more, licencing. Even if one could make a Symbian emulator for Android, its legality would be questioned.
It's difficult to answer your question in detail, but since Symbian is open sourced (and Android too), if you've got the time, it shouldn't be too hard to see what sets them apart.
QT is used for the latest symbian OS, and has been ported to Android, you could write apps in QT build for each platform
the problem for writing an emulatir are variouss.
If the Symbian apps are written in in an interpreter language like Basic or similar then an emulator couldn't be too difficult to write. I did such stuff once to make the same code run on linux and windows, and I used a translation API for all calles coming from the software directed to UI, input/output.
I wound guess that the UI capabilities of Symbian are a subset of the Android functions so it would be not too difficult to write a WINE alike thing or an interpreter that runs the Symbian code on different hardware - IF it is only in high language.
But be aware there could be some machine code in the appps and that is processor specific. Most of the Android tabs nowadays run on Tegra, Tegra2 or (soon) on Tegra3, some may run on StrongArm or Arm, some may run on Intel Atom (x86 architechture), so this might get more or less impossible if the CPU isn't binary compatible like ARM / ATOM. Then you need to emulate the CPU as well and that might eat so much performance that you need a 4-5 times stronger machine to run that stuff smoothly.
It won't be too difficult to crack Android to execute Linux-alike binaries, but for sure this "mod" will affect the ability to use or download stuff from regular appstores.
With some apps you might have even more headache, e.G. my MP3 player from Korea runs on Strongarm, but it also executes Flash games from various sources. When there is no Flash player - and Google announced something like dropping support for Adobe Flash - it won't be usable.
The "most wanted" is obviously the Ovi Maps, probably that stuff could be easily converted to another app having offline navigation capability :-) People wrote "Gaia" some years ago, an open source viewer for Google Earth (and later forced to give up) so it can't bee too difficult to realize at least this.