I'm hoping it ends up serving as a drop-in replacement for Android Wear that provides more standalone features. I know hardware is the limiting factor too, but it seems we are getting there.
As a really casual smartphone user, I think I'd be much better served by a smartwatch. Most of the time, I'm next to a computer. So I never use phone browsing capabilities. Also I never make calls out of my office. Thus, I'd love to have a standalone smartwatch that tracks my heartrate & activity, offers some maps & navigation and allows for emergency calls and SMS without the need for a smartphone. I don't want to carry one, and I think I'm not alone. They distract me.
Check out the variety of standalone smart watches coming out of China now, some even run full Android 5. I'm thinking of one which could act as a 3G-to-wifi hotspot for a tablet for when I do need to work on the go. That also gives much more flexibility in selecting a tablet without a SIM.
Then we constantly have the same issues working with the display. We output ARGB for an augmented reality product, but Android is not designed to output anything but RGB to the final LCD. So similarly, if we were just dealing with a Linux frame buffer, we'd have had a much easier time doing the customization than fighting all of Android's various SurfaceFlinger and other layers between the app and the display.
Maybe for your type of work it looks different, but from app developer perspective, they could replace the kernel with something totally different, keep the constrained set of official NDK libraries and no one would notice the kernel wasn't Linux any longer.
And there is no way to know this in advance (beside checking if symbols are defined on a specific device)
Even if you could overcome that, you would still need to make your own companion app for the phone and framework, since all that is Samsung proprietary too.
That's exactly why I'm the sole mantainer of Gear 2 & Gear S Android Wear ports...
IMHO it would be easier to clean up AOSP and make an open variant of Android Wear, rather than reimplement it all from scratch, but who doesn't like a challenge! At least they can use some parts of Nemo/Sailfish OS
Granted, I haven't tried Tizen. But I AM using a Samsung device at the moment and let me state it as clear as possible: Samsung is the worst, the absolute worst, phone manufacturer in my frequently changing usage. I wouldn't trust Samsung with anything.
Incidentally I've been at a Samsung HQ (not phone related, printers) a while back and the manager in charge stated something like "We're great at hardware, we suck at support". I had a hard time keeping a straight face.
Honestly: There's no phone company that is worse than Samsung. I am not convinced that Tizen can fix that.
(I have a S6E right now and I constantly want to throw it against various obstacles)
Samsung's policies on their devices have nothing to do with how another company might deploy Tizen.
I'd argue that Maemo/Meego were that system, but I already admitted to know really not a lot about Tizen.
You might be perfectly correct. I wouldn't want to touch anything (Software. Hardware is a different story) made by Samsung with a 10 foot pole and cannot imagine that Samsung would be great as upstream, however you plan to deploy the software.
Again, apologies. My beef is with every piece of Software Samsung published around me, not with you, your opinion or Tizen. I'm extrapolating and generalizing and obviously have a gripe here..
Are you aware that since Samsung got their hands on Meego, Tizen already went through three SDKs and userspace re-rewrites?
- First it was just Meego Qt SDK renamed for Tizen
- Samsung then replced it with the SDK from their BADA OS, a ugly Symbian influenced variant, including the same Symbian C++ patterns.
- Now it is based on the Enlightenment Foundation Libraries and C, with a C++ wrapper library
But this is only for the hardware where developers are allowed to write native apps, as what Samsung is usually pushing for is their Web app approach.
For example for TVs you need a special contract to deploy native apps.
I'm not saying Tizen is popular; on the contrary, I was trying to say that it has a reputation as a pointless also-ran Android clone. But past that prejudice, it's actually a competent Linux platform for embedded systems.
- Not Google
- More hackable
- Qt + QML
looks really cool to me. Android is decidedly not the be-all-end-all of mobile OSes, and an alternative project is always nice.
Reusing some low level code does not an Android make.