I am developing an Android game, which I will upload to the market. I am using the NDK; the majority of the game code is C++.
Should I worry about supporting x86 devices? Are there actually any out there?
Currently I am building for ARMv6 only; building for both ARMv6 and v7 increases the APK size without making it any faster (it's already fast enough). It would be nice if I only needed to build for a single architecture.
If you can do it without too much hassle, I would do it.
Not because there are tons of Android/x86 devices, but simply because supporting multiple architectures is a fantastic way to shake out bugs that you might otherwise never encounter (or that would lie dormant until something changes on the system two years from now, and suddenly your app doesn't work anymore). It will make you a better programmer.
Also, I'm surprised that building for armv7 doesn't confer any advantage. Do you mean that you're already framerate-capped running the armv6 build on an armv7 device? If so, building armv7 may still allow your code to run faster, which typically saves energy even if it doesn't increase "performance". Less energy = people use your app longer.
Now, all that said, I don't know the Android toolkit, so I don't know how much hassle is actually involved with supporting multiple arches. If it's a major hassle, then by all means stick to armv6; it's a good baseline for "most" devices out there.
Related
I am developing a program that is going to be very performance-intense for Android/smartphones. Because I do this on a pc (Windows) I do not really know how my application will perform on a mobile device. I do not want to port this program to android until I have a good working version for Windows (this will be my first Android-app and I don't want to try to troubleshoot something when I'm not even sure whether my program is working).
I am searching for some database where I can compare pc-GPUs with mobile GPUs. I know that an accurate comparison is difficult between such different architectures, however, a small hint about the expected performance would be very helpful.
By the way, I am developing on a machine with an integrated Intel® HD Graphics 4400 and ideally, I want to compare it to something like an Adreno 306.
Rather than using benchmarks for the GPU, look at existing cross-platform applications with similar performance and see how it compares. Install it on your computer to make sure the intensiveness is similar (using whatever benchmarks you want), then install it on your android device to see if it can keep up to your expectations. You can find benchmarking apps or you can use the profilers on Android Studio to see how the device in question is handling the application.
This is about as good as you're going to get. Like you said, so much relies on the implementation and the vastly different architecture. Lastly, if you're building on a framework that builds to other platforms (libgdx, xamarin, etc), you should present a specific question to other users of that framework.
Now I want to install my own developed app on smart phones with android os or ios. Since my app will do many mathematical calculations, thus I want to use off-the-shelf math libraries like Atlas and MKL, could any one tell me whether I can use these libraries on smart phones?
MKL seems not to be available yet:
https://software.intel.com/en-us/forums/topic/281168
ATLAS should build in the Android NDK (i.e., Native Development Kit)...
https://stackoverflow.com/a/1046726/414125
...unless it relies on System V calls for something:
http://math-atlas.sourceforge.net/faq.html#where
In general, however, you may want to architect your app to do any serious number crunching on the cloud. Android is power-optimized, so even if you succeed in installing one of these libraries, they probably will end up performing poorly and using too much power.
I've been seeing reports (rumours) that soon Android will be switching from Dalvik to ART as it's default runtime. I have no real idea what that means, my guess the runtime is (kind of?) like the operation system.
My app doesn't do anything particularly special/unique in the sense of mostly it makes HTTP requests for data, and uses LocationListeners a few times.
On some articles I've read about the rumored change, I've seen some people saying things along the lines of "I like ART, I'd use it right now if X app supported it". (One app I remember being mentioned is Xposed)
I've switched my phone to ART, and my app seems to work fine, so I'm guessing the answer to the title question is no, but I'm curious as to how the Xposed app isn't compatible. What have they done (or not done) to make their app not work in ART?
ART is a different runtime for Android applications. All android apps run inside of a virtual machine, much like java code runs in the Java VM.
Classically, when you compiled an Android app, it would compile to Dalvik byte code, designed to run in the Dalvik runtime (virtual machine).
In Android Kitkat though, Google introduced a new experimental runtime called Android Runtime, or ART. This is a different virtual machine, a re-implementaton of the runtime for Android applications to help fix some of the fundamental flaws in the original design.
ART offers several advantages over Dalvik:
Ahead-of-time (AOT) compilation
Improved garbage collection
Development and debugging improvements
Support for sampling profiler
Support for more debugging features
Improved diagnostic detail in exceptions and crash reports
It should also help with things like the DEX limit.
As to your question, you do not need to do anything as a developer. Google has said plainly that "Dalvik must remain the default runtime or you risk breaking your Android implementations and third-party applications".
Google has announced at Google I/O 2014 that in the Android "L" release and beyond, that ART will replace Dalvik.
ART has now replaced Dalvik on the Nexus devices, and my six existing apps, available in the Google Store, all now fail to run. I see multiple lists of questions about ART causing app failures. I suspect the "new and improved" memory managment garbage-collection is the root cause of much of this. My Samsung devices did not have an option to select ART instead of Dalvik, so I am only now getting user reports of the failures under Android 5.x. It is reported that the implementation of the native interface is significantly less forgiving, and requires different and more explicitly defined global pointers, where previously local pointers would operate correctly. This means anyone using native code, and the JNI (native interface), may have to re-code their app, or target a different platform with a more stable system architecture.
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.
I would like to start doing some Android development, and would like a cheap device to deploy apps to, just for testing and demo purposes. Is it possible to deploy apps to, for instance, an Archos 28? I don't know much about Android development yet, and haven't found a good answer to this question elsewhere. Thanks.
I can recommend the A28 for development. The user experience is rather crashy, part of the problem lies in the low RAM (128Mb is very little for an Android device). But I developed JGame on an A28 and did not run into firmware bugs. It also runs Flash 10.x in case you want to experiment with that.
I second that you should in particular worried about devices with a larger display. I found that graphical performance can be much worse on those devices. The A28 has a pretty good GPU considering it has several times fewer pixels than the average Android device.
Yes, it is running android 2.2 froyo. That should work fine for development purposes. Just keep in mind that some people will be using your app on cell phones that may be "larger" than the archos' screen size.