Native-Android-discussion: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
h1. native Android | |||
There are a lot of rumors and statements around regarding | There are a lot of rumors and statements around regarding OEM mainly (only?) supporting Android for there chipsets now/in the future.<br />There is an idea in the room regarding how we can leverage that without having to have Java/Dalvik. | ||
The idea is to remove at least the Dalvik layer, maybe everything but the kernel. | The idea is to remove at least the Dalvik layer, maybe everything but the kernel. | ||
==Thomas | == Thomas Senyk's thoughts on that: == | ||
===So two questions at hand are:=== | === So two questions at hand are: === | ||
* | * "Could we do a "android-BSP without DalvikVM&quot;-setup and have Qt running on this?" | ||
* | * "Would this reduce the amount of work when porting to an new board?" | ||
====What we need/want:==== | ==== What we need/want: ==== | ||
* multi-process including opengl-painting | * multi-process including opengl-painting | ||
* multimedia playback; using QtMultimediaKit if possible | * multimedia playback; using QtMultimediaKit if possible | ||
====We have some pros and cons if we use android- | ==== We have some pros and cons if we use android-BSPs: ==== | ||
===== | ===== PROS: ===== | ||
# Standardized media-playback (OpenMAX AL) from android-14 (4.0) and forward.<br /> There is already a OpenMAX_AL-QtMultimediaKit implementation for symbian (could serve as a base/start for a linux/android implementation) | # Standardized media-playback (OpenMAX AL) from android-14 (4.0) and forward.<br />There is already a OpenMAX_AL-QtMultimediaKit implementation for symbian (could serve as a base/start for a linux/android implementation) | ||
# Very good OpenGL+EGL implementations <br /> … but: see | # Very good OpenGL+EGL implementations<br />… but: see "No multi-process&quot; in cons | ||
===== | ===== CONS: ===== | ||
# There might be some legal/politic issues. (As with | # There might be some legal/politic issues. (As with ANY other android approach!). Nokias should check with legal. | ||
# officially | # officially ARM only (x86 also, but x86 is not a problem-child anyway) | ||
# '''No multi-process''' | # '''No multi-process''' | ||
## You | ## You can't use SurfaceFlinger (that easy) because it's started and managed by "System Server&quot; which is a Dalvik-process!<br />Or in other words: SurfaceFlinger does only come with the full android-stack. | ||
## The basic kernel-enables (e.g. | ## The basic kernel-enables (e.g. PMEM, CMA) are only the first step towards a linux multi-process solution (e.g. wayland), the real work starts after that. | ||
## | ## What's left is basically: single-process EGLFS (backed-up by very good OpenGL+EGL implementations)<br />… that was never a big problem on any device I worked on! | ||
# A lot of non-standard implementations of various OS-utilities. (ashm (instead of posix shm), binder (instead of dbus), …) | # A lot of non-standard implementations of various OS-utilities. (ashm (instead of posix shm), binder (instead of dbus), …) | ||
# | # It's all just a big hack where you (Qt) would stand in the middle of things. It's not really android and it's definitely([[Image:|Image:]]) not real linux! | ||
# You will need a lot of special solutions for special problems. You have to maintain those! | # You will need a lot of special solutions for special problems. You have to maintain those! | ||
'''This means: you are building yet another setup/platform in which nobody is interested in.'''<br /> If you want to give Chipset-Vendors a recommendation: They should use the work | '''This means: you are building yet another setup/platform in which nobody is interested in.'''<br />If you want to give Chipset-Vendors a recommendation: They should use the work they've invested in android (kernel, EGL, OpenGL, OpenMAX,…) and build (as a their second offering) a proper REAL linux instead of playing around and doing something which has no name and no future!<br />If you want to give Produkt-developers a recommendation: Either insist on a proper REAL linux BSP … OR use the full android stack (e.g. via necessitas) | ||
===Android with dalvik. Qt without Java=== | === Android with dalvik. Qt without Java === | ||
"Can we do a Qt port on a full android-stack, but only using the android-ndk and no Java?"<br />This would mean that everything is started and managed in the usual way (full android-stack[[Image:|Image:]]!), including a lot of Dalvik-processes.<br />But Qt(-Applications) would only use the android-ndk.<br />Performance and foot-print vice this will be something between android-BSP-without-Dalvik and necessitas. | |||
Revision as of 09:53, 24 February 2015
h1. native Android
There are a lot of rumors and statements around regarding OEM mainly (only?) supporting Android for there chipsets now/in the future.
There is an idea in the room regarding how we can leverage that without having to have Java/Dalvik.
The idea is to remove at least the Dalvik layer, maybe everything but the kernel.
Thomas Senyk's thoughts on that:
So two questions at hand are:
- "Could we do a "android-BSP without DalvikVM"-setup and have Qt running on this?"
- "Would this reduce the amount of work when porting to an new board?"
What we need/want:
- multi-process including opengl-painting
- multimedia playback; using QtMultimediaKit if possible
We have some pros and cons if we use android-BSPs:
PROS:
- Standardized media-playback (OpenMAX AL) from android-14 (4.0) and forward.
There is already a OpenMAX_AL-QtMultimediaKit implementation for symbian (could serve as a base/start for a linux/android implementation) - Very good OpenGL+EGL implementations
… but: see "No multi-process" in cons
CONS:
- There might be some legal/politic issues. (As with ANY other android approach!). Nokias should check with legal.
- officially ARM only (x86 also, but x86 is not a problem-child anyway)
- No multi-process
- You can't use SurfaceFlinger (that easy) because it's started and managed by "System Server" which is a Dalvik-process!
Or in other words: SurfaceFlinger does only come with the full android-stack. - The basic kernel-enables (e.g. PMEM, CMA) are only the first step towards a linux multi-process solution (e.g. wayland), the real work starts after that.
- What's left is basically: single-process EGLFS (backed-up by very good OpenGL+EGL implementations)
… that was never a big problem on any device I worked on!
- You can't use SurfaceFlinger (that easy) because it's started and managed by "System Server" which is a Dalvik-process!
- A lot of non-standard implementations of various OS-utilities. (ashm (instead of posix shm), binder (instead of dbus), …)
- It's all just a big hack where you (Qt) would stand in the middle of things. It's not really android and it's definitely([[Image:|Image:]]) not real linux!
- You will need a lot of special solutions for special problems. You have to maintain those!
This means: you are building yet another setup/platform in which nobody is interested in.
If you want to give Chipset-Vendors a recommendation: They should use the work they've invested in android (kernel, EGL, OpenGL, OpenMAX,…) and build (as a their second offering) a proper REAL linux instead of playing around and doing something which has no name and no future!
If you want to give Produkt-developers a recommendation: Either insist on a proper REAL linux BSP … OR use the full android stack (e.g. via necessitas)
Android with dalvik. Qt without Java
"Can we do a Qt port on a full android-stack, but only using the android-ndk and no Java?"
This would mean that everything is started and managed in the usual way (full android-stack[[Image:|Image:]]!), including a lot of Dalvik-processes.
But Qt(-Applications) would only use the android-ndk.
Performance and foot-print vice this will be something between android-BSP-without-Dalvik and necessitas.