On Mon, 02 Nov 2015 14:07:41 +1000 Peter <[email protected]> wrote: > On 2/11/2015 12:23 PM, Carsten Haitzler wrote: > > On Mon, 02 Nov 2015 11:54:05 +1000 > > Peter<[email protected]> wrote: > > > >> On 2/11/2015 11:28 AM, Carsten Haitzler wrote: > >>> On Mon, 02 Nov 2015 11:21:47 +1000 > >>> Peter<[email protected]> wrote: > >>> > >>>> On 2/11/2015 9:41 AM, Carsten Haitzler wrote: > >>>>> On Mon, 02 Nov 2015 09:24:23 +1000 > >>>>> Peter<[email protected]> wrote: > >>>>> > >>>>>> Is there a platform independant way of obtaining a Window and > >>>>>> binding the EGL display to it without using EFL on Tizen? > >>>>>> > >>>>>> Is there a possiblity of Tizen supporting OpenKODE from Khronos > >>>>>> in the future? > >>>>> no. evas_gl replaces egl. it's done this way because there are > >>>>> so many other things you want to use the widget infrastructure > >>>>> for like indicator, kbd handling (eg sizing content to move out > >>>>> of the way of the kbd) etc. and if you use evas_gl you can merge > >>>>> both ui, widgets gl api. > >>>>> > >>>>> you simply need to change the egl parts (it's actually less work > >>>>> using elm_glview than using egl - by far) and ensure your > >>>>> rendering all happens in the render callback. > >>>>> > >>>> Carsten, > >>>> > >>>> Sounds good for creating a new application. > >>>> > >>>> I was investigating the work required to port an existing > >>>> application. > >>>> > >>>> I noticed the EGL and GLES libraries exist on the tizen platform > >>>> emulator. > >>> yes - but you can't use them if you ever want to ship/distribute > >>> your app. platform components only as they can change to move > >>> display systems. > >>> > >>>> I was thinking of writing a wrapper library, that implements > >>>> GLES2.0 around evas_gl. A Tizen application has it's own lib > >>>> directory, if I install the wrapper library into this directory, > >>>> will it be resolved instead of the system GLES libraries? > >>> i ... don't know actually. i do know that evas_gl and egl are not > >>> an exact 1:1 match and there are other things like NO > >>> swapbuffers so you structure code differently. > >>> > >>> you are best off restructuring the egl code and isolating it in a > >>> porting layer etc. > >>> > >>>> Thanks, > >>>> > >>>> Peter. > >> Thank you Carsten, > >> > >> Ignoring the display layer for a moment, the underlying system is > >> Linux, I was going to bundle an Embedded JVM with the application > >> (written in Java) using JOGL - Java Open GL bindings. > >> > >> Java has JNI which allows it to call C libraries and be invoked by > >> C code. > >> > >> It would be nice if Tizen supported Java as well, don't know if > >> there are any plans in future to do so? > > OK time to clarify a few things from a 3rd party developer > > perspective. To save you time and ensure we're on the same page: > > > > Tizen is a locked-down sandboxed OS in its reality shipped on actual > > commercially available products. It COULD have been like > > "Linux" (i.e. GNU/Linux distributions with a regular permission > > model, display system, middleware etc.) but has chosen not to be > > and diverge fairly significantly (as opposed to Android which just > > used a Linux kernel and then built an entirely different OS on > > top). I quote that "Tizen is to be as secure or more secure than > > iOS". Of course that means locking it down so only the vendor has > > control. > > > > It has moved further and further away from being Linux over time and > > Java is not supported by Tizen. There are currently no plans to do > > so. If it's not supported then it's "your job". And it's your job > > to do it within the limits set. > > > > So for an app, it's HTML5 with the Tizen web runtime or native with > > C APIs (you can use C++ too for your app - your system interface is > > C though). You use JUST the C APIs allowed and you cannot use one > > single library or function symbol more than that or your app will > > never be distributable or installable by anyone else. It'll be > > nothing more than a local toy. Apps are checked for libraries > > linked and symbols accessed from those libraries and are rejected > > at the appstore level if they use any API not documented on > > tizen.org as a public API. > > > > As a developer you get no root access on any device and devices are > > locked down to the point of needing certificate signed by the > > manufacturer (e.g. Samsung) to get permission to place applications > > (regular ones) on your own device in front of you. That certificate > > I think is valid for that device only and no others. Certificates > > are manually approved last I knew. So this doesn't get you any extra > > permissions other than permission to load app pkgs directly on the > > device you have without going through the store to do so. > > > > Oh and bootloaders only allow signed kernels - at least from the z3 > > onwards. Queue chain of trust spiel here. > > > > So if you've gotten to this point by now being able to finally run > > something on the device in front of you, you are limited only to the > > APIs above. You must port the entire JVM and it's libraries > > yourself and ensure it requires nothing beyond these APIs. Yes - > > you would have to ship that JVM embedded with your app after > > ensuring this. You could ensure that that layer uses the > > appropriate GL API sets in Tizen. > > > > If you want to do platform development and build your own Tizen > > devices and products, then you can do whatever you like - you have > > root and ship software on your device so no one can stop you. I was > > assuming for now you are aiming for "3rd party dev" as above on > > devices available commercially. > > > Thanks Carsten, > > I've looked into Tizen security and it seems simple enough, from what > I can tell network and other privileges only need to be declared in > the manifest. I'm familiar with protection domain's and least > privilege security models. > > Is there a static analysis tool available that allows me to test for > Tizen API compliance?
At this stage - not that I know of. There *SHOULD* be one in the SDK that checks binary at compile time for this, but no such thing is done at the moment. the appstore has such a script/tool and will reject things that don't comply. > Despite using a different security model, Tizen still appears to have > a lot of standard C api's that you'd expect to find on a POSIX > compliant unix? There's a lot of header files included in the Tizen > IDE that aren't explicitly documented as part of the API. At the libc level - yes. beyond that... YMMV > Is it safe to conclude that if a header file is available in the > tizen IDE's available header files, then it's part of the Tizen > public API? Apart from header files that aren't supposed be used > directly of course. No. actually. :) You'd need it documented. :) I know that there are EFL APIs you will have in headers that are part of the upstream EFL public API but Tizen does not allow them/support them. libc though - yes. ou should be fine. > Example: > #include <sys/socket.h> > > Java runs headless on the tizen emulator without privileges, although > I've got more tests to run... > > The embedded jvm would bundled with the app and be used as a library > that's invoked from C code. Sure. Your issues will be things beyond libc that may be needed by the JRE - like opengl-es/egl and others. > Regards, > > Peter. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
