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.
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.
Is Way To Run Machine Code Instead Android OS In Android Devices ?
I Want Remove Android Os And Work With Cpu And Other Devices Directly .
What Compiler I Can Use ?
MASM is an x86 assembler, so it would not be suitable for most Android devices as the vast majority use ARM-based processors.
That said, Android phones are computers just like any other and can be programmed in assembly. The first thing you'll need to do is select a device running a well documented CPU and chipset.
Since you'll be removing Android and plan on programming in assembly you'll need to write your own routines for nearly everything. An understanding of the CPU, power management and some form of I/O (you can avoid having to write complex display code if you plan to interface with the phone through serial communication, for example).
Unfortunately, much of the information required for successfully writing your own OS for an Android device is unavailable so you'll need some hardware analysis tools to assist in reverse engineering some of this information. A logic analyzer may be useful in sniffing some of the protocols used between chips, although much of modern phones is done on a single SoC, so you'll need to experiment heavily and compile information from a wide variety of online sources.
Aside from that, it's smooth sailing. Programming an OS in assembly for Android is pretty much the same as programming an OS in assembly for any other computer and you'll find it to be rather familiar territory.
I need to make an architectural decision for developing (actually porting) my embedded solution.
I will try to present my case as clearly as possible, and any advice I can get will be appreciated.
Introduction
I have an embedded system, currently developed on ARM11 architecture and ArchLinux OS. It is implemented using all kinds of technologies available under Linux, including C, C++, Bash and Python.
At this time, I would like to port my solution to a tablet, so I am trying to make some decisions about the architecture, based on the requirements of my system.
Requirements
The system is modular, and it runs multiple processes and threads. It also communicates to remote servers and controls the hardware peripherals. These are the basic requirements, at the moment, I will update as discussion develops:
Primary:
Dedicated system (minimum amount of other applications running, even in the bg)
Multiple processes, ability to set priorities
Ability to assign a process to a single CPU Core (cpu affinity)
Inter-process communication mechanisms
Complete hardware control (WiFi, 3G, GSM, mic, speaker, display, ...)
Creating sockets, etc.
Other:
Ability to connect a microphone directly to a 3.5mm plug (TRRS connector)
Mainstream solution to ensure reliability
Future-proof: minimize the porting effort for new tablets and HW
My questions
What tablet and OS combination would meet these requirements?
How to approach the "dedicated solution" requirement?
How to approach the software development, what language and tools to use?
My investigation so far
My investigation so far has been concentrated on the OS choice. The main options seem to be Android and Ubuntu Touch. Here are my thoughts:
Android
Android wins in the mainstream category obviously, but...
I have no experience of Android development, but as far as I can tell, I can either develop a Java application that runs on top of Dalvik, or I can go native via Android NDK. Maybe I can even bypass the whole thing and go native side-by-side of Dalvik, and develop in Python? I guess then I will lose the access to the API for HW access. Not sure how I would access the HW then. But if I go with Java development, this is a sandbox solution, and I am not sure if I can have such a control over the processes, HW and CPU core affinity?
Ubuntu Touch
Developing on Ubuntu Touch would be more like Linux development I am used to, since it uses Qt. The issue here is that the applications are developed using the SDK that restricts me to HTML5 and QML, which I'm not sure can allow me the same control over the system I need. If I use Python and avoid the SDK, same issue arises - how do I control the HW? Of course, there is a way to do it like on a regular embedded system I guess, but I don't want to reinvent the wheel if I don't have to.
Also, it seems that Ubuntu Touch hasn't been ported to many devices yet, only a handful of them are supported.
Finally
I am not sure how well I have presented my case, but I will update the question as needed with further explanations and requirement details. Thank you for your patience, your time and any help you may offer.
I am in the same boat as you, we are developing embedded system on ARM CPU. Currently the system is written in Python on custom built linux distro from hardware vendor.
We have been looking at Android and Ubuntu Touch for a few months. So far we didn't get any decision yet. But here what we found out from our incomplete analysis:
Android is quite heavy system, that also brings JVM into the mix. So you HW and memory requirements will significantly increase.
Android likes to take over the entire system, so sometimes you might be fighting with Android.
Android has very good IPC mechanisms, not available on mainstream linux kernel, such as Binder. Of course you can port it to another system. But this would be considerable effort.
Android has very rich GUI interface, also with things like NDK view you are not confined into the JDK box.
Android doesn't use standard GNU C library, it uses something called BioniC which is a port of C library from BSD. Usually it is not a problem for most software, but if you are using some linux specific low level features, like working with serial ports you will need to tweak your code. See what I had to do to port Java RXTX library to android https://github.com/vladistan/gnu.io.android
You can find a lot of Android developers out there who will do basic GUI programming for you, while you are concentrating on your app specific stuff. Interfacing between GUI and low level things is quite easy using binder. And of course you can bring in whatever mecahnism you want via NDK.
We have considered Ubuntu Touch. But so far it doesn't seem to be mature enough.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
What advantages would a real time operating system like QNX bring to the smart phone / tablet space vs what android and iOS are doing.
Is really going to be more reliable and secure and at the same time providing great performance and security?
Thanks
It's very hard to figure out exactly what RIM is saying when they mean "QNX". Yes, they bought QNX Software from Harmon-Kardon, but it's not like a QNX was selling a tablet OS out of the box.
QNX provides various components for the customers, including but not limited too:
QNX Neutrino RTOS -- a microkernel (with a few variations) that runs on x86/ARM/PPC/etc. The normal development kit for this comes with the RTOS, all the standard UNIX/Posix utilities, a Windows or Linux IDE based on Eclipse, and a GNU toolchain. You can buy it, and bring up embedded platforms and write C/C++ code to your heart's content.
On top of that, QNX provides various packages that provide other features. They've got Photon, a X11-like windowing toolkit to make GUI apps, but it's really limited to making old-school UNIX apps. They've got a Core graphics toolkit which allows for low-level OpenGL accelerated graphics. They've got some Flash-running compositing toolkits for general purpose UI stuff. Then, on top of that, they've got some toolkits and packages aimed at cars.
So now, when RIM says "We're using QNX", it's unclear about what they're using. The kernel, sure, a lot of the underlying OS, sure, but the entire User Interface doesn't really match up to anything that QNX has publicly provided to date. I consider that part of the system the most critical for user buy-in. Comparing the details of the iOS kernel vs the Neutrino kernel, while interesting to some, is mostly irrelevant to the product itself.
I think that discussion is touching just some very high level capabilities of QNX.
Some of important things:
This system is very mature from all points of view. It doesn’t have issues on kernel level and uses completely different architecture vs. Linux.
One thing is that you don’t need to rebuild kernel if you change something on drivers level or something like that.
System is much more stable and doesn’t have crashes on kernel level.
You don’t need to take tricky procedures to balance multi threads solutions as it is in Linux.
You have fault tolerant system by default and other things. Just read QNX capabilities in white papers.
UI and Applications part for Mobile devices (smart phones, tablets) still be architect and implemented but it tem of time only.
System is really scalable from single chip microcontroller up to Cisco variant and full Airport Control System 24/7 (London )
Linux CANNOT be scaled this way at all.
So will see next two years...
QNX has made their first attempt to enter in Tablet Market which I believe is not bad. But they have always been a pioneers in developing support systems for any hardware like emended systems on aircraft Industry (including F-16), auto-mobiles and other industries.
I have used Playbook, I believe its wonderful, touch is amazing better than apple specially with all-side touch swap option leave no room for buttons. Its microkernel architecture protects every application, driver, file system, and protocol stack in the safety of memory-protected user space. As a result, multiple third-party applications can run simultaneously on the RTOS without corrupting one another or the RTOS itself.Furthermore, its will be like first Multi-core / Multi Tasking Tablet and the best part is that Now Android app's can also be installed and run on Playbook.
QNX is quite a bit heavier than Android IMO, so it will take something along the lines of the HTC Vision (TMobile G2) to get it running smoothly with modern software.
Funny enough, one of the airlines I worked for in the early 2000s ran their pilot training flight simulator, which had a complete 2 seat cockpit with QNX and an ancient 386 + coprocessor. Most smart phones would kill that machine.
I am going to develop a handheld device which has an Atom processor. I am thinking of using Android embedded OS for running telecom applications on this device. I have heard from my friends that Android is good for wireless applications. But my device does not need any wireless application. I will need only data (ping, traceroute...), IPTV and VoIP applications to run on this device. So is it advisable to use Android for my device?
In my opinion the biggest benefit you get from running a OS like Android as opposed to a tailored Linux distribution are:
An application ecosystem, that integrates well
A UI environment suitable for small screens
An Application SDK that makes developing new apps pretty straightforward
Drawbacks of using Android IMHO:
No standard libc. That means you will have to do some porting, to get mplayer or something similar to play your media content
Way less libraries than you have, when you use a "regular" Linux distribution
You can only create apps with UIs using Java (well there are other possibilities but you probably wouldn't do it)
It comes down to choosing what hurts less. My estimate if you have powerful hardware and a big screen (the combination of Atom and IPTV sounds like that) than using a LFS (Linux From Scratch), Ubuntu or something similar and create a flashy UI on top of that (using QT, OpenGL, GTK, Swing, ...) is less pain than porting your libs & apps to Android.
Of course you loose the sexy Android label which decreases probability of making it to Engadget :-)
Have fun tinkering!
Android uses a Linux kernel, and is designed to support Java applications. So perhaps you need to consider whether Linux and Java are suited to your application. You may be better off with a straight Linux kernel.