Meizu provides FlymeOs with Android 6.x to non Meizu devices!

As I have been informed by XDA, there are devices of other brands, like Lenovo, Nexus, Oneplus etc that can install the official FlymeOs 6 Rom from here: http://www.flyme.cn/firmware.html

All is good till here, but the most annoying part is that these Roms are based on Android 6.x, as you can see here from this Zuk Z1 photo.

So, from one side you have Meizu devices that receive Roms only with Android 5.1 and on the other side there are non-Meizu devices with official FlymeOs roms with Android 6.x

It’s really frustrating.

alt text

last edited by viper

This ROMs are not provided by Meizu but capable users who can use source here:
https://github.com/flymeos

No it’s wrong!
If you go on the page of firmware download you find the name of developer.
http://www.flyme.cn/firmwarelist-51.html#7 (use google translate)
In this case (Xiaomi Red Mi Mote 3) you can se 2 different versions as two developers toasted 2 different ROM.
Developers have nothing to do with Meizu, but they are users as me and you.
If you are able, you can compile your own rom; check here:
http://forum.flymeos.com/thread-7714-1-1.html

Still, why there are Roms for non Meizu devices and not for our devices?
If one developer can do it for one device, why he cannot prepare another Rom for us?

@viper said in Meizu provides FlymeOs with Android 6.x to non Meizu devices!:

Still, why there are Roms for non Meizu devices and not for our devices?
If one developer can do it for one device, why he cannot prepare another Rom for us?

I don’t know the technical implication, but I think that some part of drivers are not opensource. When I tried AOSP rom for Pro 5 fingerprints don’t works.

Admin

Entirely correct.
As long as some drivers are hard coded and undisclosed by their source its technically not possible to use them in a newer rom. I once had a talk with HondaRacer (ex-founder), who said that this was the failing part at Meizu.

The only way to solve this issue is to reverse engineer the drivers like faust93 did in CM14.1 for the Pro 5. He created his own fingerprint driver based upon a legacy one, if I am not mistaken.

In my opinion Meizu shouldn’t have used “liberal” suppliers like Samsung combined with ones created closed source drivers only as seen with the audio chip used in the Pro 5.

Some might think:
“Why doesn’t Meizu just reverse engineer their drivers?”

The answer is simple and frustrating: Because they can’t.

Reverse engineering is a relatively complex task depending on what you are trying to do. Just yesterday for instance I had to reverse engineer a part of my cars ECU software, so I could read out the PIN over my tool (was possible to flash the EEPROM). Alone this task took me around 2-3h as I was inexperienced with this.

In Meizu’s case it could be familiar. Developers might know what is inside their Flyme code, but trying to understand something you didn’t created is a hard task, especially in relation to drivers which are fairly the hardest thing you can code (see ReactOS Project as a reference).

Meizu m3s

The first developer, haohao3344, is part of the meizu firmware development team. I could not find anything about the second developer but his works seems to be discontinued.

So all models of Meizu (M1 Note, M2 etc) have the same problem with drivers?
Some of these models don’t have fingerprint scanners for example.
It’s not easier for these models to find the requested drivers?

Admin

The problem with these devices is the MTK chipset. Some of them might perform even worse when upgrading their base version.

At this point MTK has been a disaster for Meizu as MediaTek doesn’t provides source code.

However, due to the “little investment” of several hundred of millions, Meizu doesn’t cares about it.

last edited by Rey

The problem with these devices is the MTK chipset. Some of them might perform even worse when upgrading their base version.

Hi, no the mediatek SoCs are not an issue, mediatek devices I played with, mostly mt675x with 3.10 LP-alps / 3.10 MM-alps / 3.18-MM&N-alps branches, they all perform better or at least as good as previously and I can tell you O-preview-2 is blazing fast compared to stock flyme, it’s even ahead of a well-optimised lineage-14.1 rom (and O is still ~a preview~), mediatek only releases “template devices”, then SKU & vendors have to make a “commercial product” out of it, adding additional peripherals to the main device (selecting components, capabilities).
SKU & vendors buy licences from mediatek and have to buy new ones for newer alps (LP => MM is not free, I know, it’s discutable but hey).
Up 'til now, mt675x will have N alps and prolly O-alps due to popular demands (mostly the biggest companies using mtk : htc/sony/lenovo, etc…)

At this point MTK has been a disaster for Meizu as MediaTek doesn’t provides source code.
I’m just trying to raise awareness that MediaTek is not the problem here, but morely likely middlemen like 3rd-party peripherals : lack of support for out-of-tree / non-mediatek drivers, can’t be attributed to mediatek nor the linux kernel.
The linux kernel has simple rules and the world would be a better place if they were followed, yet there’s not enough resources to include/merge-in every “fancy drivers” small electronics company never care to maintain. Imagine if linux had every LCM drivers, every sensors ones; etc…
Mediatek have working branches for 3.10/3.18/4.x kernels, they are actually doing their job at providing “updates”.
When it comes to smaller companies for X or Y drivers/hardware, most of the time, business world works like “you get what you pay for”, Meizu is big enough to pay for updates so this mostly sounds like an “small economy” or “contract terms” issue.

As an amateur, when those small companies don’t provide updates, I can tell you from experience you can easily contact them, explain your case and get help from them and get datasheets / spreadsheets and a lot of informations, far enough to dev your own drivers from scratch, be it that you are resourceful enough to gather infos online (here’s an example I contributed to, thanks to himax for the docs : https://github.com/MediatekAndroidDevelopers/android_kernel_ulefone_metal/commit/c5504bf8e223327b779e420ea7265b5eb17626b3 ).
And we’re talking about young/student people, with few resources and knowledge, who did it. I wonder what a real company with experienced engineers (from most domains : electronic / IT / CS / etc…) could possibly do :P

However, due to the “little investment” of several hundred of millions, Meizu doesn’t cares about it.
This is mostly why they don’t care about updating old devices, they don’t risk anything and they sell “en masse” and releases newer devices each time they can cut prices on the production line (the various Mx (note) with mt6735/mt6753 or mt6755 socs).
Meizu M2 Note: mt6753 - kernel sources are 3.10 LP0.alps.
Meizu M5s : mt6753 - kernel sources are 3.18 MM1.alps.
the only differences between those two phones are the “3rd parties drivers”, but you can clearly see that if Meizu released 2 devices with the same SoCs over different alps sources, they had to acquire (the newer MM) alps. So meizu have sources from mediatek for mt6753.
I’m pretty sure the biggest problem here is that it’s not a good investment to spend man-hours and port the m2 note 3.10 to a 3.18 sources and bring MM to older devices. (and what it involves if they can’t get oem updates, RE their drivers, etc.).
And due to how mediatek alps sources work, and how meizu handles their release, most of meizu’s customised blobs (mtkcam and audio Hals mostly) are mostly generic across devices (if meizu uses mtk alps, they have their custom code live in /vendor/meizu ) (not to mention for example, meizu’s “hifi” audio thingy is just ported from exynos to mediatek sources, that’s inter-platform compatible).
Meizu just want quick profit, and mediatek is sold as “cheap” (pardon the pun). There’s still (like every new “market”) a few bad apples, because smaller companies released N for mt6753 / mt6755 and mt6752/mt6797 also is coming. (vernee, umi, elephone amongst others)

At this point, non-savvy phone-maker companies have been a disaster for Mediatek ;) (and that includes fishy economical decisions to hire small companies without contracting for updates, or shipping “precompiled” .a drivers in some kernels even when other vendor released the sources of the same exact drivers (looking at you, Ulefone p9000 and your .a lsm6ds3 driver, kappa), or blaming mediatek for a “no-release policy” when mediatek strongly encourage about respecting the GPL licence of the gnu/linux kernel : looking at you Umi…)

Sorry for the long post, I’m not trying to bring a conflict over who’s faulty, but it appears to me that meizu is just trying to cash-in passively on their mediatek devices lines, they also quickly turned their vests about mediatek or they forgot about their hugely increased visibility and benefited (both in $ and in making a name as a “quality” brand) when they released one of their first “flagship” (the mx4) with a mt6592 soc and also offering ubuntu touch and making open-source promises.

As a last argument, I brought LP (cm-12.1) / MM (cm-13.0) / NG (cm-14.0 & los-14.1) and OC (aosp-o-preview2) on my Meizu M2 Note and most of the roadblocks are meizu’s own customisation (mtkcam have meizu code, audio hals too) but they also extended their modifications and planted stems everywhere in the kernel(s) (which in definitive makes it close to impossible to rebase m2 note’s kernel to a newer kernel sources or a cleaner one like aosp-common/3.10 branch).
And I still haven’t talked about the fact they released Flyme 4.5 sources-based kernel-source (github/meizuosc only have outdated flyme 4.5 kernel sources) when Flyme 5.x was already “available and installed” on almost all of their devices.
Which means they are breaking the GPLv2 licence, for all of their hosted repositories, and not letting “indy devs” like me, have their newer updates/fixes (which also means I can’t use their latest blobs from flyme 5.x / 6.x) because the kernel imgsensor drivers are not updated and litteraly hardcrash the device board.

I’ll stop here or else I’ll spend the day listing to Meizu’s poor decisions and implementations. I do still acknowledge they did some good devices and coded some quite robust and well-working drivers (I think Weng Pingbo is to thank here, for the kernel-side gestures / flipflap cover drivers, that are still working on android 7.x/8.x)

Greetings :)

Looks like your connection to Meizufans was lost, please wait while we try to reconnect.