Related
I hope this isn't perceived as spamming or fishing for votes. I think most of us would like to see a smoother Android GUI instead of that choppyness on our 1GHz phones. I and many people believe that Google can do something about this but are not prioritizing this as they should. I think we can change this by visiting and voting here, clicking on the star under the headline, if we want to see a change: http://code.google.com/p/android/issues/detail?id=6914
Who knows, if we start voting now, maybe they will implement this feature in the next Android version.
P.S. You need a Google account to be able to vote.
EDIT: Maybe this is why we haven't seen it yet?
From what I've heard, the fault lies mostly with HTC, encouraged by wholesale indifference by the carriers. Here's the story I was told:
* Qualcomm makes the core chipset used by most HTC phones, and most Android phones were built by HTC until VERY recently. Thus, the things that got the most attention during Android's first year and a half of commercial availability were things directly supported by HTC phones.
* The price charged by Qualcomm for its chipset varies, depending upon what features the handset manufacturer chooses to license from them. Put another way, every Qualcomm chip in a given family has the silicon resources to do everything... but manufacturers are only allowed to use the features they pay Qualcomm for the right to use.
* Because the carriers don't care, and the carriers are HTC's real customers, HTC didn't care about GPU support, either. It saved a few cents per phone, and washed its hands of GPU support to boot.
* Making matters worse, Qualcomm only makes its chipset documentation available under NDA (at least, the parts dealing with "premium" capabilities), and only made it available to licensees (of which there were very, very few). Ergo, the documentation has been VERY hard to come by, and less likely to be leaked by a public-minded HTC employee for the good of humanity.
Put another way, there probably isn't a thing Qualcomm can do to stop the folks at xda-developers.com from releasing guerrilla video drivers for HTC Android phones that take advantage of acceleration if they can figure out how it works, but you'll never see a phone come out of the box new with GPU acceleration unless HTC officially licenses the capability from Qualcomm. Nor will you see Google making it easy to do an end-run around the official release to graft it on, because then Qualcomm would sue THEM.
Click to expand...
Click to collapse
- This is from: http://androidforums.com/android-news-talk/29584-why-doesnt-androids-gui-use-gpu-acceleration.html
I starred it.
Definitely is bizarre that GPU integration isn't enabled in Android 2.1+
This hardware-can-do-qualcom-wont-allow-it is old...
It happens with a LOT of devices...
Sent from my HTC Desire using XDA App
I'm glad to see that we are climbing on the chart of issues.
I have come to notice that the issue of the choppy Android experience is not only a problem because of the lack of GPU acceleration. Android phones tend to respond to our gestures way too exactly. This results in uneven transitions, one half of the animation is fast and the other half is slower. This unevenness being a result of us not making, or following through, with perfectly even movements in terms of speed. I believe this is something Apple has addressed and they did it very nicely because even though you are moving your fingers unevenly and slowly, the UI transitions follows your finger in an even and smooth fashion but in a speed that matches your finger. This looks phenomenal. Same goes for faster input gestures, the Ios (iOS) responds in an even and smooth fashion but the transition is faster.
It was the same with my old HD1, the xda gpu-drivers helped alot. Looks like we'll have to take the matter into our own hands again.
Wasn't HTC mass-sued for this a while back?
Syc said:
It was the same with my old HD1, the xda gpu-drivers helped alot. Looks like we'll have to take the matter into our own hands again.
Wasn't HTC mass-sued for this a while back?
Click to expand...
Click to collapse
Nope. There was a whole load of talk of it over the TyTn II debacle, but the only thing to ever come of that was the rather excellent XDA GPU drivers.
I hate to admit this, but if Google, or whoever it is responsible, doesn't do something about this, I'll have to look elsewhere (Iphone). It might sound crazy but it's that important to me. I mean, it's so basic. Why add mega-ultra-fiction features and all other sh*t, when you don't know how to make a smooth transition. The basic element of the GUI.
Don't get me wrong, I don't like Apple, their policy or their attitude towards the rest. However, I'm being honest about this: they care. I haven't seen one Android phone capable of delivering smooth transitions although they are more powerful than the Iphones. On the one hand you have a team utilizing the entire potential of their sh**ty phones, and on the other hand you have a team doesn't give a rats a*s about the hardware in them.
I don't know if Google is to blame or the phone manufacturers. I just don't like the idea of owning a 1 GHz CPU and an awesome GPU (Samsung Galaxy S) and not being able to use it.
Sorry to bump an old thread.
Has there been any progress on this issue?
Using spare parts and setting all the window animations and transitions to very slow has made everything "smoother" to me for all purposes of discussion. during the slow but smooth transition, my phone has time to fully load the next screen or popup menu, therefore it all appears to happen seamlessly.
android is very smooth on my Hd2 ... Did you try a cyanogen mod build ?
Sorry, i was referring more towards the GPU being actively used by the UI front end.
Im using a Legend with Azure's cyanogen mod (froyo) things are pretty slick but I can tell when there are slowdowns, but the worst offender is definately the web browser.
The best example I can find is going to the html5 test website, I get a score of around 180 and the iphone about 140, but the legend browser (built in and Dolphin) really struggles to scroll that page, whereas on the Iphone its extremely smooth. Its these kind of inconsistencies which are annoying.
Another gripe is the whole portrait-landscape switch, its not gpu based in the least and its a rather half assed solution at the minute (visually). But I understand that no app could ever interfere with how this works as its so deep in the os? Such a shame.
I work in animation which is why im overly critical
I am not Apple fanboy, but i think that Anddroid OS has a big optimisation problem.
For example the iphone 4S had a CPU 800 Mz and it seem to be real fast. But the latest Androphone plan to use Dual CPU. Is Android OS needed more ressources than iOS?
Before make effort to get more material ressources, is n't time for google to optimise his OS ?
Symbian was an OS whitch was too optimsed and i would like to have an Android OS like that.
Someones wouldnt like what i said but it is my deep think.
+1 BRO !!!!
I really dont know why the **** iOS is that smooth, never noticed any lag on an Iphone. But you should think about that : Every Phone needs his own setup, caused of CPU, GPU and other things like ram and so on....
every iPhone got the same setup, optimized for iPhone 4 , iPhone 3GS and so one. They all got the same CPU and GPU, so they really can tweak every singe hardware.
Google just give us a source code, which every Company, Like Samsung or HTC have to port on their new device...
By the way, HTC got much better optimized Original Roms than Samsung. ( I have seen some OFW running on HTC Desire, and they are very smooth... )
lascoul said:
....
Before make effort to get more material ressources, is n't time for google to optimise his OS ?
.....
Click to expand...
Click to collapse
It is same way as MS passed: one simple question to you: how would you like to optimize the OS against HUNDREDS of available hardware combinations?
Of course, the Apple choice is easy and smooth: ONE hardware set, ONE OS.
similar was already done by Ford with model T: everyone could have it with favourite colour, as long as it was black. and now the ford position on global market is...
it's easy to optimize a software for 1 device but for 10000+ devices it's not that easy
dadyal said:
it's easy to optimize a software for 1 device but for 10000+ devices it's not that easy
Click to expand...
Click to collapse
If google doesn't optimise the OS. He may do it for his phones. take a look at the future Nexus prime it will get a dual core CPU. But don't think that is necessary if the OS is much optimise. The ipohne 4S had only a CPU at 800MHZ
spamtrash said:
It is same way as MS passed: one simple question to you: how would you like to optimize the OS against HUNDREDS of available hardware combinations?
Of course, the Apple choice is easy and smooth: ONE hardware set, ONE OS.
similar was already done by Ford with model T: everyone could have it with favourite colour, as long as it was black. and now the ford position on global market is...
Click to expand...
Click to collapse
But a think that the OS is not optimise for googles phones. Otherwise why will they use a dual core CPU in Nexus Prime?
I thought the difference in speed was because of the way they handled multitasking. It was only recently that iOS even had multitasking. But this is probably just a part of the reason why iOS is faster.
lascoul said:
If google doesn't optimise the OS. He may do it for his phones. take a look at the future Nexus prime it will get a dual core CPU. But don't think that is necessary if the OS is much optimise. The ipohne 4S had only a CPU at 800MHZ
Click to expand...
Click to collapse
iPhone 4S: 1 GHz dual-core ARM Cortex-A9 processor
They both have dual-cores.
Yea ios is optimized better. But it also doesn't have many basic features like android. Like a proper customizable homescreen with the ability to chose your launcher (no, lockscreen and an app tray are NOT an homescreen like apple has been trying to sell it), widgets, proper multitask, proper application integration, live wallpapers, lack of an external SD, etc. That makes for a lightweight system. You gain speed but lose features.
That said, granted, android needs to be generic. But as soon as a big company like samsung picks up android and starts developing to one device of their own making, this "1 OS for all devices" gap ceases to exist. Its 1 OS being optimized to a single piece hardware, and they have all they need for proper optimization.
This isn't the same as windows -> 1000 kinds of hardware. Windows comes prepared from Microsoft to run everywhere so that applies. Android doesn't come prepared to run everywhere from google. You can't simply just download and put it on your phone regardless of brand. Has an extra step of preparation from hardware developing companies like HTC or Samsung.
What i'm trying to say is, there is room for optimization. But companies don't care much because they are on a tight schedule on market competition to put out the next big thing, have hardware specs to compensate for poorly optimized coding and in the end stuff works just the same, since most people, sadly, won't notice or care that much for those extra delays/lags.
Can't speak for other brands, but Samsung proved with SGS they don't care much for good coding. The community has been, since its release, improving this phone leaps and bounds and continue to do so even though a successor has shown up.
At the end, companies don't care enough, imo.
kaynpayn said:
What i'm trying to say is, there is room for optimization. But companies don't care much because they are on a tight schedule on market competition to put out the next big thing, have hardware specs to compensate for poorly optimized coding and in the end stuff works just the same, since most people, sadly, won't notice or care that much for those extra delays/lags.
Can't speak for other brands, but Samsung proved with SGS they don't care much for good coding. The community has been, since its release, improving this phone leaps and bounds and continue to do so even though a successor has shown up.
At the end, companies don't care enough, imo.
Click to expand...
Click to collapse
i am aggre with u. The compagny must provide us much optimise Room before growing the specs of the phones.
lascoul said:
I am not Apple fanboy, but i think that Anddroid OS has a big optimisation problem.
For example the iphone 4S had a CPU 800 Mz and it seem to be real fast. But the latest Androphone plan to use Dual CPU. Is Android OS needed more ressources than iOS?
Before make effort to get more material ressources, is n't time for google to optimise his OS ?
Symbian was an OS whitch was too optimsed and i would like to have an Android OS like that.
Someones wouldnt like what i said but it is my deep think.
Click to expand...
Click to collapse
Iphones are smooth because iOS was designed to work on one device (technically, 9 devices if you count all the variants of iphones, ipads and ipods) only whereas Android has to work on hundreds of devices with different processors and hardware.
Also, iOS removes so many functionalities from the user, hence has more free ram.
disclaimernotice said:
Iphones are smooth because iOS was designed to work on one device (technically, 9 devices if you count all the variants of iphones, ipads and ipods) only whereas Android has to work on hundreds of devices with different processors and hardware.
Also, iOS removes so many functionalities from the user, hence has more free ram.
Click to expand...
Click to collapse
The job of compagnies like SAMSUNG, HTC ... isn't to optimise the OS for they devices? To say that there are more devices is not an apologizes
First step then should be: CLOSE the system. Lock it all, and after that, you can optimize system individually for each phone, completely separately. Another option is to push Samsung, HTC, LG, SE or whoever else to have SAME hardware configuration.
Then: you will loose:
- all custom ROMs, bootloaders, CWM, root, kernels;
- all customized versions of stock apk's, like phone, start screens, themes, Market etc.
- ANY ROM update will be available only after OFFICIAL release, through Kies.
Well, xda does pretty good work with optimization, while Android is kept OPEN, not locked, like iOS.
I personally prefer that it will continue this way.
---------- Post added at 06:40 PM ---------- Previous post was at 06:37 PM ----------
lascoul said:
The job of compagnies like SAMSUNG, HTC ... isn't to optimise the OS for they devices? To say that there are more devices is not an apologizes
Click to expand...
Click to collapse
??? Why are you stating that they are not doing this? But, one thing: DO NOT flash everything available here, but just stay with OFFICIALLY released ROM's, via Kies (in case of SGS).
For example: JVR, JVS, JVT ROM's are not officially released, and then any claim that the sys is not optimized is pointless.
Whilst the first post is correct regarding speed and optimisations they fail to realise that Apple have only their own hardware to work on, so they can really work it until its perfectly optimised.
Google have one device to work on, but multiple manufactures use their open source platform using different hardware, so its up to them to optimise the software for their hardware, not google.
You also failed to quote correct hardware specs for the iphone, which has dual core and I believe as much memory as the galaxy s2... So it does sound like your trying to bash android with incorrectly informed arguments.
Just to close the item, and to proof how optimised the IOS is, the recent update, iOS 5, caused vanishing of the music, files, messages, contacts, customised folders and applications for not very small group of users:
Brilliant iOS5 update, example 1
Error 3200 and 3004
3002, 3200, 3194
So, I think that the conclusion may be:
Apple has much more simple way to optimise their sys, because they have much less kind of hardware than Google.
But, Apple is not able to manage even so small amount of the hardware variations, and iPhone CAN go smoothly on its 2 cores CPU (yes, dear OP, read the specs more closely) if Apple will not mess the sys or its update... what just happened.
It's only multitasking problem.suspend and resume of iOS paid off better although you miss some features because of that but on all basic features it way better.
I always wonder why dialer and messaging apps sent out of memory,they should have been kept in memory like browser.
We shouldn't be nagging much about it as things can be done by Android are much more.
Sent from my GT-I9000 using Tapatalk
I can't predict the future of course, but it is not unlikely we will see some performance increase with ICS.
I would deem it likely that ICS will use HC's memory manager which is definitely faster than GBs, especially when used with programs that are massive memory hogs. HC's still constantly frees memory it doesn't need to free though ( == waste of cycles), so there is still room for improvement there, let's hope ICS brings it.
Likewise, UI hardware acceleration is already better in HC than it was in GB, and it is rumored to be further improved in ICS. If that is true, ICS devices will likely seem much more fluent. It doesn't actually make them faster, but it will look that way.
In the end, iOS is much more optimized than Android, but ICS should be a good step in the right direction. It will probably not bring the optimization to an iOS level, though.
kaynpayn said:
Yea ios is optimized better. But it also doesn't have many basic features like android. Like a proper customizable homescreen with the ability to chose your launcher (no, lockscreen and an app tray are NOT an homescreen like apple has been trying to sell it), widgets, proper multitask, proper application integration, live wallpapers, lack of an external SD, etc. That makes for a lightweight system. You gain speed but lose features.
That said, granted, android needs to be generic. But as soon as a big company like samsung picks up android and starts developing to one device of their own making, this "1 OS for all devices" gap ceases to exist. Its 1 OS being optimized to a single piece hardware, and they have all they need for proper optimization.
This isn't the same as windows -> 1000 kinds of hardware. Windows comes prepared from Microsoft to run everywhere so that applies. Android doesn't come prepared to run everywhere from google. You can't simply just download and put it on your phone regardless of brand. Has an extra step of preparation from hardware developing companies like HTC or Samsung.
What i'm trying to say is, there is room for optimization. But companies don't care much because they are on a tight schedule on market competition to put out the next big thing, have hardware specs to compensate for poorly optimized coding and in the end stuff works just the same, since most people, sadly, won't notice or care that much for those extra delays/lags.
Can't speak for other brands, but Samsung proved with SGS they don't care much for good coding. The community has been, since its release, improving this phone leaps and bounds and continue to do so even though a successor has shown up.
At the end, companies don't care enough, imo.
Click to expand...
Click to collapse
Disable to slight extent. I felt that Samsung have done something to the ROMs they provide for SGS. Example the old RFS filesystem, lags like hell in the past but feels good now. Im using RFS instead of EXT4. Still, I have to agree, they don't care much on good coding, new phones are coming up, why bother? The community makes it happen
Apple hires a ton of CPU architects solely for this purpose. Apple prioritizes fluency and optimization above features and openness.
Just a different strategy, no better, no worse.
Sent from my GT-I9000 using xda premium
My mate has the latest iPhone his wife had the SGSII, I had the chance to compare them both side by side last night. What can I say except the SGS is larger, faster, smoother, has more apps, more customisable, the difference is amazing. The iPhone is like
a kiddies toy compared to the SGS.
Remember that the iPhone has been going a lot longer than Android, yet Android had had voice recognition for over a year. Enough said
Sent using TCP/IP
I've got a question... Any plans to implement the new Android-friendly Bluez stack recently rolled out? Seems it would fit with your open-source goals pretty nicely, while also providing enhanced functionality over the status quo...
Sometime last year there were several reports of a successful PulseAudio port as well. As I recall, it offered performance and feature enhancements, though the final word I've seen on the port was a sort of an open-source compromise because the port still required interaction with the closed-source HAL.
Anyway, it seems to me that successful inlines of the above projects might even be incorporated at least in part upstream, thereby setting you apart in your contributions, your feature set, and helping to offload some of the work for both sides.
Also, I want those things.
-Mike
mikeserv said:
I've got a question... Any plans to implement the new Android-friendly Bluez stack recently rolled out? Seems it would fit with your open-source goals pretty nicely, while also providing enhanced functionality over the status quo...
Sometime last year there were several reports of a successful PulseAudio port as well. As I recall, it offered performance and feature enhancements, though the final word I've seen on the port was a sort of an open-source compromise because the port still required interaction with the closed-source HAL.
Anyway, it seems to me that successful inlines of the above projects might even be incorporated at least in part upstream, thereby setting you apart in your contributions, your feature set, and helping to offload some of the work for both sides.
Also, I want those things.
-Mike
Click to expand...
Click to collapse
Well, the existing Android bluetooth stack is also open source, so the question would be what this "new" BlueZ stack (which isn't new, Android used BlueZ for years and switched away with 4.1 or 4.2, can't remember...) offers.
For audio - We have open HALs for a lot of devices, and for those devices we don't have an open HAL for, pulseaudio won't really help.
Entropy512 said:
Well, the existing Android bluetooth stack is also open source, so the question would be what this "new" BlueZ stack (which isn't new, Android used BlueZ for years and switched away with 4.1 or 4.2, can't remember...) offers.
For audio - We have open HALs for a lot of devices, and for those devices we don't have an open HAL for, pulseaudio won't really help.
Click to expand...
Click to collapse
But the existing Bluetooth stack is Android specific, whereas Bluez is a standard Linux component. It's also just recently made itself more Android friendly and (arguably) provides a better documented, more standardized interface.The same can be said of PulseAudio versus Android's sound daemon; implementing either or both would provide for more ease of interoperability between Android and other Linux devices, diminish Android fragmentation, and relieve some of the strain imposed by redundant development. What's more, I think both of these goals are probably largely achievable, but I was just asking.
Also, I want those things.
-Mike
mikeserv said:
But the existing Bluetooth stack is Android specific, whereas Bluez is a standard Linux component. It's also just recently made itself more Android friendly and (arguably) provides a better documented, more standardized interface.The same can be said of PulseAudio versus Android's sound daemon; implementing either or both would provide for more ease of interoperability between Android and other Linux devices, diminish Android fragmentation, and relieve some of the strain imposed by redundant development. What's more, I think both of these goals are probably largely achievable, but I was just asking.
Also, I want those things.
-Mike
Click to expand...
Click to collapse
Well, BlueZ was the default Android stack for quite some time - it was dropped for whatever reason. So not sure why they need to make it more "android friendly" when it was part of Android for a few years.
As to PulseAudio - it's a consistent bane of my existence on the desktop, and is probably overkill for mobile.
Of course, if you want to take a crack at integrating them and actually find that they do have tangible benefits, give it a try!
Entropy512 said:
Well, BlueZ was the default Android stack for quite some time - it was dropped for whatever reason. So not sure why they need to make it more "android friendly" when it was part of Android for a few years.
As to PulseAudio - it's a consistent bane of my existence on the desktop, and is probably overkill for mobile.
Of course, if you want to take a crack at integrating them and actually find that they do have tangible benefits, give it a try!
Click to expand...
Click to collapse
Wow. Strong words. You consider PulseAudio an existential bane, huh? Can I ask what sound daemon you use instead? I suppose it's possible you do without. Though it seems OSS is entirely deprecated, ALSA can still provide minimal functionality without a user-space management daemon if necessary, but without some extensive and, at least to me, seemingly esoteric initial configurations, good luck handling even a lasting volume adjustment without root access (or be in the "sound' group, I suppose), and should you have occasion to simultaneously offer two applications sound privileges... Sorry, grinding my teeth again.
Anyway, I didn't much like PA at first either, but I wanna say my first encounter with it was Ubuntu 7.10 or so, or thereabouts. I've since adopted the greener pastures offerred by several other distributions, less brown anyway, but PulseAudio is a fairly static component of my sound system as configured by default by distro maintainers no matter where I wander. Even on systems I build up myself from very little, when PulseAudio is included it tends to be one the things I have to consider least as trouble goes. The plugin support is very extensive these days as well.
When PulseAudio is combined with Bluez for instance, it can emulate almost all of the headset profiles, to include a telecommunications headset, and can easily record from this stream or any other because every one of PA's sources can be easily multiplexed. It's fun, and very powerful. PA can do on cheap or even no dedicated hardware at all what Airplay only aspires to. And these days, it even makes it easy. It's a true sound server, and while it can be utilized simply enough with Android satellite clients if you set it to emulate Airplay, to serve a multi/unicast, and/or to emulate the DLNA protocol, even this impressive scope of functionality is much diminished when compared to two PA servers working in concert.
Other desktop alternatives do exist, of course. There's Jack, designed to provide low-latency, realtime audio rendering, but these days it seems it too seems to operate best, and is most often configured to do so by default, in conjunction with a PA daemon. And MPD of course, which I confess I have much interest in, but very little other incentive otherwise to actually try for myself. I don't actually known what it's capable of. Perhaps you do? I wonder, is it just, as is eponymously implied, a music player daemon? Or can it actually be extended to do the kinds of things I've come to expect of PA as hinted at above? I really should find out.
Anyway, if you haven't had a look at this, it might interest you: http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/
The author takes care to provide many impressive benchmarking results as proof of the worth of his efforts. If that sparks your interest, you'll find the Android port homepage here: http://www.freedesktop.org/wiki/Software/PulseAudio/Ports/Android/.
And try to remember that PulseAudio is a more mature and proven project than is Android itself, much less SoundFlinger, and each of these three could be said to have experienced some rather rocky starts.
As for the Bluez project being recently dropped from Android and its even more recent Android-focused development, I believe these things are likely just as related as they appear to be. I would have to dig deeper than scanning a few kernel changelogs to be sure, but as I understand it for about a year or two, Bluez has been undergoing a codebase overhaul. I expect that in such a scenario the Linux kernel's default Bluetooth stack would have to focus initial efforts on the Linux kernel's core x86 support, and especially providing ARM support would prove difficult due to its lack of a default firmware interface and handling the myriad hardware access mechanisms might just have been too much at the time. Again, these are my assumptions, but what has definitely happened recently is a concerted effort at full Android support. If my assumptions are correct, then probably the Bluez project just got caught up is all. In any case, the functionality Bluez provides, especially where networking transparency is concerned, is definitely superior. Find out for yourself if you'd like to know.
Surely I'll find out for myself soon, as I guess i'll be diving in after all. Never built Android from source before, which doesn't make much sense as I've had nothing but Android devices since my G1, every one of which, up to and including the Dream, was rooted and flashed with at least a replacement recovery pretty much on day one. I guess better late than never, though.
Back soon, I expect! Best wishes!
-Mike
I still use it because I really don't want to spend all the time ripping it out and replacing it with something else on my Ubuntu machines, but it consistently fails to operate properly on nearly every machine I have. It's way too complex and the end result is that it breaks all the time.
That said, because of my experiences with it, I will never personally put any effort into putting it into more places. It is in too many already.
*edit of this mistakenly resulted in double-post below*
Entropy512 said:
I still use it because I really don't want to spend all the time ripping it out and replacing it with something else on my Ubuntu machines, but it consistently fails to operate properly on nearly every machine I have. It's way too complex and the end result is that it breaks all the time.
That said, because of my experiences with it, I will never personally put any effort into putting it into more places. It is in too many already.
Click to expand...
Click to collapse
Maybe that's true, but if you asked me I'd probably lean the other way and say instead that Ubuntu is in too many places. Honestly, PA is really not complicated if you consider it a suite of core sound apps as opposed to a single, cohesive application. Probably my biggest gripe with Ubuntu's interfaces is that they often do the opposite, which is of course contrary to Unix principles, and in the process they tend to sort of opaque over simple and accessible modular designs.
I won't attempt to argue that PulseAudio is simple by design, as we both know I'd be certain to lose that argument, but it does offer a few lesser known interfaces you might find interesting. For instance, one of my favorite little tools is pacat. This does exactly what it sounds like; point it at one or more of PA's sources and it will concatenate their raw audio output into stdout at which point you are free to pipeline it as you would any other stream. Imagine you took pacat, perhaps also lz4, nc, and another little pipe-friendly PA tool called paplay directed at a PA sync on its system rather than a source, and combined them all into a pipeline. I hope in this you might begin to see some of PA's merits that perhaps you've missed before.
Also, there is pacmd, which is not nearly as straightforward as those others I've mentioned, but is far more capable and very well documented. It can do anything PA can do, really, and is fully scriptable.
I don't know which versions of Ubuntu you use, but those not on rolling releases may not yet have caught up to the PA update that implemented a PulseAudio-module-specific udev adaptation. Newer PA versions now pretty much auto-configure audio modules in the same way early user-space handles kernel-module loading. It's kinda cool, and almost an entirely hands-off process.
Anyway, I'm through proselytizing. I just thought I'd mention these things because they're the bits that I use when I want to do something with it.
EDIT:
Entropy512 said:
...because of my experiences with it, I will never personally put any effort into putting it into more places...
Click to expand...
Click to collapse
I looked again and noticed this. While I fully understand where you're coming from here, I thought I heard some French kid on YouTube say that this was not the sort of response that should be expected for OmniRom feature requests. He described a sort of democratically driven road map, and specifically he said that if a feature request was well enough supported by the users, then the developers would implement it even if they did not agree it should be done. Has this policy changed?
Of course I realize that youtube guy was probably talking about majority rule as opposed to a well-argued request, and that I'm only one person, but above you say you will never do this thing, without making any allowances for the possibility of a vote or poll or similar.
Like I say, I fully understand your position on this, as I, of course, do not intend to devote my own efforts to something like further Android fragmentation for instance, vote or no vote. I just wish to know what to expect here, and if maybe I missed something.
-Mike
Everyone on the project are volunteers. Time is a limited resource, and we tend to prefer working on things we enjoy since we're not getting paid for it.
There's a big difference between "I have no interest whatsoever in working on this myself" and "I hate this so much I will mercilessly -2 it without any discussion". The latter is what I've promised never to do.
If someone's going to implement a feature, I'm OK with that as long as it doesn't have significant negative impacts (which PA would likely have, but I'll give it the benefit of the doubt...), I'll even give them some tips/assistance.
However, given the pain and suffering I went through with the yamahell audio HAL, touching audio again if I don't have to is dead last on my priorities list.
Looking at your link - it seems like nearly any advantage PA might have would only be seen by commandline clients - All apps would have to be presented with something that is "audioflinger-like" which didn't offer the extra features offered to clients. Also, PA claims improved power consumption - but they actually likely do not support LPA or tunnel mode.
To me it looks like PA offers a huge integration effort for little to no actual benefit.
Also, that article was written in January 2012 - I can tell you for certain that Google made MAJOR changes to the audio setup with Jellybean in mid-2012 including the ability to select buffer configurations that are use-case-dependent - https://github.com/omnirom/android_...210153d8f19a0ca825b33f2282b9ae071c6ec#diff-11
Entropy512 said:
Everyone on the project are volunteers. Time is a limited resource, and we tend to prefer working on things we enjoy since we're not getting paid for it.
There's a big difference between "I have no interest whatsoever in working on this myself" and "I hate this so much I will mercilessly -2 it without any discussion". The latter is what I've promised never to do.
If someone's going to implement a feature, I'm OK with that as long as it doesn't have significant negative impacts (which PA would likely have, but I'll give it the benefit of the doubt...), I'll even give them some tips/assistance.
However, given the pain and suffering I went through with the yamahell audio HAL, touching audio again if I don't have to is dead last on my priorities list.
Click to expand...
Click to collapse
Wow, man! Thanks very much indeed for replying with honesty and humility. I'm very pleased that I didn't, or at least I hope I did not. Even if you had said otherwise I would have fully understood, of course, but as it is, I'm also very impressed. I like discussion. Thanks, man.
Two questions: what's yamahell? And, because you say you've worked with it, can you tell me about AudioFlinger or whatever it is and maybe why the status quo is desirable? I thought it was a problem. I'm asking these things for my own edification and because I think I'm gonna try something to do with a PA replacement.
While I agree PA may be overkill, I really don't believe pulse has to be applied monolithically, you know? It's already designed to work with modules, so maybe a subset would be sufficient. Clients only communicate with libpulse.so for the most part, for example. And for the past few months (on an upstream system) PA and Bz have been working really well together. So I'll try it, maybe, after you tell your horror stories and I can judge for myself.
-Mike
-
Entropy512 said:
Looking at your link - it seems like nearly any advantage PA might have would only be seen by commandline clients...
Click to expand...
Click to collapse
I assume you mean the first one, the blog on the initial port? Well, I believe that may have changed since then. The actual port homepage at freedesktop.org (the second link I provided) says this:
Code:
...[T]ested on Samsung/Google Galaxy Nexus as ... reference implementation... [P]ort fairly straight-forward for ... devices with ALSA support.
Various bits of functionality are available, and this is a moving target. The following are tested at the time of writing this section:
Audio playback for most apps using native Android APIs
Volume control
Switching of outputs depending on the device plugged in (headphones, headset)
To Be Done
The following pieces are either partially or not at all implemented
Audio playback API completeness: infrequently-used bits of the API (loops, markers, etc.) are not implemented
***BIG ONE*** Calls: this is work-in-progress, but needs to be cleaned and merged
Policy: initial implementations of volumes and port switching are done. There are probably a lot of bits of policy that still need to be implemented for us to have feature/bug-parity with standard Android.
Audio record API: can be implemented fairly easily like the playback API was
***NOT CLEAR ON THIS*** Audio effects API (we don't support this in PulseAudio at the moment)
Entropy512 said:
Also, PA claims improved power consumption - but they actually likely do not support LPA or tunnel mode.
Click to expand...
Click to collapse
Something tells me this is a statement I should be able to fully comprehend before getting neck deep...
Entropy512 said:
To me it looks like PA offers a huge integration effort for little to no actual benefit.
Click to expand...
Click to collapse
It doesn't look so huge to me, as much is already done, I think. But then I've to hear your horror stories so I will reserve judgement.
Entropy512 said:
Also, that article was written in January 2012 - I can tell you for certain that Google made MAJOR changes to the audio setup with Jellybean in mid-2012 including the ability to select buffer configurations that are use-case-dependent - https://github.com/omnirom/android_...210153d8f19a0ca825b33f2282b9ae071c6ec#diff-11
Click to expand...
Click to collapse
Yes, that article was written then, but the freedesktop.org homepage was created March of this year. I suspect some changes have accumulated along the way, and because PA is an actively developed high-profile application hosted and backed by RedHat, I expect that website landing page would be removed soon after it became irrelevant. I will, of course, reach out to the maintainers at that end as well for advice.
But... that's kind of the point... less redundancy, you know? Less fragmentation? No need for separate groups for thisnkind of stuff. I just thought that was inline with omni ideals. Is there another way that you know of that could as easily bring a like convergence of functionality with other Linux systems? I just wanted to effect something along those lines and I thought omni sounded like a place worth starting.
Also, I want those things.
-Mike
P.S. This is the git repo described in the .XML repo definition for the PA build-code at freedesktop.org: http://cgit.collabora.com/git/
You can see the android specific PA packages are being worked on, and very recently. Also, ALSA is seeing somewhat recent dev work as well.
EDIT: This may not even be quite as difficult as i initially assumed.You can also see at the following git repo that a commit was made to master referencing 'mako' 5 weeks ago.
http://cgit.collabora.com/git/android/platform/external/collabora/pulseaudio-android.git/
yamahell - the hell that was working with the Yamaha MC1N2 codec seen on many Galaxy S2 family devices.
Poorly documented, kernel code written by a member of a primitive tribe with no concept of zero, Samsung's blob HALs doing all sorts of unpredictable crap requiring workaorunds and hacks...
One of the things that the Android audio subsystem has (overall) great support for is hardware accelerated decoding of compressed audio. LPA and tunnel mode are both methods for doing hardware accelerated audio decoding even when the host CPU is asleep.
The closest analog to this in the PC world would really be AC3 passthrough to an external decoder - which happens to be where 90% of my hatred of PulseAudio comes from. Its usual response to AC3 passthrough switching on/off is to screw up the audio codec and do weird stuff like pass AC3 through but not set the "this is a bitstream and not raw audio" bit, or send raw audio when setting the "this is a compressed bitstream" bit.
Entropy512 said:
...no concept of zero...
Click to expand...
Click to collapse
....should I?
Entropy512 said:
One of the things that the Android audio subsystem has (overall) great support for is hardware accelerated decoding of compressed audio. LPA and tunnel mode are both methods for doing hardware accelerated audio decoding even when the host CPU is asleep.
The closest analog to this in the PC world would really be AC3 passthrough to an external decoder - which happens to be where 90% of my hatred of PulseAudio comes from. Its usual response to AC3 passthrough switching on/off is to screw up the audio codec and do weird stuff like pass AC3 through but not set the "this is a bitstream and not raw audio" bit, or send raw audio when setting the "this is a compressed bitstream" bit.
Click to expand...
Click to collapse
This makes very good sense. While I think the PA 4.0 changeligs from July or so may acknowledge this lack they also seem to indicate it's been addressed. Would you mind looking? Not positive I'm reading it right.
-Mike
This might help people eyeing the Z4 Tablet, but are unsure of what positives and negatives there are. Of course, this is highly subjective, but this is my list. It's influenced by my personal competing choices which were the Samsung Galaxy Tab S2 and the Google Pixel C. I'm happy I chose the Sony Xperia Z4 Tablet.
Pros:
Fast SoC (Qualcomm Snapdragon 810)
This is Qualcomm's 2015 flagship SoC and from what I've experienced it's really fast. Android flies. It also runs 64-bit, which it should anyway, but for example Samsung's Tab S2 doesn't. I don't know about the graphical performance as I don't really play games.
'Compatible' SoC (Qualcomm Snapdragon 810)
This opens up the way for optimized-for-specific-SoC apps (like RSBrowser, which is Snapdragon-optimized and significantly faster than stock Chrome/Chromium) and CyanogenMod support, that need documentation/drivers. For example, Samsung's (faster) Exynos SoC's are a black box for developers, which makes things like this very hard and has the result of devs abandoning it.
Big internal storage (32GB)
32GB is plenty of storage for apps and a reasonable amount of media. But that can be stored on the microSD.
microSD capability (up to 128GB)
This is a major benefit for a media consumption device like this, which many devices don't have.
Good multitasking
I could have mentioned 3GB RAM, but that doesn't tell the whole story. Multitasking on the Z4 is pretty darn good. It swtiches quickly and is generally very snappy. My Samsung Galaxy S6 with 3GB RAM has pretty bad RAM management in comparison. I'm still trying to find a custom kernel for it that keeps the phone snappy after 2 days.
Huge screen solution, high ppi on a big screen
2560x1600, 299ppi. On a big 10.1 inch screen. This is wonderful.
16:10 aspect ratio screen
Which is good for widescreen content like movies and dSLR photo's. 16:10 also beats 16:9 for me because of the added screen height.
Screen has natural, accurate colors
Very subjective, but compared to several other screens I've found this one to be superior.
Front facing stereo speakers
A rare thing among Android devices. Good design choice.
Lightweight (~390gr), thin
It's pleasantly light to hold.
NFC, notification LED, GPS, vibration motor
These features are often overlooked, but are important to me. I use NFC for LastPass, the (multicolor!) LED with LightFlow to see what exactly is asking my attention when in standby, vibration to still be notified when I want the tablet to be silent and GPS for the occasional navigation need or social app check-in.
Qualcomm Quick Charge 2.0
Another nice bonus, which isn't mentioned much. Quick Charge makes a major difference to charging speed. Needs a compatible charger though.
Big battery (6000mAh)
Can't yet say battery life is amazing, because I'm using it a lot and crank the screen brightness up quite high so don't know what to expect. Reviewers seem to agree it's great though.
Bootloader can be unlocked (so the road is open for rooting)
No waiting for an exploit if you're OK with going this route. Just follow Sony's instructions and you'll have root in no time.
Marshmallow announced
Should come January '16 I heard, but these things always get delayed :| At least it's coming.
AOSP commitment by Sony
Sony's Open Device Program is nice and all, but their sources are a bit troublesome and don't seem to produce functional ROMs. Still, Sony's stance on it might bode well for future things.
Water-/dustproof
I don't care much myself, but it's a nice bonus. At least it takes some worries away (dropping liquids on it, no fear for dust particles between the screen and the glass).
Keyboard dock option
Nice for when you want to use a physical keyboard that is fully compatible and is also attachable. I use a 3rd party BT keyboard, but I'm constantly fighting with fixing incompatible button mapping stuff.
Important root-specific things that work
These things are not guaranteed to work or be available on any rooted device, and are pretty major in adding possibilities, so I consider them pros to be working on the Z4T:
Xposed Framework
For most people anyway (Some are having issues). This is a thing to be happy about, because if it didn't, chances are it wouldn't be fixed anytime soon because of the small user/dev base. Xposed opens up many possibilities which really enhance a device. To me it's a selling point.
Native KCAL support
Another Qualcomm exclusive. I believe this is actually fully present on the stock ROM, but not fully controllable (limited to RGB in the Settings menu). KCAL support enables you to tweak various image parameters, like RGB, saturation and contrast with a tool like Color Control or Kernel Adiutor. It's pretty great and you don't see it often.
Cons:
SoC might overheat in extreme circumstances
Haven't had any problems myself, and I stress the tablet pretty hard, but I've read some reports about issues. At least of a guy bringing the tablet to the beach. It's mostly just people saying it's fine, even with heavy usage.
Speakers are lacking in bass
No surprise, but it's still a letdown.
Bad low-light camera performance, no flash
Picture quality in low light is disturbingly bad. Having no flash makes this unusable in those situations. Not a big deal for me personally, I don't take pics with a tablet.
Screen isn't that bright
Compared to several others, the screen isn't that bright and needs to be cranked up pretty much, even indoors. Outdoors, this is a problem. The big screen reflectiveness doesn't help either. Indoors it fine, it just that the needed high brightness level eats battery.
Screen lacks deep blacks
This is compared to (S)AMOLED, specifically. Those screen blacks are amazing and darker colors are also good for battery on those screens. IPS screens just don't have that. Using dark themes won't help battery life on the Z4T, it may even be worse with them.
Stock charger isn't Quick Charge 2.0
Come on, Sony.
No hardware navigation buttons
This is a real PITA for me because this requires Android's soft keys / navigation bar which take up valuable screen space. This is especially problematic in landscape mode on this 16:10 ratio in which you'll want every screen height you can get. Fortunately, this can be overcome by tools like GMD Full Screen Immersive Mode (with full screen keyboard typing restrictions so you'll have to switch back to type :S) combined with All in One Gestures, both of which don't reqquire root. Better yet is a build.prop edit that declares to Android the tablet has hardware buttons, removing the soft keys entirely, while keeping the ability to type anywhere. I navigate using All in One Gestures, because GMD GestureControl sometimes stops working. Which isn't very nice when you don't have navigation keys
No user-land root exploit (yet)
Because of this, you'll need to unlock the bootloader to gain root access. Which will destroy your TA partition, which will in turn remove Sony-proprietary functions. Which I personally don't use and don't see much use for anyway. Also, unlocked bootloader can't be undone without Sony noticing, so as a non-EU citizen you'll possibly have warranty issues.
Small user/dev community
Not many people own a Z4 Tablet (bad availability in the US and it's expensive) and because of this, there's next to no development for it. Luckily, we have @AndroPlus who's made a custom kernel and ported TWRP (which unfortunately has a bug that keeps us from restoring the system partition from a backup). @DHGE worked on root, which made it possible in the end I think. Still, custom ROMs would be nice. Also, if you run into device-specific problems, there's not many others that can help, because you're either the only one or one of very few who have that problem.
It's expensive
The price is very high and a bit hard to justify.
What I miss:
Wireless charging
This is sooo convenient. It also spares the precious MicroUSB port, which is used for charging, data-transfer, USB-OTG and adb/fastboot. If it breaks, you're done.
Removable battery
Batteries do not have eternal life, so eventually it will be completely dead. Which will render the tablet dead as well.
Any thoughts, questions, additions or critique is welcome.
jelbo said:
[*]Small user/dev community
Not many people own a Z4 Tablet (bad availability in the US and it's expensive) and because of this, there's next to no development for it. Luckily, we have @AndroPlus who's made a custom kernel and ported TWRP (which unfortunately had a bug that keeps us from restoring the system partition from a backup). @DHGE worked on root, which made it possible in the end I think. Still, custom ROMs would be nice. Also, if you run into device-specific problems, there's not many others that can help, because you're either the only one or one of very few that have that problem.
.
Click to expand...
Click to collapse
Hello jelbo. Let's discuss about it. First of all, our tablet is not alone with some sort of problem. z3+ and z5 devices are the same story. I don't really understand how can we have aosp sources but not to have its rom. So what the problem, some building problem, or is it true that aosp roms works without working sensors? People give different feedback. Did you try some aosp rom? I just want to cook aosp rom in ubuntu.
alex009988 said:
Hello jelbo. Let's discuss about it. First of all, our tablet is not alone with some sort of problem. z3+ and z5 devices are the same story.
Click to expand...
Click to collapse
Yes, they're similar. Which actually makes me think about a positive point as development for those devices can also benefit Z4T owners. For example @[NUT]'s efforts may eventually reach us, or when an Xperia user-land exploit is found, it will likely be shared among different devices.
I don't really understand how can we have aosp sources but not to have its rom. So what the problem, some building problem, or is it true that aosp roms works without working sensors? People give different feedback. Did you try some aosp rom? I just want to cook aosp rom in ubuntu.
Click to expand...
Click to collapse
I'm not too sure about the reasons, but what I've seen is that 1) the Sony sources are/have been a bit buggy/messy 2) not many people compile ROMs from it (I've only seen 2 XDA users and the FXP Team).
I haven't yet dared to flash any AOSP build because I've been too busy on getting stock rooted to my liking and troubleshooting my Xposed issues and I don't want to interrupt that. It seems to be quite easy to flash ROMs though, it's either a TWRP flashable .zip, Flashtool flashable .tft or fastboot flashable .bin files.
I'm also curious about the mixed reports about 'sensor stuff not working' and 'everything works fine' on Sony-sourced AOSP builds, but so far no-one has answered my or your questions about it. Seems we'll have too find out ourselves at some point Best leave that part of questions and discussion in their respective threads to keep things organized.
Nice summary, thanks for the effort; its clear and concise.
jelbo said:
it's either a TWRP flashable .zip,
Click to expand...
Click to collapse
I think free xperia team jeer at us cause twrp has a serious bug and it can't flash any roms for the time being whereas we can see exactly .zips at their site.
Interesting, had they even tested themselves what they uploaded
jelbo said:
Yes, they're similar. Which actually makes me think about a positive point as development for those devices can also benefit Z4T owners. For example @[NUT]'s efforts may eventually reach us, or when an Xperia user-land exploit is found, it will likely be shared among different devices.
Click to expand...
Click to collapse
I've put XZDualRecovery on 'feature freeze' for 2.8 well over a year ago, because it needs some work to keep it working on the ever changing Android eco-system. As a consequence, I also stopped adding devices to the supported devices list. For XZDR 2.9 things will change and I will start adding devices again, remember that I am just on my own, from time to time I have a helper but they generally drop out after a while and I'm on my own again after that... I have a busy real life and a very busy job, which consumes most of my energy, leaving only little amounts of it for use on the XZDR development unfortunately... and I have big plans with it which I'd rather deploy sooner then later.
As security features increase, so do the difficulties to keep XZDR working properly... For the Z3+/Z4/Z5/M4 Aqua it is dm-verity, which throws a tantrum once the system partition is modified, which in turn causes a reboot (and with that a bootloop). This behavior has hampered the Stock Based custom ROM development and made it generally impossible to root the device...
A backup-ta with a built-in root exploit (similar to the XZDR installer) to allow a backup of the TA partition would kick-start the development for these models. People don't mind unlocking their devices but do mind losing their warranty on a 500-700 euro device... so most of them wait for the possibility to backup their TA partition.
Oh, and to actually participate in this topic:
I have to say the Z4 tablet takes my fancy and tics just about all the boxes of things I like about tablets... I own a Xperia Tablet Z, well, the misses has it now and I can 'occasionally' touch it :silly: and I have been looking for a new tablet to actually use myself
I don't have the funds to purchase a TabZ4, but I would really like to have one with the keyboard dock
[NUT] said:
Oh, and to actually participate in this topic:
I have to say the Z4 tablet takes my fancy and tics just about all the boxes of things I like about tablets... I own a Xperia Tablet Z, well, the misses has it now and I can 'occasionally' touch it :silly: and I have been looking for a new tablet to actually use myself
I don't have the funds to purchase a TabZ4, but I would really like to have one with the keyboard dock
Click to expand...
Click to collapse
Hello. Thanks for participating our thread. Tab Z4 is a great device with cool hardware, but it is less developed in comparison with Samsung to my regret. All we want for this moment are a fix of bug for twrp, problem with mounting the system, and some customs roms. And the very big dream is cyanogenmod of course
@jelbo, where in NL do you live? Did you root your TabZ4 yet?
---------- Post added at 02:28 PM ---------- Previous post was at 02:26 PM ----------
alex009988 said:
Hello. Thanks for participating our thread. Tab Z4 is a great device with cool hardware, but it is less developed in comparison with Samsung to my regret. All we want for this moment are a fix of bug for twrp, problem with mounting the system, and some customs roms. And the very big dream is cyanogenmod of course
Click to expand...
Click to collapse
Well, I am assuming that custom ROM's will come as soon as there is a viable way to flash them
I wonder why @AndroPlus wasn't able to fix the TWRP mount issues yet...
alex009988 said:
Hello. Thanks for participating our thread. Tab Z4 is a great device with cool hardware, but it is less developed in comparison with Samsung to my regret. All we want for this moment are a fix of bug for twrp, problem with mounting the system, and some customs roms. And the very big dream is cyanogenmod of course
Click to expand...
Click to collapse
I'm pretty confident CM will support the 'karin' at some point. Many other Sony phones/tablets are officially supported.
[NUT] said:
@jelbo, where in NL do you live? Did you root your TabZ4 yet?
Click to expand...
Click to collapse
I'll tell you in a PM Yeah, I've unlocked my bootloader and rooted it. I couldn't restrain myself anymore It's so much better now. Just some littles gripes left that'll be fixed sooner or later.
Well, I am assuming that custom ROM's will come as soon as there is a viable way to flash them
I wonder why @AndroPlus wasn't able to fix the TWRP mount issues yet...
Click to expand...
Click to collapse
Time restraints, who knows? He did post a v11 version of the kernel some days ago though @dl12345 who greatly helped him getting TWRP to work, may be able to fix it, but he hasn't been around. You can follow some technical details about it in the AndroPlusKernel thread.
It's just /system/ that cannot be restored though. Which is bad, but you can get out of a bad situation pretty quickly with restoring /data/ and using Helium/Titanium Backup, I think. Unless you really fried the ROM and need your /system/ back, then you can only go the flashtool route now
jelbo said:
I'm pretty confident CM will support the 'karin' at some point. Many other Sony phones/tablets are officially supported.
I'll tell you in a PM Yeah, I've unlocked my bootloader and rooted it. I couldn't restrain myself anymore It's so much better now. Just some littles gripes left that'll be fixed sooner or later.
Time restraints, who knows? He did post a v11 version of the kernel some days ago though @dl12345 who greatly helped him getting TWRP to work, may be able to fix it, but he hasn't been around. You can follow some technical details about it in the AndroPlusKernel thread.
It's just /system/ that cannot be restored though. Which is bad, but you can get out of a bad situation pretty quickly with restoring /data/ and using Helium/Titanium Backup, I think. Unless you really fried the ROM and need your /system/ back, then you can only go the flashtool route now
Click to expand...
Click to collapse
* [NUT] pokes @AndroPlus to join this conversation.
Due to lack of time on my side to read the entire topic, what exactly fails when restoring system?
@jelbo, do you have his kernel installed (a.k.a. have you unlocked your bootloader)?
[NUT] said:
* [NUT] pokes @AndroPlus to join this conversation.
Due to lack of time on my side to read the entire topic, what exactly fails when restoring system?
@jelbo, do you have his kernel installed (a.k.a. have you unlocked your bootloader)?
Click to expand...
Click to collapse
Yes and yes. Basically anyone here who's rooted their tablet is running AndoPlusKernel and have manually unlocked their bootloader.
jelbo said:
Yes and yes. Basically anyone here who's rooted their tablet is running AndoPlusKernel and have manually unlocked their bootloader.
Click to expand...
Click to collapse
I see, that un-complicates testing a lot
Gotta say... amazing tablet all together and the first device that i havent seen the mighty snapdragon handwarmer throttle from heat in. I kept roasting it for about 3 hours with simpleplanes and PC minecraft (boardwalk app) and it didnt lose any performance just got a bit hot on the back middle. I find the battery life to be good enough for a day of being on and off watching youtube and occasional gaming but i do keep screen brightness on auto at all times and features such as BT NFC and GPS off. Also a app that i think the tablet should have from factory: OGYoutube, you can have floating resizeable youtube above other apps or play in background or with screen off and download in mp4 or mp3.
I'd picked up a Z4T about 4 months ago to replace two different devices, my aging and finally dead cell phone (I hung on to my old Samsung S3 for way too long), and my laptop, which is a still functional but extraordinarily heavy beast of a 17" macbook - about 6 years old on its own as well. What can I say, they were still working so why buy new?
I have to say I'm very glad I made the purchase. I picked up a SBH52 handset to make phone calls more convenient, and splurged on the sony docking kb for the added ruggedness of using it as a "case" - which it does like a champ. Calls are nice and clear, and I've had pretty much no troubles - aside from some occasional static when using the handset (which I owe to the handset itself being a bit flaky). Even with an unlocked BL, remote play on my PS4 still works, only the Bravia screen mirroring to my TV is kaput. It serves very well as a laptop for those like me that need something lightweight for overnight trips, let with a big enough screen to be able to remote desktop troubleshoot back to the main office.
Would this replace every computer I own? Obviously not. I still own a high end desktop for videos, games, and intense word processing (the sony kb is just a bit small if you were attempting to write a novel for example); and my PS4 for console games; but for light end use and for traveling, it's almost the perfect laptop replacement. And as a combo cellphone laptop? I couldn't ask for better. My overall data usage has also dropped, because I'm using far more wireless on this device (I want to make sure it's connected for the stability if nothing else), but I can always drop out to a cell connection if no wireless is available - or if I don't feel like paying the stupid prices at the hotel the convention is being held at.
Now for the Cons:
I've really only got two, one of which was mentioned here. The damn thing is not cheap. Since I live in the states, the LTE version is not available directly. You need to pick up an international version from amazon or another reputable source. Hence the reason I have a kb with extra non-english symbols on it. Not that I mind, but it confuses some people when they look at it. When I picked mine up, the tablet kb and handset ran about $900 US all together. so not something you want to accidentally brick, or drop, or leave behind in a restaurant....
The second one is convenience. Given that it is a tablet - and a fairly large one, most people aren't going to go the phone replacement route like I did. You can't exactly just slip it into your pants pocket. And since the handset is BT, you can't exactly leave the tablet in the car and just use the handset inside most restaurants either (unless you park really close to the building). I'll often leave mine at home if all I do is run to the store for a dozen eggs or something, just because it's easier not to pack it up. But then half an hour of being unconnected and out of touch doesn't bother me - it might bother some though.
So there you have it, a much less technical review, from yet another satisfied user.
begalund said:
I'd picked up a Z4T about 4 months ago to replace two different devices, my aging and finally dead cell phone (I hung on to my old Samsung S3 for way too long), and my laptop, which is a still functional but extraordinarily heavy beast of a 17" macbook - about 6 years old on its own as well. What can I say, they were still working so why buy new?
I have to say I'm very glad I made the purchase. I picked up a SBH52 handset to make phone calls more convenient, and splurged on the sony docking kb for the added ruggedness of using it as a "case" - which it does like a champ. Calls are nice and clear, and I've had pretty much no troubles - aside from some occasional static when using the handset (which I owe to the handset itself being a bit flaky). Even with an unlocked BL, remote play on my PS4 still works, only the Bravia screen mirroring to my TV is kaput. It serves very well as a laptop for those like me that need something lightweight for overnight trips, let with a big enough screen to be able to remote desktop troubleshoot back to the main office.
Would this replace every computer I own? Obviously not. I still own a high end desktop for videos, games, and intense word processing (the sony kb is just a bit small if you were attempting to write a novel for example); and my PS4 for console games; but for light end use and for traveling, it's almost the perfect laptop replacement. And as a combo cellphone laptop? I couldn't ask for better. My overall data usage has also dropped, because I'm using far more wireless on this device (I want to make sure it's connected for the stability if nothing else), but I can always drop out to a cell connection if no wireless is available - or if I don't feel like paying the stupid prices at the hotel the convention is being held at.
Now for the Cons:
I've really only got two, one of which was mentioned here. The damn thing is not cheap. Since I live in the states, the LTE version is not available directly. You need to pick up an international version from amazon or another reputable source. Hence the reason I have a kb with extra non-english symbols on it. Not that I mind, but it confuses some people when they look at it. When I picked mine up, the tablet kb and handset ran about $900 US all together. so not something you want to accidentally brick, or drop, or leave behind in a restaurant....
The second one is convenience. Given that it is a tablet - and a fairly large one, most people aren't going to go the phone replacement route like I did. You can't exactly just slip it into your pants pocket. And since the handset is BT, you can't exactly leave the tablet in the car and just use the handset inside most restaurants either (unless you park really close to the building). I'll often leave mine at home if all I do is run to the store for a dozen eggs or something, just because it's easier not to pack it up. But then half an hour of being unconnected and out of touch doesn't bother me - it might bother some though.
So there you have it, a much less technical review, from yet another satisfied user.
Click to expand...
Click to collapse
Thanks for sharing
So I am coming to this device from the Nvidia Shield Tablet and I love the device thus far for all of the positive reasons mentioned. Also with respect to screen brightness listed as a con my own experience is that it is much better than what I was coming from.
The battery life is truly great with this device and my needs are small when it comes to the development area. I simply need it to be rooted because I prefer to remove all of googles garbage that I don't use and rooting and bootloader unlock was very simple.
All in all I am really liking this device, had it about 10 days now. I have the LTE version but only because I may use it at some point.
Overall very pleased with the device so far.
ThePhoneGeek said:
So I am coming to this device from the Nvidia Shield Tablet and I love the device thus far for all of the positive reasons mentioned. Also with respect to screen brightness listed as a con my own experience is that it is much better than what I was coming from.
The battery life is truly great with this device and my needs are small when it comes to the development area. I simply need it to be rooted because I prefer to remove all of googles garbage that I don't use and rooting and bootloader unlock was very simple.
All in all I am really liking this device, had it about 10 days now. I have the LTE version but only because I may use it at some point.
Overall very pleased with the device so far.
Click to expand...
Click to collapse
I was seriously considering the Shield because of the dev scene and the price. What made you switch?
jelbo said:
I was seriously considering the Shield because of the dev scene and the price. What made you switch?
Click to expand...
Click to collapse
The device itself just isn't very efficient on battery and I needed something with a slightly larger screen. It does ok but it's really designed more as a gaming device IMO which wasn't what I needed. Also the specs are a bit outdated now.
I noticed in the op that he said being a non eu customer when unlocking bootloader they will notice. Im an eu user, does this mean that they wont notice if I try claim warranty after bootloader unlock? I havent unlocked yet but I was getting slow WiFi and disconnections. I really want root but im not sure about this WiFi issue I set the WiFi to turn off at sleep and it seems better also the issues are caused less im concerned what would you guys do? ive sent it off to Sony once already they said nothing was wrong with wifi. Can someone help me decide? Much appreciated, many thanks.
First off, let me make clear that this post is written purely from a developer perspective. As a user, I love the Pixel C despite its shortcomings, use it all the time (even if mostly just for web browsing, at the moment at least).
But as an Android developer (both OS and apps), the device makes it really hard to love it.
The Pixel C is, hardware-wise, and firmware-wise, a ChromeOS device. Not maybe, not used to be, but fact. It starts with using coreboot+depthcharge as the bootloader that only on the very top of everything boots Android, and goes over to the ChromeOS EC (Embedded Controller).
And it is this embedded controller, combined with the Tegra X1 chipset, that I have the most gripes with.
What is the EC? The EC is, somewhat contrary to its naming, not a "dumb" controller, but actually a fully-fledged system inside the Pixel C. It has its own CPU (a Cortex A7) and its own operating system (which is much much smaller than the OS the device actually runs, in this case Android).
The EC does basic things like partially controlling the boot sequence, and having direct control over auxilliary hardware like the device's sensors. That means that the OS has to rely on communication with the EC to make use of the sensors, and that is exactly how it is implemented in the Pixel C.
So what is my trouble now, finally, you might be wondering at this point.
Maybe some of you have noticed that over the course of the past weeks I tried to develop Double Tap to Wake for the Pixel C.
My initial approach was the same as on other devices: make sure the touchscreen still receives power and handles events, even if the screen is turned off. Then listen for gestures (like a double tap), and if a gesture is recognized, activate the device.
This didn't work out, because the Tegra X1 chipset is extremely strict when it comes to power management. Similar to the EC, you don't have direct access to the PMU (Power Management Unit), but rather need to go through the Tegra's PMC (Power Management Control).
Basically, while I've succeeded in keeping the touch screen awake after the device is suspended, it amounts to nothing since the Tegra can only be awoken by specific events when in LP0 state (Low Power 0). These events are already pre-determined by the firmware and can be hooked into through the DTB (Device Tree Blob) which contains hooks and information for the various kernel subsystems.
It does so for the PMC as well, but since the events are already hardcoded, there is no way to wake the device from suspend on a touchscreen event in a useful way, or at least not with the Linux kernel 3.18 used in the Pixel C.
So double tap to wake works, until the system goes into LP0 suspend, which happens very quickly after you turn off the screen if everything works well (no wakelocks or wake interrupts).
I gave up on that, and decided to implement double tap to wake through the mechanism the Pixel C already makes use of, as we all know: if you double tap on the back, OR the front, the Lightbar will show you the battery level.
It turns out that this feature is controlled by the EC, but since there is only access to the sensors via the EC, it is the EC and only the EC that can propagate the event to the host system, and possibly wake it up from suspend in case of a double tap.
I had, again, everything working: I've created a small framework overlay APK so you can enable wake settings in Android Settings, modified power.dragon and sensors.dragon (two Android modules that interact with various subsystems in order to control the devices state, and to read sensors, respectively).
Double Tap to Wake using the sensor worked!
Until... the system goes into LP0 again. It was very frustrating, and became even more so once I read the EC source code and realized that the event simply isn't hooked up into the host system on purpose, in order to enable the Lightbar tap functionality.
Now, I'm not saying that this all is deliberately created in such a way as to make development hard for the device. But none the less, it is.
In order to make this work (I don't see much of a chance for DT2W using the screen), I will have to compile my own modified EC firmware, flash it onto the Pixel C, hoping I didn't make some grave mistake that will blow my Pixel C up in smoke, something that I wouldn't have to do on a usual Android device.
As you can see, all this is becoming a little convoluted, hairy, and dangerous. It's akin to getting the mostly undocumented sourcecode for your Laptop's EFI BIOS, compiling it yourself, and then flashing it into your Laptop, hoping you compiled from the right version of the source code, you did everything right while flashing the new firmware, etc.
The next problem is whether this, flashing your own EC firmware, is even possible at all things given. The Pixel C has, like all ChromeOS devices (I'm staying with my point here), a Write-Protect mechanism. In the Pixel's case it's not a screw, but it is the front camera flex.
Only with the Write-Protect disabled you have full access to the device on a similar level which you would have on a normal Android device after unlocking the bootloader. But, in order to access it on the Pixel, you need to take off the screen. You'd have to heat-gun the front until the adhesive comes off, pry off the screen with bezel, disable the Write-Protect, and then somehow reassemble the Pixel.
I bet at this point many will agree that it's all a bit extreme just in order to get a feature like Double Tap to Wake working.
Still, I will be trying. But not today. And probably not tomorrow.
Over and out.
Great rant and information. I have been following your efforts and wanted to thank you. I can now understand the frustrations why it is more difficult than other devices. Thank you again.
Man... This is depressing. Here I was hoping this device was only a Pixel by name alone, and that it would function like any other Nexus device. That's a real bummer, as I was SO close to replacing my aging Nexus 10 with this. But, alas, maybe it just wasn't meant to be. I would've been willing to drop $600 on this, but not anymore. Unless they can magically flash PURE Android on this, and get rid of all the junk that ties it to ChromeOS, I'll probably pass. Or, maybe I'll pick one up after they start discounting it, realizing what a failure it was rushing it to market. It's a shame that other OEMs put a bunch of crappy UI skins on their tablets...
charesa39 said:
Man... This is depressing. Here I was hoping this device was only a Pixel by name alone, and that it would function like any other Nexus device. That's a real bummer, as I was SO close to replacing my aging Nexus 10 with this. But, alas, maybe it just wasn't meant to be. I would've been willing to drop $600 on this, but not anymore. Unless they can magically flash PURE Android on this, and get rid of all the junk that ties it to ChromeOS, I'll probably pass. Or, maybe I'll pick one up after they start discounting it, realizing what a failure it was rushing it to market. It's a shame that other OEMs put a bunch of crappy UI skins on their tablets...
Click to expand...
Click to collapse
I bought the Pixel C to replace my N10. The Pixel C is a great device ; however, it has some known issues right now (touch screen & wifi). They are working on software solutions for them. Cheep5k8 has done some great development work so far - root with custom kernel. There is also an unofficial TWRP available as well. I still would recommend the Pixel C, but would suggest that you wait until the major issues are resolved. You can also follow the development threads to see progress. There are some great developers working with the device, so we will eventually get some custom options even if they are limited in some aspects.
Wow I knew some software was left over from the Chrome OS but I didn't expect all of that!
God damn Google wth
charesa39 said:
Unless they can magically flash PURE Android on this, and get rid of all the junk that ties it to ChromeOS
Click to expand...
Click to collapse
This is not going to happen. It would require very elaborate and extensive work on the firmware to make it appear like a true Android device, something that is not necessary for the device's first line of sale, and is sure as rain not going to happen just for the aftermarket. To be honest, they've already done a pretty good job at masquerading it as an Android device in the very short time frame they had, and it's still way problematic.
Still, I feel, and I'm not really sure why, that we can fix at least some things wrong with this device, but it's so damn messy. I mean, why would you leave the Write-Protect enabled on a device that effectively runs Android, especially if it's impossible for normal users, and thus developers, to disable it. Who's going to take the screen apart just to have some features added? Probably only the most die-hard of developers, and sure as hell no casual users who just want to flash a ROM. Some input from the Nexus team would have been really appreciated here.
I'm gonna try my best, but the past few weeks have been extremely frustrating. I just kinda want to enjoy the device for now, and that's just not possible once you start developing on an OS level beyond minor modifications to the kernel, so I'm taking a break, taking the device as it is (which is easier than I thought it would be, perhaps because in theory it is such a wonderful device), and focus on other things for the moment.
hey cheep5k8, nice work on the pixel c so far. you should be proud of your efforts in bringing what you have to users of this device. Do you have any thoughts on why google did not, or could not, make the pixel c a chromiumOS device?
Personally, and I don't have extensive data to back everything up (Ars did a more thorough research, but then again, I went deep into the code and ChromeOS gerrit, etc.), this is my opinion:
I think until early mid-year 2015 the Pixel C was still running ChromeOS in Google's labs, and it was well planned to ship it that way. Somewhen around late summer, the device was adapted to masquerade as an Android device. I call it that because it still really isn't a real Android device. The kernel source is hosted on chromiumos git, and the kernel is as much a ChromeOS kernel as it is an Android one.
But why the change? We can mostly just speculate. I didn't find any direct evidence in git or gerrit, and I doubt the developers really had much of a choice in that. I'm also sure the reason wasn't a technical one; the Pixel C would well be able to run ChromeOS as is. Maybe someone will even try to port it.
It was most likely a business decision. Maybe because the attempts to make ChromeOS operate touch only were not successful from a UX perspective. The device was already being developed on with prototype boards in 2014. At that time, though, it was mostly the bringup, so no real UI yet (as far as I could gather from git and gerrit). But still, you don't develop an OS/interface for a device only to conduct UX tests almost before release, only to just scrap it, so this doesn't seem to be likely.
No, I think this was a decision related to the future of Android, ChromeOS or both. Maybe they didn't want to bring ChromeOS touch to devices in order to promote Android in that position. Maybe they thought that in order to better sell the device, a less experimental, and already better known OS would be more beneficial. But this was definitely a product management decision; the developers really don't have that much of a say into what the final product, in terms of being a product, should look like.
A last question I have been pondering, somewhat as a conspiracy theory, whether this has something to do with Sundar Pichai becoming Google CEO. Not to forget, he was (or still is?) head of ChromeOS development before becoming Google CEO. It's possible, but depends on the details. He was announced new CEO on 10th auf August 2015. IMO that would have been still enough time to convert the Pixel C to run Android (the changes are not really too vast). I think it would be doable in 2 to 3 months, with a large enough team, which Google certainly has. Maybe the fallback to Android had already been planned for longer, maybe for different reasons than the final decision, and maybe some Android-relevant/compatible code was already there. That would have shortened the timeframe, in which to convert the device to Android, by a good amount, and would have made a date of mid-August for starting the move to Android realistic.
EDIT: But then, Pichai announced the Pixel C, already running Android, on September 29th. Would a conversion of the device from ChromeOS to Android be doable in just 1.5 months timeframe? Possibly, but it would definitely be rushed. Though AOSP is pretty easy to handle and run on a device if you have the right drivers; this would have meant nvidia providing on their part. Coding a small layer for the EC to accommodate Android...... Maybe this is what happened? Who knows.
What really happened, precisely, is, at this time, anyone's guess. Anyone's but Google's.
there have been a couple stories written mid last year that google wanted to phase out chromeOS and someway merge it with android, then late last year stories that no, that is really not the case google is gonna continue to develop both OS's. assuming that the merge thing was really going on inside google maybe that had something to do with the pixel c mess. about the write protect screw, one thing i had been thinking about is to figure out how to build a small trap door of sorts in the back cover at the point of the screw while at the same time clearing the adhesive to make the remove/replace easier. then, do an exchange plus maybe $100 [to cover mod/shipping]. but before i even attempt to do one device as a prototype i need to see the ifixit or similar teardown to get an idea, after seeing the affected insides, if something like that is even doable. but in theory someone would send in their stock unit and get back the mod device which would have quick easy access to the wp screw, assuming at this point it is something that can be done.
Aka the tablet doesn't know what it should be?
The rush to change it to Android could also show us why it's such a buggy mess. they already said they were gonna launch it at Xmas so I wouldn't be surprised to hear that ti didn't get a proper QA acessment and was just pushed out when they got Android "stable" enough.
The fact it's taken this long for even a statement from Google about the issues is ridiculous and why is it taking so long to fix?
Roxas598 said:
Aka the tablet doesn't know what it should be?
The rush to change it to Android could also show us why it's such a buggy mess. they already said they were gonna launch it at Xmas so I wouldn't be surprised to hear that ti didn't get a proper QA acessment and was just pushed out when they got Android "stable" enough.
The fact it's taken this long for even a statement from Google about the issues is ridiculous and why is it taking so long to fix?
Click to expand...
Click to collapse
I've actually helped a volunteer at Google to debug the WiFi issue, since they knew of me and knew my device is rooted, so I was able to perform diagnostic tests from the side of the device.
It seems to be very difficult to fix simply because it was, so far, not clear what exactly the reason for the WiFi issues is. It doesn't really seem like (only) a hardware issue with lost reception. The WiFi interface also massively drops packets/needs data retransmits, something is going wrong but it's not clear if that happens at the hardware level, the firmware level, or the kernel level.
I also tried to diagnose and possibly fix the WiFi issue myself; so far, no luck.
cheep5k8 said:
I've actually helped a volunteer at Google to debug the WiFi issue, since they knew of me and knew my device is rooted, so I was able to perform diagnostic tests from the side of the device.
It seems to be very difficult to fix simply because it was, so far, not clear what exactly the reason for the WiFi issues is. It doesn't really seem like (only) a hardware issue with lost reception. The WiFi interface also massively drops packets/needs data retransmits, something is going wrong but it's not clear if that happens at the hardware level, the firmware level, or the kernel level.
I also tried to diagnose and possibly fix the WiFi issue myself; so far, no luck.
Click to expand...
Click to collapse
The WiFi issue is a strange one but I'm on my 2nd pixel and never had an issue with either of them for the WiFi and get max speed 2 floors away :S granted I'm using 5Ghz so not sure if that why. The only major issue is with the touchscreen (and sometimes lag) did you have a look at these at all?
With that WiFi issue people have do you reckon that is what's holding the update back so long? They seem certain the software is what's causing the screen to not respond.
Roxas598 said:
The WiFi issue is a strange one but I'm on my 2nd pixel and never had an issue with either of them for the WiFi and get max speed 2 floors away :S granted I'm using 5Ghz so not sure if that why. The only major issue is with the touchscreen (and sometimes lag) did you have a look at these at all?
With that WiFi issue people have do you reckon that is what's holding the update back so long?
Click to expand...
Click to collapse
I think that it is very difficult to fix, yes.
As for the touchscreen, my Xceed kernel has some patches for the touchscreen included from the chromiumos git which were not yet released as an OTA (I think), so maybe that would be worth a try.
cheep5k8 said:
I think that it is very difficult to fix, yes.
As for the touchscreen, my Xceed kernel has some patches for the touchscreen included from the chromiumos git which were not yet released as an OTA (I think), so maybe that would be worth a try.
Click to expand...
Click to collapse
I would give your kernel a go but I don't really want to mess around with the pixel C too much
As a whole i've kinda slowed down with doing anything to my Android stuff now.
I don't think those fixes have been sent out in the OTA but perhaps they were in the other factory image? I think chainfire said he flashed it and his touchscreen problems have yet to come back.
Roxas598 said:
I would give your kernel a go but I don't really want to mess around with the pixel C too much
As a whole i've kinda slowed down with doing anything to my Android stuff now.
I don't think those fixes have been sent out in the OTA but perhaps they were in the other factory image? I think chainfire said he flashed it and his touchscreen problems have yet to come back.
Click to expand...
Click to collapse
Possible. IIRC they were only recently commited, but somehow still might be in the new factory image.
cheep5k8 said:
Possible. IIRC they were only recently commited, but somehow still might be in the new factory image.
Click to expand...
Click to collapse
well if the new update isn't released soon I may just suck it up and start trying out things to help.
Thinking about it since fixes were pushed to the Chromoniumgit is this tablet always gonna contain stuff from ChromeOS?
Roxas598 said:
well if the new update isn't released soon I may just suck it up and start trying out things to help.
Thinking about it since fixes were pushed to the Chromoniumgit is this tablet always gonna contain stuff from ChromeOS?
Click to expand...
Click to collapse
It can't not be a ChromeOS device. The entire board, basic hardware and firmware setup is built like a Chromebook. It has the Chrome EC, it starts up (boots) like a Chromebook, etc. This can't be realistically changed.
The "only" things really different from a Chromebook are:
- It is a touch-only device (there's the Chromebook Flip but it at least also has a keyboard)
- The storage partition layout has been partially changed so that Android can deal with it
and
- Instead of, at the very end of the boot sequence, booting ChromeOS, it boots Android. But actually, this is the least spectacular and least intricate part about the Pixel C's nature (even though of course a complex matter from a pure Android point of view). Both ChromeOS and Android use a Linux kernel. I'm not even entirely sure whether the Pixel C kernel contains any greater Android-specific adaptations that make it different from a ChromeOS kernel, aside from having a slightly different build configuration. When the Android kernel finally boots (from inside a ChromeOS boot image, may I remind you), it just expects to find a specific partition layout, which is there, and not the biggest problem to arrange. And after that, it just needs the right drivers, and it runs.
So, yes, the Pixel C is very much a ChromeOS device.. a Chromebook without keyboard, if you will, even if there are some people adamantly claiming the opposite. It just happens to run Android.
cheep5k8 said:
I've actually helped a volunteer at Google to debug the WiFi issue, since they knew of me and knew my device is rooted, so I was able to perform diagnostic tests from the side of the device.
It seems to be very difficult to fix simply because it was, so far, not clear what exactly the reason for the WiFi issues is. It doesn't really seem like (only) a hardware issue with lost reception. The WiFi interface also massively drops packets/needs data retransmits, something is going wrong but it's not clear if that happens at the hardware level, the firmware level, or the kernel level.
I also tried to diagnose and possibly fix the WiFi issue myself; so far, no luck.
Click to expand...
Click to collapse
Thank you for this post, information, and your efforts! It really sounds like this is a Frankenstein device. I returned mine because I didn't have confidence the google devs would be able to fix the poor wifi (especially wireless N) any time soon as they were requesting debugging reports from users here:
https://productforums.google.com/fo...ce=footer#!msg/nexus/CM9tv3pjTfQ/QY0xGoTMAgAJ
There were simply too many problems. I had wifi and touchscreen issues on both units I tried. Again, thanks for the info and effort. I keep reading about this device with hope it all gets fixed but that seems like it might be a while.
cheep5k8 said:
It can't not be a ChromeOS device. The entire board, basic hardware and firmware setup is built like a Chromebook. It has the Chrome EC, it starts up (boots) like a Chromebook, etc. This can't be realistically changed.
The "only" things really different from a Chromebook are:
- It is a touch-only device (there's the Chromebook Flip but it at least also has a keyboard)
- The storage partition layout has been partially changed so that Android can deal with it
and
- Instead of, at the very end of the boot sequence, booting ChromeOS, it boots Android. But actually, this is the least spectacular and least intricate part about the Pixel C's nature (even though of course a complex matter from a pure Android point of view). Both ChromeOS and Android use a Linux kernel. I'm not even entirely sure whether the Pixel C kernel contains any greater Android-specific adaptations that make it different from a ChromeOS kernel, aside from having a slightly different build configuration. When the Android kernel finally boots (from inside a ChromeOS boot image, may I remind you), it just expects to find a specific partition layout, which is there, and not the biggest problem to arrange. And after that, it just needs the right drivers, and it runs.
So, yes, the Pixel C is very much a ChromeOS device.. a Chromebook without keyboard, if you will, even if there are some people adamantly claiming the opposite. It just happens to run Android.
Click to expand...
Click to collapse
Yep I totally understand now. Man what a Frankenstein tablet but as long as they fix the issues with touch and some lagging here and there I'll be totally happy with it (as long as multi window is in N)
But since its a ChromeOS device could say Google release a flashable Chrome OS for it that would work? For people who have the keyboard anyway. Not saying they would but I'd much prefer Chrome OS tbh
Roxas598 said:
Yep I totally understand now. Man what a Frankenstein tablet but as long as they fix the issues with touch and some lagging here and there I'll be totally happy with it (as long as multi window is in N)
But since its a ChromeOS device could say Google release a flashable Chrome OS for it that would work? For people who have the keyboard anyway. Not saying they would but I'd much prefer Chrome OS tbh
Click to expand...
Click to collapse
Yes, they theoretically could very much do so.