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.
Related
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.
I have a Xoom tablet and it would be great if I could run statistical analysis using R on it. As far as I know it is not possible to use R on iPad due to license problems (GPl x iTunes etc.) and a lack of compiler for Fortran in the Apple tablet.
But what about tablets using android? Arguably, the GPL issue is not a problem, so any help here on how to use R on my tablet?
I used Linux Installer from http://android.galoula.com/en/LinuxInstall/ (my Dezire Z was rooted beforehand), installed stable debian and R! on this Linux install. I`m not a Linux-geek and total time for installation (first time loop file size was insufficient, and I repeated the whole process) wass less than hour however.
(source: gyazo.com)
At some point, smartphones and tablets will have browsers capable enough to run RStudio in its server mode via the browser. Currently, the latter demands too much in terms of newer GWT, Javascricpt, ... magic that it remains limited to (recent enough) desktop browsers; see here for a bit more on this.
You can always ssh out though. Connectbot is a capable ssh client for Android, and of course free. No graphs though.
The Android SDK offers developers the facility to program in Java, ... not C or Fortran, which are the languages in which R is written. Although some have said that hacking the Android tablets voids their warranty and prevents upgrades, Motorola only requires that the device be relocked before doing upgrades. For this question I think it still boils down to "if you have to ask the question, then you cannot do it".
EDIT: But somebody else will probably try it.
(I haven't found gcc for the Android.)
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.
Has anybody blogged about this comparison, or does anyone want to give it a shot here? Would be nice to see some reasoned thoughts on Adobe AIR on Android vs. the "native" Android SDK (in Java).
Edit: Despite few views and no answers, I'm leaving this question up here since it's a topic that needs to be covered at some point... but if it gets no attention I'll delete it in a few days.
I think it's ultimately very similar to the question of whether to use AIR or Java for a desktop application. Ultimately it comes down to three points:
Does AIR do everything you need? Obviously the android SDK gives you complete access to device capabilities, but AIR purposely doesn't, in order to stay portable. For example, AIR may not support intents, at least initially (I don't think Adobe has announced yet one way or the other). Also, AIR requires Android 2.2. If those limitations are troublesome, regular android SDK may be best.
Are you looking to make something that would be well-suited to doing in Flash? If you're planning a design-heavy app with animations, video, sound, or the like, then building it in Flash may be significantly easier than using Java. On the other hand, if your app will be pure code using only standard visual components, then it might not make a lick of difference which platform you use. Or on the gripping hand, if you'd have existing Flash animations or the like, then trying to shoehorn them into a Java app will be bothersome.
Are you targeting other platforms besides Android? If so, AIR may be a big win, as the same app content should run on windows, mac, linux, and later on, other devices that plan to support AIR, like Blackberry, some TVs, blu-ray disc players, etc. If you are only targeting Android, AIR may lose some of its appeal.
I hope that helps some. Realistically, unless you're effectively locked out of using AIR because you need something it doesn't give you, or effectively locked into using AIR because you're doing design-heavy work and you need the tooling, then I think the pros and cons of the two SDKs are largely questions of convenience. Either platform will work, so it's merely which will get you to the finish line the fastest and most reliably.
One issue to consider is compatibility with Android devices. Both fancy smart phones and cheap phones run in Android, but they don't have the same capabilities. Even if you application is simple or can be done beautifully in AIR, its relevant to mention that AIR is not compatible to all Android devices.
Some very popular devices currently sold (such as Samsung ACE and other "cheap" devices) use ArmV6 chips, and AIR or Flash are not compatible to this architectures, even when running on Android 2.2 or so.
AIR is interesting because same development works in different technologies, but consider that AIR doesn't run on "old" iPhones either, its only guarantied to work on new technology with big processors.
Check this Adobe link http://www.adobe.com/flashplatform/certified_devices/
AIR should be ruled out in your decision of technology if in your requirements you are targeting as much phones as possible, including those that are not so fancy or new.
I have experience with AIR mostly and little with Android SDK when I was building a native extension to AIR. My biggest hurdle with AIR is it's immaturity, it's bugs, and it's inconsistent behavior. Yes, you can go to the shiny page at adobe.com and see how cool is the AIR... All bright with tons of features which seems to cover all your needs. Yet, once you start building your app you'll find many ugly surprises:
Stage text in not working appropriately. link besides this bug StageText has few other bugs, like behavior in Scroller for instance.
Sound() object doesn't play the stream (it does on emulator only). link
Lack of features like AEC makes AIR useless to whole list of chat applications, as you'll will hear echo and screaming noise. link
Overloaded (and immature for mobile) Flex SDK (I hope folks at Apache will rewrite it from 0 and make it more manageable).
No H264 support on iOS devices: link (yes, I know it's Apple problem, that they want to control HD delivery on their platform, still it's Adobe problem too, as they couldn't fight right to bring their technology to forefront).
Sound object doesn't take variable bidrate (only 44.1KHz is possible). Flash "second generation" Speex codec samples at 16Khz. Now, try playing this back through Sound and you'll enjoy a funny circus. At the end you will need to write your own upsample algorithm.
I'm sure people will add more to this list. So, my answer would be native SDK is more preferable for anything serious. You won't work like a QA person with it - testing countless little examples trying to understand why an AIR feature not working, shuffling internet for answers and looking at AIR bug database... only to find that critical bugs are sitting there from release to release. That is my experience with AIR. Going native SDK makes your application not really "cross-platform", but AIR SDK can't claim this title anyway for anything more serious then couple of "Employee directory" examples. And if you will need to build for the other platform, you will just use native tools for it.
GL.
I am planning to develop a game for all of the mobile platform and have pretty much zeroed down on the concepts of the game. but the only issue I'm facing as of now is that I have no idea what would be the best libraries + 3d Engine to us to achieve the best results on the hardware on some of the upcoming mobiles. I'm talking about the iPhone 3GS, the new WinMo and Android devices with the famed Snapdragon, other processors from Samsung, ARM, Qualcomm and even Intel and AMD.
as of now i plan to use the ogre libraries for now, but then what will offer portability?? This is much more of a design question rather than just coding. Any help is appreciated, others who wish to collaborate are very much welcome too. just drop me a mail.
I don't know much about Window Mobile, but (right now) there is a barrier to compatibility between Android and the iPhone: managed vs. native code. Android highly encourages you to write in Java, whereas the iPhone requires Objective-C or C++ (or C). Though Android does have a native development kit, they don't currently expose many libraries. They will add more APIs over time, but the Android devs will continue to encourage Java development, since Dalvik bytecode will run on any new device.
This is just my opinion, but I would focus on just one platform at the start. Pick your primary platform, write your core game code in portable C++ if you can, and keep the platform-specific parts separate from your core game code. Your goal is to get your game published. Once you have some money coming in, then start focusing on your second platform's port.
I would recommend you to use OpenGL ES and STL. Both Android and iOS platforms become more compatible with OpenGL and STL library, and it looks like every other mobile platform would follow this course (except, perhaps, Windows Phone 7.)