Database Info

Is there a true Open Source Android phone? (drivers)

The current situation with the Dream and missing drivers have made me think about the importance of open drivers also for embedded devices like phones. Anyone using the combo Ati card + a distro that upgrades Xorg or kernel more often than Debian stable (whics is most of them) have felt the urge to curse closed source drivers to the deepest levels of hell. Now the same **** hits the fans for G1 owners.
Even though tis post is not about Ati, I must say in their defense that they have released specs, which is great.
Qualomm however, has not released anything whatsoever when it comes to source or specs, as far as I can understand. I have been stalking enough development efforts on embedded devices to know that this is common practise from hardware vendors - and extremely annoying for any geek wanting to do some heavy development for them.
And now i finally reach the question, which has already been mentioned in the title: Is there any device, released or upcoming, that features a SoC with opensourced drivers and firmware for all components? If not (and guess it is so, unfortunately), is anyone better than the others?

Of the many phones/MIDs/ARM gadgets I evaluated before I got my Vogue, the only ones I saw that had even remotely open OpenGL drivers were based on TI's OMAP3 SoC or had a PowerVR SGX GPU. Unfortunately, none of the OMAP3/PowerVR devices I saw were cheap (OpenPandora, AI Touchbook, BeagleBoard, Nokia N900, etc.) enough for me. That, and I saw what happened with the TouchBook's OpenGL ES library, which apparently wasn't allowed to be distributed outside of TI's SDK - but I haven't been following that. I also saw that the Samsung S3C6410, used in the cheap made-in-China SmartQ5 and Q7 MIDs, has open enough specs for writing a driver, but no one has stepped up to write one yet. Aside from OpenGL, though, an OMAP3/4 based phone would be perfectly open... except there aren't many consumer OMAP3 phones I really wish reverse-engineering or converting the Qualcomm/ATI libhgl.so for "real" Linux wasn't next to impossible/illegal - if doing it was easy, you'd have an OpenGL ES library for Debian on the Dream by now. I would reverse engineer it if I had the resources, unfortunately I'm unsure how legal it would be to do that.
EDIT: as far as phones (as opposed to the non-phones I was talking about), the most open right now seems to be Qualcomm - not counting Marvell PXA or other feature-poor (opposite of feature-rich ) SoCs - as contradictory as that may seem. If you haven't guessed by now, I'm basing everything on OpenGL drivers, since as far as other hardware goes, I don't have much expertise. Also, I haven't looked hard enough to find any Freescale- or other ARM SoC-based phones, and I don't know of any Android phones (shipped with android, not ported by third-party developers) that DON'T use Qualcomm chips. For the moment, it seems you must pay a premium for openness.

Well, thank for an insightfull reply anyway.
The N900 is definitely on my watch-list, but yeah, it sure is a bit expensive. Then again, it IS cheaper than the N1, So it isn't that bad.
As for the legality, it really shouldn't be legal NOT to give out open drivers for hardware when you sell it to consumers. They should have a legal right to have it!
But seriously, these outdated qualcomm chips in most HTC phones is no competitor to Snapdragon or Tegra, so who do they think they are fooling when they keep the drivers closed for "competitive reasons". Thats pretty much what they all us as an excuse.
Sad to hear about the "free" Touchbook fate though. I had high hopes for it, but if that is the stance they're taking now, I'm glad i didn't buy it myself.
Soooomewheeereee over the rainbooooow, coooode iiiiiiiiis freeeeeee (likeinfreespeechnotfreebeer) Soooomewheeeeree over...
In paradise there is no binary blobs in any code running on any of my devices.

Acer has just released the "Acer Liquid kernel source code". http://www.acer.co.uk/acer/service....tx1g.c2att92=122&ctx1.att21k=1&CRC=2980211862 Liquid support under Document tab.
Hope that everything is there.

The GeeksPhone One is an open source Android device running on the MSM7225 processor, and worth checking out.
http://www.geeksphone.com/en/

The samsung moment uses the Samsung S3C6410 processor .... whitch is used in otehr windows mobile devices and i do belive samsung has a sdk advable but im not sure

I don´t know it exactly but shouldn´t be the OpenMoko a true opensource phone?

Isn't the Droid pretty decent? Doesn't Motorola even release the drivers for the hardware as open source here: https://opensource.motorola.com/sf/sfmain/do/home

The Moment has the same problem the SmartQ 5/7 have, unless Samsung released source code for the Android OpenGL drivers behind my back. That still wouldn't cover running Debian, sadly - I was hoping I could run Debian if I got one, but I know it won't be 3D-accelerated even if Debian does run. The Motorola Droid has pretty much the same SoC as the N900 and friends, hence the same PowerVR driver problems. IIRC, the SGX drivers are only partially open - I think most of the source code is available, but I remember hearing somewhere that there were redistribution problems. The infamous Intel GMA500 IGP (which was actually designed - and manufactured I think - by PowerVR) still suffers from poor-quality closed drivers, and Intel still hasn't done anything about it, pointing fingers at PowerVR for who knows what reason. I've come to a conclusion: hardware companies don't care about the consumer anymore

What's the status of this these days?
- how open are the n900 drivers?
The Nexus and i9000 both have a thing where the modem reads the CPU so that's as far as the reliant project goes.
Geeks phone is pretty cool but has binary blobs.
I remember reading about another project to make a phone like the Geeksphone but being prepared for compromise to achieve full openness. But I forget the name of the project. Anyone know what its called?
I'm really hoping there's a cheap Chinese phone out there that one can really own from driver level up now.

What is all the obsession over dual core phones?

I have to ask: Why does everyone want a dual core phone which cant even currently be used?
I say it cant be used because dual core processors cant be used on Android 2.3 Gingerbread/Linux kernel 2.6.35, there is only multi-core processor support in A3H/L2.6.36 (only avaliable (officially) on tablets). We will see problably support in in "A4I"/"L3.6.37" for both phones and tablets.
So whats everyones obsession? The only thing you are problably gaining is a SLIGHT speed boost (not even close when a kernal that supports it is released) and more battery drain.
On a counterside this could bring good marketing to Google: They release "A4I", current dual core phones get a HUGE speed boost and everyone praises Google. Could work good for them.

Interesting, I never knew Gingerbread couldn't support dual cores on phones. Good info, I guess I'll keep my Evo for another year.

It's pretty easy to compile the kernel to use multi core processors. The current one may not, but hold your judgement until it's actually released.

crazy25000 said:
It's pretty easy to compile the kernel to use multi core processors. The current one may not, but hold your judgement until it's actually released.
Click to expand...
Click to collapse
So true............. Currently 0.0000000000000000000000000000000000000000000001% of users AND developers of applications can and are willing to complie a custom kernel not used by the rest and use/make multi core supported applications with its multi core supported kernel.

I guess progress has to begin somewhere?

i don't think i'll ever need / want a dual core phone for my daily rutine, my SGS is perfect for me, what more could you need from a phone? don't think they'll be able to fit jet packs on them any time soon...

riahc3 said:
So true............. Currently 0.0000000000000000000000000000000000000000000001% of users AND developers of applications can and are willing to complie a custom kernel not used by the rest and use/make multi core supported applications with its multi core supported kernel.
Click to expand...
Click to collapse
What I'm saying is the kernel can easily be compiled by Google or Samsung and used as the stock kernel on the GSII.

maranello69 said:
i don't think i'll ever need / want a dual core phone for my daily rutine, my SGS is perfect for me, what more could you need from a phone? don't think they'll be able to fit jet packs on them any time soon...
Click to expand...
Click to collapse
Yeah its logical to think like that but 3 years ago who thought you need phone with such big screen and processor/RAM almost match PC speed?
As someone said somewhere they have to start but interesting thought by thread creator

ksavai said:
Yeah its logical to think like that but 3 years ago who thought you need phone with such big screen and processor/RAM almost match PC speed?
As someone said somewhere they have to start but interesting thought by thread creator
Click to expand...
Click to collapse
Honestly those arent needs either. But as of right now the only purpose of a dual core phone is to brag.

I/O Issue - Is it really unique to transformer line?

EDITED as more information about other platforms were found.
Based on my reading here, it sounds like there are two theories exist currently.
1, ASUS using old kernel
2. Tegra chip issue
However, following information seems to challenge these hypothesis..
According to this http://forum.xda-developers.com/show....php?t=1722799, Iconia A700 has very similar result and also Kernel info shows 2.6.39.4+.
So based on this, I think we can hypothesize couple things:
Hypothesis 1: Kernel is the issue
One flag goes against this is that Nexus 7, which uses the latest kernel did not outperform transformer line by much. So it may boost some, but unlikely to be the sole cause of the problem.
Hypothesis 2: Tegra chipset is the issue
On the andropolice benchmark page, they included HTC One X with Tegra 3 version. It actually outperformed it counterpart and in fact was one of the best I/O benchmark result producing unit excluding Nexus Phone. So it is hard to believe Tegra 3 is the issue.
Hypothesis 3: ASUS is the issue
This well may be true, but when you look at Acer Iconia 700 Tegra 3 HD Screen model, it is as bad or perhaps slightly worse than the Transformer Infinity. So perhaps there is a part of kernel that they share or provided by someone?
Hypothesis 4: Tablet SSD/Flash or other common denominator hardware is the issue
Again this is something based on the Iconia vs. Infinity. Infinity has superior CPU and RAM yet the difference in IO is so subtle. This to me suggest bottleneck lies somewhere else. Such as SSD/Flash drive itself? Though I am not sure if that is major advantage of HTC One over Tablet as you would think smaller drives are tends to be slower and more expensive...
I know we still have not answered anything here, but at least, this result make a step further to suggest underlying issue is NOT unique to infinity but perhaps wider problem across the android tablet. If so, the chance of it getting fixed would either depend on the Google or individual manufactures to put unexpected amount of resource into this...
What do you all think?

HoushaSen said:
Based on my reading here, it sounds like there are two theories exist currently.
1, ASUS using old kernel
2. Tegra chip issue
However, following information seems to challenge these hypothesis..
According to this http://forum.xda-developers.com/show....php?t=1722799, Iconia A700 has very similar result and also Kernel info shows 2.6.39.4+.
So based on this, I think we can hypothesize couple things:
Hypothesis 1: Kernel is the issue
If so, who is actually making this kernel? Is it vendors of tablet or Google? i.e. Samsung doing its own customization which includes the newer Kernel? One thing that does not make sense here (at least to me) is that if you look at http://en.wikipedia.org/wiki/Android_version_history, the Kernel is based on the version of Android i.e. sounds like NOT dependent on the manufacture. However, clearly the picture above shows Iconia A700, which runs Ice Cream Sandwitch is not running on newer kernel as stated by the Wiki... So I am a bit confused here...
Hypothesis 2: Tablet SSD or other common denominator hardware is the issue
Considering the faster Tegra 3 (not by much but some), and better RAM (DDR3 vs. DDR2) and minimal differece between the two systems, my guess is Tegra 3 chip or memory is not the bottle neck, but rather SSD or other common component is the issue.
I know we still have not answered anything here, but at least, this result make a step further to suggest underlying issue is NOT unique to infinity but perhaps wider problem across the android tablet. If so, the chance of it getting fixed would either depend on the Google or individual manufactures to put unexpected amount of resource into this...
What do you all think?
Click to expand...
Click to collapse
Kernels are created by the manufacturer, they're what tell the OS about the hardware and how to use it. Google makes the Operating system, not the kernel. Each kernel is different on each device because each device has different hardware.
So I'm thinking it's just a software issue. I haven't really looked into it, but I haven't heard a ton of complaints about I/O issues from One X users. I think this whole issue is just normal Android stuff that people are blowing out of proportions because it may be a little worse on this right now. I know on my Bionic when a lot of I/O operations are happening, it slows down a bit. Especially with restoring Titanium Backup files and moving big files around. I'm thinking with a little help from Asus and/or indy devs this won't be a big issue.

If you use old software, you always miss out on some features. (Office 95 won't open OpenDocument-formatted documents, AFAIK. ) That being said, it is quite common for SSDs to use a number of controllers that is suboptimal for the number of memory units. That might be a problem.
Given that I perceive the TF700 to be quite a bit snappier with the SuperCharger, I think it's quite possible the issue is in fact caused by an interaction of multiple factors: standard Android policies (not being able to clear out finished-and-not-to-be-used-anytime-soon apps, filling RAM to the brim py preference), suboptimal hardware (crippled I/O controller(s)?) and software (kernel issues).
The second component obviously is out of reach in terms of solutions.The first component could be alleviated partly -- this going head-on with the considerations for earlier and less capable Android systems -- by using a task killer, or optimizing the system (SuperCharger), and the third component could be solved by some of the unbelievably able kernel enthusiasts we have in the XDA ecosystem.
I think we might have a case on hand here for arguing that the current versions of Android are not really optimal for these high-end devices. Scaling issues are not that rare: Windows scales like crap to less capable devices, whereas all *nix systems I've worked with ran beautifully on pretty much archaic systems, and the latter don't gain as much when upgrading hardware, in my experience. From a cynical point of view, you might argue that that's because they ran REALLY well initially anyway.
The policies in force for both scenarios are necessarily different. It might be beneficial to change some of them a little bit. If Google does not institute that by its mighty self, we can at the least take matters in our own hands.

KilerG said:
Kernels are created by the manufacturer, they're what tell the OS about the hardware and how to use it. Google makes the Operating system, not the kernel. Each kernel is different on each device because each device has different hardware.
Click to expand...
Click to collapse
So I guess Wiki is not correct... They often amazes me how much detail there are and quite frequently right. But I guess not this time as Wiki clearly assigns each Android OS version as based on XXX Linux Kernel. But what you say actual make sense as Kernel is like interface between the OS and underlying hardware so my understanding is Kernel just simply provides set of API that meets the OS demand.
But if this is indeed the case and Kernel is the real conundrum then the chance of it being fixed may be much lower, isn't it? Because fixing kernel or upgrading kernel to newer version probably requires extensive amount of work, which I am not sure any company is willing to do when the machines are already sold.
If it was Google, perhaps they could have indeed updated kernel along with Jellybean, but that's out of picture now except of XDA members.
MartyHulskemper said:
I think we might have a case on hand here for arguing that the current versions of Android are not really optimal for these high-end devices. Scaling issues are not that rare: Windows scales like crap to less capable devices, whereas all *nix systems I've worked with ran beautifully on pretty much archaic systems, and the latter don't gain as much when upgrading hardware, in my experience. From a cynical point of view, you might argue that that's because they ran REALLY well initially anyway.
Click to expand...
Click to collapse
Interesting argument there. One hope I have here is that if Nexus 7 succeeds, developers are more willing to put apps specific for tablets. yes. they may be 7 inch... but better than 4 or 5 inch scaling to 10.1 inch. Plus Nexus 7 has very similar spec as Transformer Prime, so supporting of such device seem to make ASUS ahead of packs and in fact, (if they decide to do so) they can easily port those knowledge and resources into Transformer line.
But this IO issue may be one reason why iOS avoids true multitasking. I can never download files or load files in a application in background on my iPAD2. It basically freezes the application where left off i.e. not really multitasking. But because of it, most application won't see any issue what other application is running in background (well actually nothing is running in background..but you know what I mean).
So I am not saying, Android should take this approach but perhaps we may have to take that into consideration and appreciate true multitasking in Android. and when the task becomes large (such as IO issue here), we may simply have to understand some tasks are not for multitask friendly...

Mostly interesting questions but when it comes to nvidia and i/o problems lets blame it on the kernel drivers.
Look at around 48 min mark.
www . youtube . com/watch?feature=player_embedded&v=MShbP3OpASA
Do you think Asus seriously cares about its customers??

HoushaSen said:
So I guess Wiki is not correct... They often amazes me how much detail there are and quite frequently right. But I guess not this time as Wiki clearly assigns each Android OS version as based on XXX Linux Kernel. But what you say actual make sense as Kernel is like interface between the OS and underlying hardware so my understanding is Kernel just simply provides set of API that meets the OS demand.
But if this is indeed the case and Kernel is the real conundrum then the chance of it being fixed may be much lower, isn't it? Because fixing kernel or upgrading kernel to newer version probably requires extensive amount of work, which I am not sure any company is willing to do when the machines are already sold.
If it was Google, perhaps they could have indeed updated kernel along with Jellybean, but that's out of picture now except of XDA members.
Interesting argument there. One hope I have here is that if Nexus 7 succeeds, developers are more willing to put apps specific for tablets. yes. they may be 7 inch... but better than 4 or 5 inch scaling to 10.1 inch. Plus Nexus 7 has very similar spec as Transformer Prime, so supporting of such device seem to make ASUS ahead of packs and in fact, (if they decide to do so) they can easily port those knowledge and resources into Transformer line.
But this IO issue may be one reason why iOS avoids true multitasking. I can never download files or load files in a application in background on my iPAD2. It basically freezes the application where left off i.e. not really multitasking. But because of it, most application won't see any issue what other application is running in background (well actually nothing is running in background..but you know what I mean).
So I am not saying, Android should take this approach but perhaps we may have to take that into consideration and appreciate true multitasking in Android. and when the task becomes large (such as IO issue here), we may simply have to understand some tasks are not for multitask friendly...
Click to expand...
Click to collapse
I hope (and actually expect) that JB will fix a lot of these issues, as it seems to tweak lot of elements that might be in the way of Android really deploying on capable hardware. As far as the Nexus 7 goes, it probably is a really nice device, but I am too much infatuated with the HD screen and the battery/keyboard/dock I currently have to even consider going over.
And yes, maybe we just have to accept that, for the time being, real mobile multitasking (i.e., relatively limitless) may be out of reach. According to your experience with the iPad2, it may show that Apple actually did some real-life testing and came to the same conclusion. That may have been the reason for the much criticised decision to not support multitasking.

Someone mentioned on our Infinity fora here that all the flash memory used in today's tablet is the same chip, so it's not somebody in ASUS or Acer didn't want to spend an extra 10$ per device, it must be something else.
I'm still wondering why I get ca. 10MB/s write and ca. 20MB/s read on internal storage and the other way around with (micro)SD or USB storage.
I think all of us are waiting for JB right now.

Its definitely a kernel issue. If you look in the Prime forum, there's a lot of people raving about the IO performance of Motley's kernel. In the TF300 forum, there's been some mention that CM9 improves the browser performance Once we get a bootloader unlock I'd be shocked if we didnt get a better kernel, if Asus hasn't fixed it already by then.

The old kernel is caused by NVidia because in every Tegra 3 device the kernel is the same: 2.6.... Nexus 7 seems to have 3.1 kernel and hopefully all Tegra 3 devices which get JB will get updated kernel. Old kernel isn't Asus' fault. It is NVidia's fault. Google built ICS with 3.0 kernel and that is why almost all other devices except Tegra 3 devices have Linux kernel version 3.0.

attelaut said:
The old kernel is caused by NVidia because in every Tegra 3 device the kernel is the same: 2.6.... Nexus 7 seems to have 3.1 kernel and hopefully all Tegra 3 devices which get JB will get updated kernel. Old kernel isn't Asus' fault. It is NVidia's fault. Google built ICS with 3.0 kernel and that is why almost all other devices except Tegra 3 devices have Linux kernel version 3.0.
Click to expand...
Click to collapse
Wait correct me if I am wrong. So you are saying, as stated in the Wiki when original Android OS is developed e.g. ICS it used Linux kernel version 3.0.x but then when ASUS or other manufactors using Tegra 3 chip only got access to Kernel 2.6 because it is what Nvida provided? So blame is actually on the Nvidia?
So how did Nexus 7 got new kernel? It uses Tegra 3, ASUS is involved... Is it google that forced NVida to upgrade to newer kernel? In any event, do Kernel usually get updated along with OS update?
One pessimistic comment though.. If we look at Andropolice benchmark Nexus 7 was included there, and their IO result was not much better than Transformer line.

HoushaSen said:
Wait correct me if I am wrong. So you are saying, as stated in the Wiki when original Android OS is developed e.g. ICS it used Linux kernel version 3.0.x but then when ASUS or other manufactors using Tegra 3 chip only got access to Kernel 2.6 because it is what Nvida provided? So blame is actually on the Nvidia?
So how did Nexus 7 got new kernel? It uses Tegra 3, ASUS is involved... Is it google that forced NVida to upgrade to newer kernel? In any event, do Kernel usually get updated along with OS update?
One pessimistic comment though.. If we look at Andropolice benchmark Nexus 7 was included there, and their IO result was not much better than Transformer line.
Click to expand...
Click to collapse
Its entirely possible that Asus decided backporting 3.X's features to a 2.6 kernel would be easier than to do a 3.X kernel from the ground up. Its the route many devices without official ICS have taken to get their community builds and for most of those devices it works just fine.
The Nexus 7 had the advantage of being being handled by Google for software, and as such had no legacy code to be based on. The 700, on the other hand, was close enough to the Prime that Asus probably decided to use the kernel of the later as a base.
This is just speculation though.

jdefi3ebuggdsf32 said:
Mostly interesting questions but when it comes to nvidia and i/o problems lets blame it on the kernel drivers.
Look at around 48 min mark.
www . youtube . com/watch?feature=player_embedded&v=MShbP3OpASA
Do you think Asus seriously cares about its customers??
Click to expand...
Click to collapse
So NVIDIA is the issue then? I like his comment, at the end. "So NVIDIA, F*CK YOU."

Jotokun said:
Its entirely possible that Asus decided backporting 3.X's features to a 2.6 kernel would be easier than to do a 3.X kernel from the ground up. Its the route many devices without official ICS have taken to get their community builds and for most of those devices it works just fine.
The Nexus 7 had the advantage of being being handled by Google for software, and as such had no legacy code to be based on. The 700, on the other hand, was close enough to the Prime that Asus probably decided to use the kernel of the later as a base.
This is just speculation though.
Click to expand...
Click to collapse
But reasonable speculation. I don't think you're far off with these assumptions.
Here's hoping that JB and maybe even some kernel updates and tweaks can at least alleviate the IO issues.

The kernel is a part of OS and can be updated when the OS is updated. I think the kernel is old because Nvidia hadn't lot of time to prepare the kernel to be compatible with new android. Now when nvidia have bee working with google and asus so maybe google have helped nvidia to make new kernel to work with tegra 3. If you want new kernel, find a working custom rom with new kernel and use it.

attelaut said:
The kernel is a part of OS and can be updated when the OS is updated. I think the kernel is old because Nvidia hadn't lot of time to prepare the kernel to be compatible with new android. Now when nvidia have bee working with google and asus so maybe google have helped nvidia to make new kernel to work with tegra 3. If you want new kernel, find a working custom rom with new kernel and use it.
Click to expand...
Click to collapse
Well at this point, we should be waiting for the bootloader to be unlockable. Once we can load custom kernels, the tablet will zooooooooooom.

KilerG said:
Well at this point, we should be waiting for the bootloader to be unlockable. Once we can load custom kernels, the tablet will zooooooooooom.
Click to expand...
Click to collapse
Did custom ROMs solve the I/O problems with the Prime entirely? (never owned one)

d14b0ll0s said:
Did custom ROMs solve the I/O problems with the Prime entirely? (never owned one)
Click to expand...
Click to collapse
According to this thread, it does.
http://forum.xda-developers.com/showthread.php?t=1768406

Jotokun said:
According to this thread, it does.
http://forum.xda-developers.com/showthread.php?t=1768406
Click to expand...
Click to collapse
no it doesnt help entirely. it helps a bit but it does not solve the problems.
for instance the browser still locks up a lot, some ANR messages every now now and then.
only way to get the browser stable is by using browser2ram.

Seems it can be a hard way out of the T3 path.
Have you tried Dolphin browser on your Prime btw? (if I assume correctly that you own one) It helps a lot on the Infinity (Chrome is slightly faster than the stock browser, but is said not to support H/W acceleration, which makes it slower on content-loaded pages)
Sent from my ASUS Transformer Pad TF700T using xda app-developers app

I am sure someone else has already noticed, but HTC One X which had one of top I/O result on Andropolice benchmark has a version with Tegra 3, which still performed well in fact often outperformed its counter part. I could not find which Kernel it uses though. But this may perhaps be one evidence goes against Tegra 3 is the actual issue, but rather something else. And also noting Nexus 7, which used Kernel 3.1 not doing that much better than transformer line also put a flag against Kernel being underlying issue. Could it really be the flash drive itself?
Now to put these in summary, I edited my opening post.

MTK Sources

Hello comunity!
First: Sorry for my bad english.
2nd: I've had found the sources from the mt6797 which is build in the redmi note 4 MTK. Is this enought for building a AOSP rom ?
There's the link: https://github.com/MT6797?tab=repositories
venor sources: https://gitlab.com/mt6797/vendor

diedmaster said:
Hello comunity!
First: Sorry for my bad english.
2nd: I've had found the sources from the mt6797 which is build in the redmi note 4 MTK. Is this enought for building a AOSP rom ?
There's the link: https://github.com/MT6797?tab=repositories
venor sources: https://gitlab.com/mt6797/vendor
Click to expand...
Click to collapse
No.
Mediatek + Xiaomi = No support, no kernel, nothing. Just deal with it. Trust me, I've been there. I had RN2. Ditched it after year.

gr4nis said:
No.
Mediatek + Xiaomi = No support, no kernel, nothing. Just deal with it. Trust me, I've been there. I had RN2. Ditched it after year.
Click to expand...
Click to collapse
mhm thats a REAL shame :/ but thanks for answer

Don't you think the developers who know how to develop AOSP already know? They are WAY ahead of you. If you checked the dev forum instead of being lazy you would see that there is already an alpha of CyanogenMod 14.1 which is built from sourcecode.
The problem is not MTK sources, it's Redmi Note 4 sources. Drivers for the camera and the fingerprint reader and stuff like that.
Sorry if you think I'm being rude, but this is borderline a troll/spam thread. You get people half excited from the title then share a repo link that any child could find in Google.
Please leave the development to the developers.
gr4nis said:
No.
Mediatek + Xiaomi = No support, no kernel, nothing. Just deal with it. Trust me, I've been there. I had RN2. Ditched it after year.
Click to expand...
Click to collapse
And yet you decided to try your luck and get another MTK device?
Most of us are aware that getting an MTK device means no AOSP. We get them because they have a high price-to-performance ratio.
Personally I am glad to move away from the Xperia series; it had every AOSP fork under the sun being made for it but they were ALL buggy. It's just torture. If you really want that kind of developer stuff, you should get a Google device.

CosmicDan said:
Don't you think the developers who know how to develop AOSP already know? They are WAY ahead of you. If you checked the dev forum instead of being lazy you would see that there is already an alpha of CyanogenMod 14.1 which is built from sourcecode.
The problem is not MTK sources, it's Redmi Note 4 sources. Drivers for the camera and the fingerprint reader and stuff like that.
Sorry if you think I'm being rude, but this is borderline a troll/spam thread. You get people half excited from the title then share a repo link that any child could find in Google.
Please leave the development to the developers.
And yet you decided to try your luck and get another MTK device?
Most of us are aware that getting an MTK device means no AOSP. We get them because they have a high price-to-performance ratio.
Personally I am glad to move away from the Xperia series; it had every AOSP fork under the sun being made for it but they were ALL buggy. It's just torture. If you really want that kind of developer stuff, you should get a Google device.
Click to expand...
Click to collapse
thanks for you answer,
I really didnt know that .. I thought with the SoC sources the drivers are allready included .. but okey, thanks anyway

CosmicDan said:
And yet you decided to try your luck and get another MTK device?
Most of us are aware that getting an MTK device means no AOSP. We get them because they have a high price-to-performance ratio.
Personally I am glad to move away from the Xperia series; it had every AOSP fork under the sun being made for it but they were ALL buggy. It's just torture. If you really want that kind of developer stuff, you should get a Google device.
Click to expand...
Click to collapse
Who said I did? I have Global version of RN4 (mido). I just replied to him, cause I know that feeling to be disappointed by MTK device. I had one and that is definitely gonna be my last.

gr4nis said:
Who said I did? I have Global version of RN4 (mido). I just replied to him, cause I know that feeling to be disappointed by MTK device. I had one and that is definitely gonna be my last.
Click to expand...
Click to collapse
Actually you said "We"
1. nominative plural of*I.
2. (used to denote oneself and another or others):
http://www.dictionary.com/browse/we
Sent from my Redmi Note 4 using Tapatalk

gr4nis said:
Who said I did? I have Global version of RN4 (mido). I just replied to him, cause I know that feeling to be disappointed by MTK device. I had one and that is definitely gonna be my last.
Click to expand...
Click to collapse
I mean if anything the Qualcomm variant is the dissapointing one, why would you buy it over the Redmi note 3 with a much faster processor and more rom support is beyond me.

Wilderone said:
Actually you said "We"
1. nominative plural of*I.
2. (used to denote oneself and another or others):
http://www.dictionary.com/browse/we
Sent from my Redmi Note 4 using Tapatalk
Click to expand...
Click to collapse
What?
I didn't use word "We" in any of my posts. Is this reply for @CosmicDan?
Nintonito said:
I mean if anything the Qualcomm variant is the dissapointing one, why would you buy it over the Redmi note 3 with a much faster processor and more rom support is beyond me.
Click to expand...
Click to collapse
It may be faster, but it's not better overall. SD 625 is based on newer architecture (14nm) which makes it cooler in load and offer your phone much better battery life. If you don't do serious gaming, the difference in speed is not even noticable (Also SD 650 is gonna throttling much sooner because of higher temperatures, which is point where SD 625 can match it's performance). And about ROMs... You can't be serious! RN3 Pro is year older than RN4X, which is still new device. Of course more people have it therefore more people develop for it. Give it some time, and RN4X gonna excede RN3Pro (even now there is developement for all ROM's I'm interested in and a lot more). Also 625 is newer than 650 so it's gonna be supported longer.

gr4nis said:
Who said I did? I have Global version of RN4 (mido). I just replied to him, cause I know that feeling to be disappointed by MTK device. I had one and that is definitely gonna be my last.
Click to expand...
Click to collapse
Oh sorry, I just assumed you had the MTK version because... well.. THIS IS THE MTK SUBFORUM.
You come in here and trash-talk a device/chipset you don't even have, and expect us to value your opinion? Please.
gr4nis said:
What?
I didn't use word "We" in any of my posts. Is this reply for @CosmicDan?
It may be faster, but it's not better overall. SD 625 is based on newer architecture (14nm) which makes it cooler in load and offer your phone much better battery life. If you don't do serious gaming, the difference in speed is not even noticable (Also SD 650 is gonna throttling much sooner because of higher temperatures, which is point where SD 625 can match it's performance). And about ROMs... You can't be serious! RN3 Pro is year older than RN4X, which is still new device. Of course more people have it therefore more people develop for it. Give it some time, and RN4X gonna excede RN3Pro (even now there is developement for all ROM's I'm interested in and a lot more). Also 625 is newer than 650 so it's gonna be supported longer.
Click to expand...
Click to collapse
"Better" is subjective. For starters, my X20 Note 4 does not overheat (in fact this is the first I've ever heard about thermal issues on this thing). Secondly, battery life is a non-issue for me - I get ~5 hours SoT which is more than enough to last me a whole day, even two or three if I don't get to charge one night for whatever reason.
The SD is actually probably the same in gaming sine the MTK GPU is underpowered, but in the CPU department the Helio X20 beats the pants off of the SD. You say the speed is not noticeable yet you just admitted you don't even have a Note 4 MTK variant so how do you know? The numbers speak for themselves - the Geekbench score is just too big for it to not be noticeable when under load.
ROM's are a moot point, they don't interest me - only an idiot (or, I suppose, a former fan who regrets their purchase) buys a Xiaomi device and gets rid of MIUI. You can get a Nexus or last-gen Xperia device or whatever for cheaper if you want that crap.
Anyway, you said you don't even have an MTK device, yet you're in here criticizing it, that's like a perfect example of trolling. I'm unsubbing, not gonna waste my time on this anymore.
Personally, I got the Note 4 at the time (right near launch) because I needed a new phone RIGHT NOW, I wasn't going to wait ~6 months for a device that's the same price and only a little bit better - if I waited six months I could of saved more and gotten a high end device. But the SD variant only has two things going for it - better battery life, and support for non-MIUI ROM's - two things that I and many others don't need.

You Said it all Dan..but many users think they know better...
Enviado do meu N5206 através de Tapatalk

CosmicDan said:
Oh sorry, I just assumed you had the MTK version because... well.. THIS IS THE MTK SUBFORUM.
You come in here and trash-talk a device/chipset you don't even have, and expect us to value your opinion? Please.
"Better" is subjective. For starters, my X20 Note 4 does not overheat (in fact this is the first I've ever heard about thermal issues on this thing). Secondly, battery life is a non-issue for me - I get ~5 hours SoT which is more than enough to last me a whole day, even two or three if I don't get to charge one night for whatever reason.
The SD is actually probably the same in gaming sine the MTK GPU is underpowered, but in the CPU department the Helio X20 beats the pants off of the SD. You say the speed is not noticeable yet you just admitted you don't even have a Note 4 MTK variant so how do you know? The numbers speak for themselves - the Geekbench score is just too big for it to not be noticeable when under load.
ROM's are a moot point, they don't interest me - only an idiot (or, I suppose, a former fan who regrets their purchase) buys a Xiaomi device and gets rid of MIUI. You can get a Nexus or last-gen Xperia device or whatever for cheaper if you want that crap.
Anyway, you said you don't even have an MTK device, yet you're in here criticizing it, that's like a perfect example of trolling. I'm unsubbing, not gonna waste my time on this anymore.
Personally, I got the Note 4 at the time (right near launch) because I needed a new phone RIGHT NOW, I wasn't going to wait ~6 months for a device that's the same price and only a little bit better - if I waited six months I could of saved more and gotten a high end device. But the SD variant only has two things going for it - better battery life, and support for non-MIUI ROM's - two things that I and many others don't need.
Click to expand...
Click to collapse
You should read more and write less. I was comparing SD 650 and SD 625. Didn't even mention MTK or RN4 (nikel). So your whole post is actually pointless.

gr4nis said:
You should read more and write less. I was comparing SD 650 and SD 625. Didn't even mention MTK or RN4 (nikel). So your whole post is actually pointless.
Click to expand...
Click to collapse
You were comparing SD chipset in the wrong thread. This is a Mediatek subforum. So actually, his post is not pointless.

ekin_strops said:
You were comparing SD chipset in the wrong thread. This is a Mediatek subforum. So actually, his post is not pointless.
Click to expand...
Click to collapse
True. It was OT, but I just responded to someone else's comment. Didn't come with it on my own.

CosmicDan said:
Don't you think the developers who know how to develop AOSP already know? They are WAY ahead of you. If you checked the dev forum instead of being lazy you would see that there is already an alpha of CyanogenMod 14.1 which is built from sourcecode.
The problem is not MTK sources, it's Redmi Note 4 sources. Drivers for the camera and the fingerprint reader and stuff like that.
Click to expand...
Click to collapse
OK let me get this straight. The culprit here is xiaomi and not mediatek for not releasing sources? Is there any chance xiaomi will release sources? How come snapdragon note 4 has so many roms? Does that mean xiaomi has released sources for it? Has mediatek released sources for this device? Sorry for asking

adrxano said:
OK let me get this straight. The culprit here is xiaomi and not mediatek for not releasing sources? Is there any chance xiaomi will release sources? How come snapdragon note 4 has so many roms? Does that mean xiaomi has released sources for it? Has mediatek released sources for this device? Sorry for asking
Click to expand...
Click to collapse
Neither note 4 has official source from Xiaomi. Difference is that Snapdragon devices can be made to boot from CAF source from Qualcomm due to sheer experience, and the same has not been accomplished with Mediatek's Helio X20 source. That and xda has a massssssssuve preference towards Qualcomm anyways due to repeat positive experiences, so most developers spend the time on Qualcomm devices.

CosmicDan said:
Oh sorry, I just assumed you had the MTK version because... well.. THIS IS THE MTK SUBFORUM.
You come in here and trash-talk a device/chipset you don't even have, and expect us to value your opinion? Please.
"Better" is subjective. For starters, my X20 Note 4 does not overheat (in fact this is the first I've ever heard about thermal issues on this thing). Secondly, battery life is a non-issue for me - I get ~5 hours SoT which is more than enough to last me a whole day, even two or three if I don't get to charge one night for whatever reason.
The SD is actually probably the same in gaming sine the MTK GPU is underpowered, but in the CPU department the Helio X20 beats the pants off of the SD. You say the speed is not noticeable yet you just admitted you don't even have a Note 4 MTK variant so how do you know? The numbers speak for themselves - the Geekbench score is just too big for it to not be noticeable when under load.
ROM's are a moot point, they don't interest me - only an idiot (or, I suppose, a former fan who regrets their purchase) buys a Xiaomi device and gets rid of MIUI. You can get a Nexus or last-gen Xperia device or whatever for cheaper if you want that crap.
Anyway, you said you don't even have an MTK device, yet you're in here criticizing it, that's like a perfect example of trolling. I'm unsubbing, not gonna waste my time on this anymore.
Personally, I got the Note 4 at the time (right near launch) because I needed a new phone RIGHT NOW, I wasn't going to wait ~6 months for a device that's the same price and only a little bit better - if I waited six months I could of saved more and gotten a high end device. But the SD variant only has two things going for it - better battery life, and support for non-MIUI ROM's - two things that I and many others don't need.
Click to expand...
Click to collapse
I Agree 100%, i have MTK and my girl SD, MTK RULES!!!

adrxano said:
OK let me get this straight. The culprit here is xiaomi and not mediatek for not releasing sources? Is there any chance xiaomi will release sources? How come snapdragon note 4 has so many roms? Does that mean xiaomi has released sources for it? Has mediatek released sources for this device? Sorry for asking
Click to expand...
Click to collapse
Do you not know that the combo of cpu, camera, soc, on the redmi note 4 is simillar to a lot of other androids lol. And those other androids have their sources released. You know where jm going with this. Redmi note 4 snapdragon having a lot of custom roms is in no way a big thanks to the redmi note ⁴ community itself. Get real.

personally I dislike miui as it has no support for advanced USB OTG features such as gamepad compatibility or being used as a usb keyboard/touchpad mouse for your pc . though at least the MTK chipset on this phone supports 10bit h265 and vp9 which makes it good for long trips. provided most of your trip isn't in direct sunlight.

asdf2354 said:
personally I dislike miui as it has no support for advanced USB OTG features such as gamepad compatibility or being used as a usb keyboard/touchpad mouse for your pc . though at least the MTK chipset on this phone supports 10bit h265 and vp9 which makes it good for long trips. provided most of your trip isn't in direct sunlight.
Click to expand...
Click to collapse
hmm MTK Note4 Support advanced OTG, eyboard, mouse and my soudcard (Soundbalster USB XiFi works fine)

How to do Virtualization on Android

Disclaimer: This is an open discussion thread for How to do virtualization on Android! It's not a reference or guide! But hope this thread can lead us towards making a way to do it!
Intro: Once phones was a tiny piece of electronic device which was mainly used to talk and sending text messages! (I am talking about mobile phones off course! )
Then here comes smartphones like the symbian one and then iphones and Android!
They opened a lot more way to do on a device rather than only talking or texting!
But still we needed to rely on laptops or desktops to do extensive tasks which we couldn't do (yet) on smartphones!
The main reason was the lack of technology or the memory and processing power limitations on these device!
I remember I bought my first Redmi 2 at a cost of 200$ back in April 2015 which featured quadcore Qualcomm processor, 1GB of RAM and 8 GB of internal storage space!
But now the time has changed! Technology advanced exponentially! After 3 years of my first Xiaomi device, I bought another one (Mi A1) with almost the same price! Whuch features double (on the basis of cores) processors and 4X RAM and 8X internal spaces!
In the mean time on the mainstream computing counterpart, virtualization technology becomes so popular that if not all but most of the servers runs based on it! We have also docker now!
We can now use or test any software/OS on any device (mainstream computers off course) by the grace of virtualization!
On the other hand, Android devs still needs to do the hard work to port ROMs let the OS itself! And yet we can't run Windows on a Android device!
But wait! Android is also a Linux! Isn't it?
So, if Linux can run QUEMU/KVM, why not Android?
And most of the Android SOCs now are 64bit!
So, can't we just make it happen? Can't we just find a way to do virtualization and run any OS on a virtual environment right in our hand?
May be!
I don't know if any guys working on this or not!
But here's how to:
1) Enable virtualization support on kernel
2) Make an apps for Android for manging the virtual machines (like VirtualBox, VMWare etc.)
I think the Android kernels (most of them) supports virtualization already!
The hardest part is to make it compatible with the frontend Android! Which brings the apps and interfaces!
I know there's wine exist for Android! But that's just a complete different thing what I am talking about!
And I wasnt able to run wine on my tissot (Xiaomi Mi A1)!
Thanks everyone who is reading!
Give your valuable opinion and ideas!
Hope someone like @CosmicDan can make it!

ARMv8 (every phone) doesn't have hardware virtualisation extensions, so it would be as slow as emulation.
For that, we already have QEMU and KVM. But it's too slow to be of any practical use.
If you want proper virtualisation, you need ARMv8.1, which no phone has.

CosmicDan said:
ARMv8 (every phone) doesn't have hardware virtualisation extensions, so it would be as slow as emulation.
For that, we already have QEMU and KVM. But it's too slow to be of any practical use.
If you want proper virtualisation, you need ARMv8.1, which no phone has.
Click to expand...
Click to collapse
Hmm! I just realised the hardest part: it's ARM and not x86_64!

ProttoyX said:
Hmm! I just realised the hardest part: it's ARM and not x86_64!
Click to expand...
Click to collapse
That's emulation, not virtualisation.
You can use QEMU, Bochs or DOSBox to emulate x86 (x86_64 is probably impossible, idk but it's pointless to try). But it's dog slow and always will be.

CosmicDan said:
That's emulation, not virtualisation.
You can use QEMU, Bochs or DOSBox to emulate x86 (x86_64 is probably impossible, idk but it's pointless to try). But it's dog slow and always will be.
Click to expand...
Click to collapse
Hmm! Got it! This thing came into my mind when I was reading about servers based on ARM! Wondered if they provides virtualization/container service or not! And ARM provides more cores than x86_64! I guess it's it's related to RISC/CISC thing! Not sure though!
ARM servers uses ARMv8.1?
AND PLEASE DON'T MIND ABOUT ENDING EVERY SENTENCE WITH (!)! PLEASE!
No one can always be rude! ?
I am surely not!
Again thanks for what you’ve done for the tissot and other staffs! You are genius! ?

ProttoyX said:
Hmm! Got it! This thing came into my mind when I was reading about servers based on ARM! Wondered if they provides virtualization/container service or not! And ARM provides more cores than x86_64! I guess it's it's related to RISC/CISC thing! Not sure though!
ARM servers uses ARMv8.1?
AND PLEASE DON'T MIND ABOUT ENDING EVERY SENTENCE WITH (!)! PLEASE!
No one can always be rude! ?
I am surely not!
Again thanks for what you’ve done for the tissot and other staffs! You are genius! ?
Click to expand...
Click to collapse
Yes those ARM servers would be 8.1. It's not so much a RISC vs CISC thing but more an SoC vs CPU thing. Our devices are SoC's - sure they have many GHz and cores but they're still a lot slower that a proper CPU which has countless of extensions designed for accelerating tasks, and have more IPC capability and other such things (in short GHz/core count is comparable across different platforms or architectures, it's more relative than that). Our SoC's simply don't have those extensions that would make this feasible.

CosmicDan said:
ARMv8 (every phone) doesn't have hardware virtualisation extensions, so it would be as slow as emulation.
For that, we already have QEMU and KVM. But it's too slow to be of any practical use.
If you want proper virtualisation, you need ARMv8.1, which no phone has.
Click to expand...
Click to collapse
Every ARMv8,and even ARMv7 has.On v8 it's called EL2 while on v7 it's HYP mode.However the biggest headache is that most SoC vendors do not allow users to enter it even with bootloader unlock.
On Qualcomm there are no way except a low level powerful exploit. On Exynos it is possible,needs a specific SMC to trustzone,and can be done only with an unlocked bootloader with custom kernel.

fxsheep said:
Every ARMv8,and even ARMv7 has.On v8 it's called EL2 while on v7 it's HYP mode.However the biggest headache is that most SoC vendors do not allow users to enter it even with bootloader unlock.
On Qualcomm there are no way except a low level powerful exploit. On Exynos it is possible,needs a specific SMC to trustzone,and can be done only with an unlocked bootloader with custom kernel.
Click to expand...
Click to collapse
do you have any references links on this? maybe a cve for the qualcomm exploit?