3

I need to make an architectural decision for developing (actually porting) my embedded solution on a tablet.
The choice comes down to Ubuntu or Android, so I have some specific questions to help me decide.

  • On Android, is it possible to develop applications outside of Dalvik, using Python? If yes, can I access the hardware this way, without the API's provided by the Android SDK?

  • On Android, can I control the process' core_affinity to bind a process to a single core? And can i use isolcpus to isolate other processes from that core making it a (almost) dedicated core for a process? This is possible in regular linux, not sure if it can be done in Android.

  • On Ubuntu, how much control over the HW do I have outside Ubuntu SDK?

gnat
  • 21,442
  • 29
  • 112
  • 288
bosnjak
  • 81
  • 6
  • 1
    http://meta.programmers.stackexchange.com/questions/6483/why-was-my-question-closed-or-down-voted/6490#6490 – gnat Mar 21 '14 at 08:00
  • I have edited my questions to be more specific. Is this better? – bosnjak Mar 21 '14 at 08:05
  • 2
    as far as I can tell, your question still asks to bite too much. Regarding part asking about Android vs Ubuntu, recommended reading is: [Gorilla vs Shark](http://blog.stackoverflow.com/2011/08/gorilla-vs-shark/) -- _"if you... don’t want your question to get instantly closed... — try to keep Gorilla vs. Shark in mind."_ – gnat Mar 21 '14 at 08:26
  • 1
    @gnat, I updated the question to be more specific. Is this ok? – bosnjak Mar 21 '14 at 08:38

2 Answers2

4

Start with the proposition that an application has a user interface. How do you want that to look and behave? You have 4 choices.

  1. Android native. You're going to write Java, but you can extend it in C++ using the NDK.
  2. HTML5/Javascript. You're probably going to write Javascript, but you can extend it using a server or a wormhole.
  3. Renderer. You can write any language you like because you're going to be drawing your own widgets on a render surface, and they won't be native.
  4. Somebody's devkit. It will eventually do one of the above. Xamarin, Qpython, QT, etc. Whatever.

There is a lot to read eg (https://stackoverflow.com/questions/101754/is-there-any-way-to-run-python-on-android). None of it matters until you decide what kind of UI you want. If you want native you are going to write Java.

In answer to your questions:

  1. Yes, can write and run code, basically via the NDK or similar. Doesn't help with the UI.
  2. Dunno, but once you get down to the NDK you can do most stuff.
  3. Ubuntu is not Android. I'll leave that to others.

Regarding the NDK, I can tell you that it provides a reasonably fully-featured C++ development environment. Most (but not all) standard C++ library features are provided, as well as a set of APIs that hook into the Android process APIs (so you can write Activities entirely in C++), and a JNI capability.

There are device APIs (things like the accelerometer and GPS) that are intended to be accessed from Java, so we go via JNI. You may be able to access devices directly from C++, but I would expect you would tend to lose portability (across manufacturers) and higher level features.

Below that there are device drivers, a HAL, a Linux kernel and other interesting things. If that's where you want to play, there is plenty to read: http://s.android.com/devices/index.html.

Community
  • 1
david.pfx
  • 8,105
  • 2
  • 21
  • 44
  • Thank you for the answer. However, the GUI is actually the least of my worries. I can go with any option for GUI, and it most likely won't matter since it will be a separated concert, wheather I do it in HTML5, Qt, Kivy or others, in all cases my logic will have to go somewhere else if I want to do low level stuff that I plan. Also, I know NDK has lots of low level stuff, but I need someone with real practical experience to explain what *actually can* be done. As far as I can see, NDK is not really designed for complete development, rather the *busy* and *intensive* parts of a higher level app – bosnjak Mar 24 '14 at 09:40
  • Also, your answer on Python doesn't really ease my main concern - the hardware access from Python. No one seems to talk about that much, everyone is discussing the GUI. I guess that's the mainstream, but for embedded projects its not really. – bosnjak Mar 24 '14 at 09:43
  • Sounds like you're in the same space as an OEM or driver writer. See edit and link. – david.pfx Mar 24 '14 at 13:41
  • I suppose that for native UI you don't need _all_ the code to be in Java, only the UI-handling part. The rest can be in any reasonable JVM language (Clojure, Jython, etc). – 9000 Mar 27 '14 at 05:00
  • Android _not_ a general-purpose computing platform. It is designed with mobile devices in mind. Such devices have very constrained energy budget. If your app wants to play nice with the rest of the device, you better use the API. Hardware may be actively power-managed, so in best case a non-conforming app would drain the battery, in worst case it might see 'malfunctioning' hardware that the OS just sent to sleep. – 9000 Mar 27 '14 at 05:08
0

If the device in question is a custom or generic tablet on a conventional platform (x86, ARM...), then ask yourself what do you need exactly from it. Do you really need a whole Ubuntu distribution, or will the tablet boot directly into your application? In that case I would go for a basic embedded linux distribution that will take care of your hardware and a QT interface. If the device is running Android then you need to use the appropriate toolkit and API for Android OS. You could also go with a full blown Ubuntu and just develop a web app. In that case all you need is a web browser and you can run it on virtually any tablet, phone, or PC.

Drunken Code Monkey
  • 109
  • 4
  • 1
    Thanks for the advice, but the question remans, what would be a *basic embedded linux distribution* in this case? Any Linux i would want to use (Arch, Debian, ...) would need to be ported for the specific device. Sure, I can build it for ARM and run it, but would I have access to all the hardware? I don't think so out of the box. I'm afraid that this approach, although probably the best, would still require too much effort on my side, so it may not be optimal. Do you have any suggestions on this? – bosnjak Mar 27 '14 at 06:56
  • Of course your linux of choice will have to be built specifically for your hardware. Of course you will need a cross compiler and some time to get your toolchain going like you want it. You will need to put some elbow grease in it. If that is not what you want, then maybe you are better off with an off the shelf tablet with known and supported tools and hardware. – Drunken Code Monkey Mar 27 '14 at 13:15
  • I would also like to point out that we still do not have clear requirements of what you need exactly. I'm sure if you would specify what hardware EXACTLY you need to have access to, in what context the app will be used, and other slightly less general details, we would have a lot of better answers. Maybe Linux or Android isn't what you need at all. Maybe you can do everything you need through a web app. Then again maybe not, but we can't guess. – Drunken Code Monkey Mar 27 '14 at 13:18
  • Well, i tried to explain my requirements a bit more, but I was warned about the question being too broad. You can read my first revision here: http://programmers.stackexchange.com/revisions/233152/1 It explains my requirements in more details. I think that revision was better, but I had to change it and trim it down or get closed. – bosnjak Mar 27 '14 at 13:29
  • Ah well your original post was much better if you ask me. In any case, what you require you will definitely have under whatever linux distribution you end up using. I guess what you really need to do is make sure all the hardware you have on the physical tablet is actually supported by the linux kernel and ported to ARM. Once you have a bootable kernel with working support for all your hardware, you just write a normal all and go through the drivers/APIs you need. For sound you will likely go through ALSA, for 3g and gsm you will go through whatever driver is available for your particular chip – Drunken Code Monkey Mar 27 '14 at 13:53
  • However, these two requirements go against using a custom tablet running linux: - Mainstream solution to ensure reliability - Future-proof: minimize the porting effort for new tablets and HW In that case, I would choose an off the shelf device and stick with it as it is. You cannot future proof it, if the hardware changes, at least some of the drivers and APIs will too. You will likely have to rewrite parts of your app for a different platform. – Drunken Code Monkey Mar 27 '14 at 13:54
  • Rewriting parts of my own app is ok, as long as its not digging into drivers and kernel. User space changes for porting are hardly evaded. Anyway, I like the idea of using an off the shelf device - that would be best for me. It is what i intentionally wanted to do. But the question is, does Android/Ubuntu/AnyOther platform provide the means to do what I want in software? For example, Android applications are in a sandbox, and its not likely they support cpu_affinity and other neat features... I need to weigh the pros and cons, but I don't know them. This is the reason i ask in the first place. – bosnjak Mar 27 '14 at 14:12
  • Just define exactly what you will need that you think might be restricted by the OS, and then just do some reasearch. For example I highly doubt any off the shelf tablet will let you do whatever you want with the 3G or GSM connections. But maybe some will. The only way to know is to test it, or ask someone who has. – Drunken Code Monkey Mar 27 '14 at 15:13
  • Thats what I'm doing here, asking :) – bosnjak Mar 27 '14 at 15:28
  • Google is usually great to look at **before** asking... – Drunken Code Monkey Mar 27 '14 at 16:30
  • Of course I have searched Google, the problem is not that there aren't any information, there are alot of information, but not specific enough for me to make a decision. Asking here was expecting that someone who has real experience with this can give more insight. But I can see from your POV that your hint is in place. – bosnjak Mar 27 '14 at 19:31