I was my first on-device development on Gear S2 today and had to go through
that painful certification process.

I can confirm, though, that the e-mails for the certificates are automated
and come back almost instantly.   That's the one nice thing I have to say
about the process from a developer PoV.   That part was not too painful in
a practical sense.

Provisioning on iOS used to be even worse than that.  I hear iOS
provisioning might have been streamlined recently, because every single
developer wasted hours very frequently on this nonsense, and all iOS devs
dreaded new SDK releases and possibly having to get a new xcode, re-build
and re-sign everything and kiss goodbye to a day or two.
On Nov 1, 2015 6:23 PM, "Carsten Haitzler" <c.haitz...@samsung.com> wrote:

> On Mon, 02 Nov 2015 11:54:05 +1000
> Peter <j...@zeus.net.au> wrote:
>
> > On 2/11/2015 11:28 AM, Carsten Haitzler wrote:
> > > On Mon, 02 Nov 2015 11:21:47 +1000
> > > Peter<j...@zeus.net.au>  wrote:
> > >
> > >> On 2/11/2015 9:41 AM, Carsten Haitzler wrote:
> > >>> On Mon, 02 Nov 2015 09:24:23 +1000
> > >>> Peter<j...@zeus.net.au>   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.
> _______________________________________________
> Dev mailing list
> Dev@lists.tizen.org
> https://lists.tizen.org/listinfo/dev
>
_______________________________________________
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Reply via email to