Native-Android-discussion: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
(Convert ExpressionEngine section headers)
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=native Android=
{{Cleanup | reason=Auto-imported from ExpressionEngine.}}


There are a lot of rumors and statements around regarding <span class="caps">OEM</span> 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.
= 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.
The idea is to remove at least the Dalvik layer, maybe everything but the kernel.


==Thomas Senyk’s thoughts on that:==
== Thomas Senyk's thoughts on that: ==


===So two questions at hand are:===
=== So two questions at hand are: ===


* “Could we do a “android-<span class="caps">BSP</span> without DalvikVM”-setup and have Qt running on this?
* "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?
* "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-<span class="caps">BSP</span>s:====
==== We have some pros and cons if we use android-BSPs: ====


=====<span class="caps">PROS</span>:=====
===== 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.
# Very good OpenGL+EGL implementations <br /> … but: see “No multi-process” in cons
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


=====<span class="caps">CONS</span>:=====
===== CONS: =====


# There might be some legal/politic issues. (As with <span class="caps">ANY</span> other android approach!). Nokias should check with legal.
# There might be some legal/politic issues. (As with ANY other android approach!). Nokias should check with legal.
# officially <span class="caps">ARM</span> only (x86 also, but x86 is not a problem-child anyway)
# officially ARM only (x86 also, but x86 is not a problem-child anyway)
# '''No multi-process'''
# '''No multi-process'''
## You can’t use SurfaceFlinger (that easy) because it’s started and managed by “System Server” which is a Dalvik-process!<br /> Or in other words: SurfaceFlinger does only come with the full android-stack.
## You can't use SurfaceFlinger (that easy) because it's started and managed by "System Server" which is a Dalvik-process!
## The basic kernel-enables (e.g. <span class="caps">PMEM</span>, <span class="caps">CMA</span>) are only the first step towards a linux multi-process solution (e.g. wayland), the real work starts after that.
Or in other words: SurfaceFlinger does only come with the full android-stack.
## What’s left is basically: single-process <span class="caps">EGLFS</span> (backed-up by very good OpenGL+EGL implementations)<br /> … that was never a big problem on any device I worked on!
## 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!
# 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(!!) not real linux!
# 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 they’ve invested in android (kernel, <span class="caps">EGL</span>, OpenGL, OpenMAX,…) and build (as a their second offering) a proper <span class="caps">REAL</span> 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 <span class="caps">REAL</span> linux <span class="caps">BSP</span> … OR use the full android stack (e.g. via necessitas)
'''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===
=== 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!!!), 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-<span class="caps">BSP</span>-without-Dalvik and necessitas.
"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.
'''I don’t see much <span class="caps">PRO</span>s against necessitas! (but a lot <span class="caps">CON</span>s!!)'''
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.

Latest revision as of 16:06, 5 March 2015

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine.
Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

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:
  1. 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)

  1. Very good OpenGL+EGL implementations

… but: see "No multi-process" in cons

CONS:
  1. There might be some legal/politic issues. (As with ANY other android approach!). Nokias should check with legal.
  2. officially ARM only (x86 also, but x86 is not a problem-child anyway)
  3. No multi-process
    1. 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.

    1. 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.
    2. 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!

  1. A lot of non-standard implementations of various OS-utilities. (ashm (instead of posix shm), binder (instead of dbus), …)
  2. 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!
  3. 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.