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
Related
Just a blog re: ICS enabling full hardware acceleration of the GUI. We've all figured it would make our tablets sprint but this is putting things in a new light so I figured I'd post it here.
Linky
I'm sure the programmers and people on top of Android out there knew this. It sort of worries me though. Keeping in mind, Apple is running a totally different system - it sort of makes me respect iOS more so, to know that such a smooth system exists within the limits of 256MB of Memory when we're going upwards of 512MB and still having 'issues'. Don't jump down my throat, I don't want iOS (or an idevice), I'm just sayin'.
Jesus. I've known for a long time that there is something wrong with the way Android accelerates stuff and the whole UI design paradigm, but that's just boneheaded o_o That begs the question though: who made the decision to implement acceleration in such a horrible way and why wasn't it designed properly from the get-go? Anyone who has the slightest experience in OpenGL programming would've been able to tell them they're doing it wrong.
What a stunningly stupid way to implement things.
Just goes to show how much difference it really makes when it comes to having experience in OS development...
I like Android, but this design choice was just... dumb.
FloatingFatMan said:
What a stunningly stupid way to implement things.
Just goes to show how much difference it really makes when it comes to having experience in development...
I like Android, but this design choice was just... dumb.
Click to expand...
Click to collapse
Well, there are several shortcomings to Android exactly because of these kinds of brainfarts, like e.g. the permissions system is terribly sketchy and should've received a lot more Q/A. But now that it's released there's little Google can do about it without breaking compatibility as they didn't even plan for it to be extendable.
I do quite like Android, but it's too uneven to really feel professional or trustworthy. I just recently pondered about what I'd want from a future mobile tablet on my Google+ page and while I didn't mention it there, I feel like Win8 would've been in a terrific position for the OS on such a device if they didn't decide to remove traditional desktop from the ARM-version. I know Windows and Microsoft aren't popular here, but they've got a lot more experience with OS-development than Google and are a lot better at power-management design and acceleration of UI and its drivers, plus they've really put some real effort into security lately. Alas, with them scrapping traditional desktop from ARM-version Win8 won't cut it, either.
You guys should read Google's blog post. That article misses one huge point: the trade off. This was far from a bad implementation, it was just a very different one. If you read the article you would know that ios freezes if you hold your finger on screen while loading a large list, Android does not. Android balances the CPU threads for ui display and data processing somewhat equally, while ios grants utter priority to their ui display thread . Basically, if the ui display thread is busy, data processing stops. Android is the winner, it is ios that will now be limited in speed with this configuration until it is optimized for new hardware much like how Android currently works!
autom8r said:
You guys should read Google's blog post. That article misses one huge point: the trade off. This was far from a bad implementation, it was just a very different one. If you read the article you would know that ios freezes if you hold your finger on screen while loading a large list, Android does not. Android balances the CPU threads for ui display and data processing somewhat equally, while ios grants utter priority to their ui display thread . Basically, if the ui display thread is busy, data processing stops. Android is the winner, it is ios that will now be limited in speed with this configuration until it is optimized for new hardware much like how Android currently works!
Click to expand...
Click to collapse
Uh, it is a bad implementation. You can have both a good implementation AND still balance priority of both the rendering queue and application threads, they are not mutually exclusive.
WereCatf said:
Well, there are several shortcomings to Android exactly because of these kinds of brainfarts, like e.g. the permissions system is terribly sketchy and should've received a lot more Q/A. But now that it's released there's little Google can do about it without breaking compatibility as they didn't even plan for it to be extendable.
I do quite like Android, but it's too uneven to really feel professional or trustworthy. I just recently pondered about what I'd want from a future mobile tablet on my Google+ page and while I didn't mention it there, I feel like Win8 would've been in a terrific position for the OS on such a device if they didn't decide to remove traditional desktop from the ARM-version. I know Windows and Microsoft aren't popular here, but they've got a lot more experience with OS-development than Google and are a lot better at power-management design and acceleration of UI and its drivers, plus they've really put some real effort into security lately. Alas, with them scrapping traditional desktop from ARM-version Win8 won't cut it, either.
Click to expand...
Click to collapse
If Microsoft is dumb enough to kill desktop mode on ARM, that really destroys the Win8 tablet market outside of running on Intel chips, which puts them at sub-par graphics. I suppose the only hope then is if AMD steps in and I'm not all that much a fan of AMD, though they have tried to make good efforts in the mobile arena with their A-series chips and having decent GPUs.
I suppose I'll keep an eye on this and see what Microsoft does. Given their lack of intelligent decision making of late (ie. far dumber than their normal stupidity), I don't hold out much hope. Pity, Win8 tablets were looking strong, too.
Gnoop said:
If Microsoft is dumb enough to kill desktop mode on ARM, that really destroys the Win8 tablet market outside of running on Intel chips, which puts them at sub-par graphics. I suppose the only hope then is if AMD steps in and I'm not all that much a fan of AMD, though they have tried to make good efforts in the mobile arena with their A-series chips and having decent GPUs.
I suppose I'll keep an eye on this and see what Microsoft does. Given their lack of intelligent decision making of late (ie. far dumber than their normal stupidity), I don't hold out much hope. Pity, Win8 tablets were looking strong, too.
Click to expand...
Click to collapse
The Metro-interface is aimed for touch-based devices, including tablets. Desktop-mode doesn't work too well on such. The problem is that Win8 tablet could serve as BOTH a mobile device AND a desktop computer if Microsoft played its cards right and thus reserve a very nice spot for itself.
WereCatf said:
The Metro-interface is aimed for touch-based devices, including tablets. Desktop-mode doesn't work too well on such. The problem is that Win8 tablet could serve as BOTH a mobile device AND a desktop computer if Microsoft played its cards right and thus reserve a very nice spot for itself.
Click to expand...
Click to collapse
Indeed. Being able to handle both of those would hook me in pretty easily.
Hi everyone,
Thought I would post about an Android issue that is bugging me - the fact that despite USB Host functionality being present in ICS, USB DACs (digital audio converters, external sound cards if you will) do not work with our devices .
If they did work then we could use relatively cheap USB DACs with our Android phones and enjoy great music sound quality, no matter which cheap DAC/DSP the manufacturer has seen fit to include. Ever since I sold my Galaxy S, which has an excellent Wolfson DAC and can produce awesome sound quality with Voodoo Sound, the sound quality of my subsequent devices has rankled. Now with ICS this is a simple software fix, which makes it all the more irritating (someone has managed to add support for these in a Nook Colour kernel that works with CM9). To be honest I'm seriously considering buying an iPhone for the first time ever because they have this functionality out of the box.
Fortunately there is something we can do about this besides making ineffectual unhappy noises and waiting for customs ROMs etc to fix this - vote the issue up here: http://code.google.com/p/android/is...rs&colspec=ID Type Status Owner Summary Stars
To vote just star the issue.
This issue needs ~1150 votes to enter the top ten, which doesn't seem a big ask given the hundreds of millions of Android users out there... (it's got 66 votes so far today and risen 16 places up the issues ladder).
Please star this and share this out to your social networks - help save me from having to continue think about getting an iPhone!
I also posted about this issue at my blog, if you were planning to share it out over your social networks that might be a better thing to link to:
http://www.androidnz.net/2012/02/android-usb-host-for-audio-devices-fail.html
code.google link does not work.
+1!
I would also really like to see this implemented. Shouldn't be too difficult for them, methinks? The nook already seems to be able to do 24/96 with a USB DAC using a standard USB audio module. Apparently, with the correct ALSA driver we could also do 24/192, even!
ps. Correct url to vote (sans http prefix) is here:
code.google.com/p/android/issues/detail?id=24614
^ I are n00b so can't link, sorry.
Add star near the comment box at the bottom of the thread.
Voted for it since the first week. Hoping i can finally ditch my ipod once and for all.
Working link?
Sent from my GT-I9100 using Tapatalk
guttsy said:
I would also really like to see this implemented. Shouldn't be too difficult for them, methinks? The nook already seems to be able to do 24/96 with a USB DAC using a standard USB audio module. Apparently, with the correct ALSA driver we could also do 24/192, even!
ps. Correct url to vote (sans http prefix) is here:
code.google.com/p/android/issues/detail?id=24614
^ I are n00b so can't link, sorry.
Add star near the comment box at the bottom of the thread.
Click to expand...
Click to collapse
No, it's a major ***** for them to implement - ALSA is evil.
Getting audio routing to work properly on a device with fixed hardware is enough of a pain as it is.
Handling audio routing that changes for 3280348230 different peripherals would be an utter nightmare for Samsung.
While I agree it would be a cool feature, it's definately something hard. Just look at how hard it was for us to make audio working properly on Ice Cream Sandwich. While some Alsa could work, all devices have their own controls and way of working, so it's really tough to make it work for all at once (which is probably why Google doesn't support it).
First post updated with working link!
In relation to this being difficult, doesn't seem that difficult since it's been done already (the Nook fix was not specific to the E7). Surely doesn't need peripheral-specific support, only needs to be able to send audio out via USB on the host device? The iPhone doesn't specifically support any particular peripherals either...
Anyways, thanks to those who have voted, over 100 extra votes now and climbed 24 places.
Apparently there's a test-build kernel around that would support USB DAC for GB (yes I know we are talking about ICS here)
For those interested go check out the post by pongster
http://forum.xda-developers.com/showpost.php?p=22265282&postcount=9844
Starred.. i really wish to see iRig sorta of hardware being supported
Sent from my GT-I9100 using XDA App
Elythor said:
Apparently there's a test-build kernel around that would support USB DAC for GB (yes I know we are talking about ICS here)
For those interested go check out the post by pongster
http://forum.xda-developers.com/showpost.php?p=22265282&postcount=9844
Click to expand...
Click to collapse
Interesting! Just been reading there... I would imagine custom ROMs and kernels will support this long before Google
Still, important to try and raise the issue with Google, would rather not wait for x-feature to be ported b ydevs with every new Android device.
Entropy512 said:
No, it's a major ***** for them to implement - ALSA is evil.
Getting audio routing to work properly on a device with fixed hardware is enough of a pain as it is.
Handling audio routing that changes for 3280348230 different peripherals would be an utter nightmare for Samsung.
Click to expand...
Click to collapse
I was thinking... some devs could get this thing to work in their custom ROMs on some devices, like Nook color for example. Why should be so hard for Google to implement this? I have a tablet, and could make ALSA recognize my DAC with appropriate libraries, but route audio to the DAC is imposible, tried to mess asound.state, alsa.conf, etc...
Seems to be something hard, but there are devs who could get it working.
If the problem is that each DAC has its own protocol and settings, and that accommodating every powered DAC would be too difficult, then wouldn't the next step be to ask a few specific companies to design and build Android DACs around a fixed set of values, commands and so forth, and to introduce them on a very small scale at first -- so that, while not every DAC worked with Android, a few specific ones did? That's what a certain fruit company did with the Wadia 170i and the Cipher Labs AlgoRhythm Solo.
Reignogleph MMXI said:
If the difficulty is that each DAC has its own protocol and settings, and that accommodating the massive variables inherent in including every powered DAC would be too difficult, then wouldn't the next step be to ask a few specific companies to design and build Android DACs around a fixed set of values, commands and so forth, and to introduce them a scale that small at first -- so that not every DAC works with Android, but a few specific ones do? That's what a certain fruit company did with the Wadia 170i and the Cipher Labs AlgoRhythm Solo.
Click to expand...
Click to collapse
I think the guys from Wadia/BA went to the Android SD requesting Google to help them (for the Droid & Captivate ) but they got a naked bird instead..remember that Google only recently have launched the music store...
I think audio hardware is one of those non standard things across android platforms and getting the audio -usb dac protocol to work across all devices would prove difficult if not impossible for stock android.
But yes, it's a feature id definitely want to see implemented. But I think the devs might have to take on this one.
Sent from my samsung galaxy s2 using tapatalk
This has already been accomplished on the Nook. It's not difficult.
01010001 said:
This has already been accomplished on the Nook. It's not difficult.
Click to expand...
Click to collapse
If it's not hard, please do us all a favor and implement it yourself.
Sent from my GT-I9100 using XDA
So out of curiosity, if we did indeed have ALSA working with a USB DAC, would that bring the audio latency down to near realtime speeds?
If there's one are that iOS is superior to Android it's with low latency audio performance, and that's why you don't really see any softsynths or guitar processing apps for Android, sadly.
Lord Tim said:
So out of curiosity, if we did indeed have ALSA working with a USB DAC, would that bring the audio latency down to near realtime speeds?
If there's one are that iOS is superior to Android it's with low latency audio performance, and that's why you don't really see any softsynths or guitar processing apps for Android, sadly.
Click to expand...
Click to collapse
Good question.
Would be another benefit. Even if I care only for external DAC's with superior sound quality, I'm sure that there are people waiting for this
Sent from my GT-I9100 using XDA
You galaxy sII people are lucky, cyanogenmod supports audio out via usb. Still no real love for the galaxy nexus
I have been somewhat following the whole Phonebloks and ARA scene, participating in the Dscout missions, and generally have to say that there is a lot of buzz and hype with very little meat behind it. The general populace is thinking legos, colors, fancy shmancy materials, and other appearance related nonsense. There seems to be very little technical content, and the majority of the crowd seems to be lured by key words such as "eco", "reusable", "repairable", "customizable" and so on.
Certainly, in terms of driving sales, this is good attention, something Motorola needs.
The downside, however, seems to be that people do not understand how things work, have no patience for it, and want things to "just work."
I highly doubt that this will be something that is user friendly out of the box.
The biggest misconception seems to be that you will be able to build anything you want out of this. If this idea is not curbed, this project will fail. People will become disappointed. Already they seem to think that they can have an espresso maker and a telescope added to the thing.
On top of it all, Motorola has a track record of taking good ideas and executing them poorly. Think Atrix lapdock.
So what is the clear mission of this project?
Ease of repair? That can already be done using current production methods. Look at the iPhone vs Galaxy series in terms of screen replacement. Its night and day.
Reusing parts? What could you reuse from an iPhone 4 when building a 5s? The headphone jack? Batteries die, radios, memory, sensors, processors, become old news by the time they hit the assembly line, and screens evolve at a fast pace.
There is no mention of a core device with expansion bays, the project seems to suggest you could swap all basic components on the fly. This is nonsense. Is it really worth taking steps back to make separate little bricks for Bluetooth, Wifi, NFC, GSM radio, etc., when current production methods can squeeze these into a single system-on-chip design at a fraction of the cost?
Imagine for a minute if Googorola took the Moto X approach to hardware: You log into your Motomaker account, and at checkout you pick your options. 3 choices of screen size, 3 choices of processors, 3 choices of storage capacity, an 8, 13, or 16 Mpix camera, 3 different battery capacities, cdma, gsm, or global radio, etc., then once you select your hardware, you customize the case colors, and you're done.
I know this rant is way into the TL;DR territory, but there are other factors to consider, perhaps profitability being paramount. Open source phone, with open source modules, etc. How will Motorola make $ on this? How long till knock off modules hit the market? What is the pricing scheme, etc.
I would love to get a serious discussion going, touching on some of the things I brought up.
Sent from my Nexus 5 using xda app-developers app
I wouldn't say they're doomed from the start but their social network app and stuff seems pretty gimmicky to me. I definitely think that modular phones are in the future but they need to spend more time talking about the actual hardware and open sourcing drivers and stuff instead of their weird Instagram clone in my opinion. I'm still staying optimistic if they don't do it someone else will.
Sent using Tapatalk
Nice idea, but people here at xda would have a nightmare with such a thing, meaning rom development for every and each component combination.......
Lets ask ourselves, when would it be appropriate or papamount to upgrade a hardware component of any of our phones now? The reasoning now is more like, 'it would be cool if we could'. I cant think of any necessary reason now for needing to change harware unless it needs repair. I believe necessity should be a starting point for this whole concept. Necessity often drives truly good design.
I personally think that this would be good because of the fact that technology advances at such a rapid pace that being able to upgrade your components when a better version comes out would be good. Obviously there would be some compatibility issues between some parts that would be unavoidable. It would be more for the person who wants the high end device. Take me for example, I have the S4 and I love it but next year when the S5 comes out it wouldn't be the latest and greatest and I can't upgrade for two years. I could love a Moto X but I don't wanna pay the off contract price for it. So I think this is the only time it would be good and efficient, not a huge game changer but a slight game changer.
Also about the knock off or cheap parts, if they have the drivers and protocols open source than it shouldn't be to big of an issue, not anymore than buying a knock off replacement screen. Still something to look out for when buying modules.
I think that the idea from Phoneblocks or Ara are really good but I think that the project will prospere
Project Ara.
Being a modular design, brings complications, but with those complications comes new opportunities in the hardware section as well as the software side of the development.
The metric is quite valid and tangible, even more so today, wth the manufacturing techniques available, this idea actually makes far more sense than feeding the giant a steady diet of the same old thing.
You save money if all you require is a modified version of the RF section, you install that block.
The same goes for the remainder of the phone, easy upgrading, no downtime, and lower overall cost for the entire market, not to mention the lowering of landfill garbage from dumped devices that could not be upgraded.
The engineering end of this is wonderful, I wish it arrived years ago. A 'Lego-Phone' you build and upgrade as you need to, no more buying an aircraft carrier, when all you require is a shuttle.
We can finally drive the market, provide for ourselves, push manufacturers in the direction we need them to head, instead of driving us with their own thoughts on what is necessary.
I don't use much in the way of media, so anything more than 720P is of little use, but I do appreciate an HDMI-type format screen.
The RF section is far more important to my needs, and of course, a micro-SD card slot.
I prefer a sensitive front end, high dynamic range, and a superbly augmented IP3(third intercept point) as a basis for my receiver design.
I have grown tired of matchbox quality RF systems, and when in poor signal areas, or in a heavily wooded area with sparse cell tower penetration, i prefer my phone have the ability to connect with a site even if the RSSI indicates no signal, at least a data channel should be able to 'hear' a short text message for help if sent.
If the phone can't hear well, it can't talk well, either.
Most subscribers assume that cell signals are routed through the power lines*!*
I have had customers that actually said this...But this is the basis of my most desired and important 'want', a solid RF system, receiver and transmitter section that works!
High density areas have few problems with dropped calls, if the site loading is low, but in rural areas, loading is not an issue, it's accessibility, and sites spaced 10 miles apart, can actually have users drop calls even near by, due to dense foliage or hilly/mountainous terrain, even though the tower is within eyesight, you still drop a call. This is where fresnel zones come into play, and where a good RF section makes the difference.
If you think rain kills RF signals, see my pic I just snapped from my door, of the trees filled with heavy snow!
Poorly designed RF systems can't decode signals properly, the B.E.R suffers, causing message failures, call time-outs as well as just lousy QOS due to noise, echoing, raspy speech processing and a host of other problems.
The memory subsystems are important, as well as the GPU and video systems, but you can still make a call if the video drops, not so much if the RF section dies.
We all have our own desires, as well as what is most important to our needs, but overall, i do believe that project Ara is a great step in the right direction for a change....Where the customer drive the market, not the manufacturers!
Now I don't know if you were aware, but Google only owns Motorola's Research Lab. The actual company was purchased by Lenovo a few weeks ago.
Besides, I sort feel the same way, because, besides the hubbub, it doesn't seem like a very user friendly process in my mind. That's why I think it feels like nothing more than a research project with a couple of news reporters locked inside their facilities.
Sent from my ST21i using XDA app-developers app.
Don't forget to hit thanks if I helped!
In the beginning, they will have to offer options in a controlled environment like one poster abive said. It will be similar to
1. CHOOSE YOUR PROCESSOR:
a. Good
b. Better
c. Best
Etc etc....
The first question probably will be "Choose Your Carrier". Then all of the module choices will be pre-screened to function together on that network.
Samsung Galaxy S4 "Fort Knox Edition"
Guys, believe in Google. They made a search engine wich is now the most used engine. They also made a very good browser, an operating system for mobiles, an online map wich has street view and many other good things. Why they couldn't make project ara?
Sent from my LG-P880 using xda app-developers app
PenguinStyle said:
Guys, believe in Google. They made a search engine wich is now the most used engine. They also made a very good browser, an operating system for mobiles, an online map wich has street view and many other good things. Why they couldn't make project ara?
Sent from my LG-P880 using xda app-developers app
Click to expand...
Click to collapse
Just making sure it wasnt a misinterpretation but google did not create android, Android Inc founded by andy rubin(correct me if im wrong) http://www.techradar.com/news/phone...e-phones/a-complete-history-of-android-470327
PenguinStyle said:
Guys, believe in Google. They made a search engine wich is now the most used engine. They also made a very good browser, an operating system for mobiles, an online map wich has street view and many other good things. Why they couldn't make project ara?
Sent from my LG-P880 using xda app-developers app
Click to expand...
Click to collapse
All those things you mention are software, that runs on high performance computers. What ARA requires is a total rethinking of the hardware and engineering of today's mobile phones.
Can any module be swapped for some other type of module? How do they interface? What bandwidth limitations do these interfaces introduce?
Sent from my GT-I9505 using Tapatalk
SynGates said:
All those things you mention are software, that runs on high performance computers. What ARA requires is a total rethinking of the hardware and engineering of today's mobile phones.
Can any module be swapped for some other type of module? How do they interface? What bandwidth limitations do these interfaces introduce?
Sent from my GT-I9505 using Tapatalk
Click to expand...
Click to collapse
The ARA developers conference already answered most of this, so its possibility is not the question. Its availability and adaptability is the question. Will people flock to it or despise it?? Will it make people feel more in control?
If google can advertise this thing as something that gives people more power it will definitely catch on. Plus if Google is truly looking to start their own mobile network as rumoured, then they could start in that manner and make others envious to catch on.
Sent from my SM-G900T using Tapatalk
It's going to be a wait and see what happens on release thing I think. I don't personally don't think it's going to explode instantly onto the mobile scene but give it a year or two and hopefully it will start changing the game. With everything being open source it might pave the way for smaller companies to get into the handheld scene where they don't have the money or resources to develop full devices but can focus on just a single module. Much like the way of the custom pc market.
replicamask said:
It's going to be a wait and see what happens on release thing I think. I don't personally don't think it's going to explode instantly onto the mobile scene but give it a year or two and hopefully it will start changing the game. With everything being open source it might pave the way for smaller companies to get into the handheld scene where they don't have the money or resources to develop full devices but can focus on just a single module. Much like the way of the custom pc market.
Click to expand...
Click to collapse
My sentiments exactly.
Koreans will really fight against this project. They won't be willing to loose the cellular market to Google. ARA has a lot of potential in developing countries, provided the prices for modules will be adequate. But yes, even with adequate pricetag such innovation will require a drastic change in marketing-infected minds of people.
Sent from my SM-N900W8 using Tapatalk 4
I hope it could work really well. I'd like to see the ability to transfer all the core modules from one endo 'frame' to another - SIM, WiFi, ROM, storage plus camera and perhaps CPU/RAM from a larger 'everyday' frame to a smaller 'night out' frame. I'd like an 'everyday' camera and a 'holiday' camera. I might carry a speaker module, but would swap it in against a torch module only for those occasions I'd need it. I'd carry spare battery modules and expect to see external chargers for them.
Didn't read the whole thread, but I'd say the whole "eco friendly" concept is BS from the beginning. People will start buying new components everytime they are out, thus generating MORE electric waste.
till22 said:
Didn't read the whole thread, but I'd say the whole "eco friendly" concept is BS from the beginning. People will start buying new components everytime they are out, thus generating MORE electric waste.
Click to expand...
Click to collapse
This is possible and a good point. I think they could counter this by placing some inherent value on modules so you could trade them in for cash or credit towards other modules.
I think this will work much better than trading in phones since all modules should work for all ara phones.
What you all need to remember is that the microcomputer revolution didn't really become a mass market phenomenon until the IBM PC arrived with its open "Industry Standard Architecture". This allowed the rapid emergence of third party expansion cards and other "PC compatible" hardware, and "PC clones". Not only did this accelerate the pace of technology development it also pushed prices down significantly. If IBM had not made the PC architecture both expandable and open, general purpose computing would have remained an expensive and specialised tool available only to business and the very rich. Imagine the effect that wouls have had on the development of the worldwide web a decade later.
If you are of the generation who grew up uaing laptops you may not have realised that modular technology is cheaper and more flexible, and it means longer hardware lifecycles.
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.
I started this off as a response to another thread inquiring about bugs or issues with 9.0, but ended up writing up a full piece about the useability and functionality of the system and decided to make it a new thread. In short, I suggest to anyone considering the update, if you're happy with your current set up and are not fond of relearning how to use something you carry and depend on every day, then you will probably want to stay on 8.1.
I used it from the day it released up until 2 days ago and found it to be a massive clusterf*ck of UI/UX inconsistencies, glaring white, and broken useability features. Notifications are a mess, settings and features which were organized into reasonable categories are now buried in unrelated submenus and renamed confusingly, reliable UI/UX features have been swapped with newer less obvious actions, gestures, and unclear UI elements, drastically unrelated font families have been thrown together to create a very visually jarring reading experience, the system UI has enough white-on-white you could use the phone as a beacon in a storm, and the color choices seem to have been based on focus groups conducted with toddlers. Maybe it's just me getting old and stubborn towards change, but the consistency and predictability of 8.1 is nowhere to be found in 9.0.
As for the backend, a lot has been added, more than I can recall or understand, but the PrivateDNS and MAC randomization are nice security upgrades that are actually useful for those who live in places with ubiquitous but often sketchy, less-than-open internet fuctionality. It is noticeably faster visually, but also particularly faster in dealing with larger files and database types of information. Small tweaks, like the media volume default, and the dynamic rotation icon in the navbar, are welcome additions, but those come at the expense of the god-awful, take it or leave it, reworking of the Recents overview page. I know it's currently optional, but I gave the new gesture system a go, and eventually got used to it. However, it's going to take some massive tweaking down the road for it to be anywhere near as efficient and simple as the old navbar and vertical card overview.
Core device functionality is fine and battery was fair, almost the same, but I run a very lean system and also disable a lot of services since I currently live in a country with restricted Google access and most of those features are useless to me. Camera is still best-in-class and shouldn't be expected to change since the core camera functionality is in the hardware, the Camera app, and the Pixel Visual Core extension app. Basically any system apps that update via the Play Store should and do function as expected without any noticeable problems. While not specifically a Google problem, it's still worth mentioning that some apps are not yet ready for 9.0 and need to be updated by their developers.
My personal opinion, 9.0 is Android's "Windows Vista" moment, and they'd be smart to pull the whole thing back to beta and hold the release until they get their UI/UX overhaul ready for a full primetime roll-out. The system runs like it was built and tuned specifically for the Pixel hardware, but the user experience made me cringe every time I picked up my phone.
I spent the last 36 hours downgrading to 8.1 from a full wipe, clean setup, and restoring an adb backup. I now have a phone that I actually enjoy using again and I couldn't be happier with it.
Edit:
In considering a few friends opinions regarding Betas and Developer Previews, I'm inclined to temper my opinions, but only slightly.
Yes, I agree, that taking part in the Beta and Developer Preview (DP) process of OS releases helps determine many important aspects of the OS. However, in the case of entities this large, that involvement is really only meant to be as bug chasers. Beta and DP user's opinions on UI/UX matters are largely ignored, as they do not fit within the framework of said entities larger goal: Mass Usage (i.e. the lowest common denominator, AKA the ignorant child-like masses). They only want you for your ability to create and willingness to report showstopping bugs. They don't need the developer or niche user community to make UI/UX choices, they have focus groups for that. Unfortunately, the customer isn't always right, and people don't usually know what they actually like or why. Chase opinions, focus groups, ad engagement, click data, and the fastest dollar, and eventually we'll all be living in a Fisher-Price world (see: Asia).
The second problem with participating in these not-really-beta and almost-but-not-quite-developer-previews is that, not only have they already made all of the major decisions about how it's going to look and be used, expert use and experience be-damned, but by participating in these programs, the user is effectively subjecting themselves to a brainwashing scheme meant to dull the discerning mind into believing that "vX.X is so much better now than when it first hit public preview". It's the equivalent of software Stockholm Syndrome. Public Beta and DP users have deluded themselves that this final release is ok based on how they saw it change from the first public preview release. It's still just as awful as it was when it first went public, it's just a slightly better shade of awful.
It's a damned shame such a powerful and well running OS feels like it had such an awful UI/UX thrown on top of it. It's inconsistent, half baked, and feels like a grab at the ignorant, screen-obsessed masses, if they were color-blind with 20/200 vision. This is professional grade coding with pre-alpha grade UI/UX. A system built for power with a GUI designed for infantiles, on a device aimed at enthusiasts. They should be ashamed.
I'm not struggling like you with the UI. But, in order to get the new hidden/back end benefits and avoid most of UI issues, why not just run a different launcher?
WibblyW said:
I'm not struggling like you with the UI. But, in order to get the new hidden/back end benefits and avoid most of UI issues, why not just run a different launcher?
Click to expand...
Click to collapse
I always do. Been a die hard Nova user for years. But there are some really weird glitches with how 9.0 and third party launchers interact. I managed to work most of them out but never regained that full, fluid, native UX like with previous versions.
Finally, someone who understands. I've been thinking that I'm the only one disgusted by this release.
How did you revert back to 8.1?
Unlock bootloader, flash-all script, re-lock?
harisyks said:
Finally, someone who understands. I've been thinking that I'm the only one disgusted by this release.
How did you revert back to 8.1?
Unlock bootloader, flash-all script, re-lock?
Click to expand...
Click to collapse
Backed up everything with Titanium, did a full /sdcard backup to pc via adb, full partition wipe via TWRP, then ran the flash-all script from the July image.
Afterwards, same as my usual manual update. Boot to TWRP flash kernel, and Magisk.
Followed by the painstaking process of a full manual setup of clean device.
Then installed Titanium and SD Maid, disabled all unnecessary services and activity hooks, restored SD Maid settings via Titanium, cleaned caches, then restored my /sdcard via adb, then restored user apps and user app settings via Titanium.
Then individually redownloaded all the individual app files that didn't make it in the backup.
And now, here I am, posting from my 8.1 device like the last two weeks never happened.
Edit:
If you're bootlocked, then you'll need to backup your important /sdcard files via file transfer or adb, unlock to do the fastboot method of restoring the stock 8.1 July image, then just relock, restore your /sdcard via file transfer or adb, and then manually download and setup all your apps fresh.
If I had to do all that, I would have either suffered with 9.0, or waited till I had enough whiskey and coffee on hand to suffer through a long weekend of a full manual setup.
@jallenhayslett thanks for the detailed reply, I appreciate it.
I'm don't have a lot to back up, so a clean flash isn't a major issue for me. I'll probably wait for the September security patch to see if they've changed anything and then decide.
So many tears about very minor UI changes. I don't get it. I feel like it the time you spent complaining about it you could have learned to use it.
crixley said:
So many tears about very minor UI changes. I don't get it. I feel like it the time you spent complaining about it you could have learned to use it.
Click to expand...
Click to collapse
I tend to live by the "If it ain't broke, don't fix it" ethos. "Just shut up and learn to love it" only exists in the section of my dictionary labeled "if absolutely necessary".
Mind you, I live and work in a country where ignoring things until they become festering, puss filled, infected boils is almost as commonplace as breathing, so I'm well acquainted with how I should just adjust and get by. I refuse to accept garbage products here as well, despite knowing it won't change many opinions.
jallenhayslett said:
I tend to live by the "If it ain't broke, don't fix it" ethos. "Just shut up and learn to love it" only exists in the section of my dictionary labeled "if absolutely necessary".
Mind you, I live and work in a country where ignoring things until they become festering, puss filled, infected boils is almost as commonplace as breathing, so I'm well acquainted with how I should just adjust and get by. I refuse to accept garbage products here as well, despite knowing it won't change many opinions.
Click to expand...
Click to collapse
Many like the changes, so who decides that it is or isn't garbage? I like it personally, so is your opinion the only valid one, is mine? Etc.. It's changed, either adapt or move to something else.
crixley said:
Many like the changes, so who decides that it is or isn't garbage? I like it personally, so is your opinion the only valid one, is mine? Etc.. It's changed, either adapt or move to something else.
Click to expand...
Click to collapse
Glad you like it, regardless of my opinion. I did, however, move on, or back, rather.
Interesting though that I am not the only one to have similar opinions. opinions that have been mentioned and discussed as far back as the first preview build. But our opinions don't matter, and they aren't about the preview builds, they're about the release build, and our opinions matter even less in regards to public release builds.
Why these opinions and the opinions of countless others matter, is because, while occasionally drenched in colorful, subjective language, they actually address some very objective, glaringly obvious missteps taken by the departments responsible for UI and UX. Missteps which, whether you like, dislike, approve, or disapprove, resulted in repeatable glitches, slowdowns, and inefficiencies. Missteps which those departments chose to gloss over and/or ignore for the sake of shipping a subjectively better looking, subjectively cleaner, and subjectively prettier product on schedule, despite grievances aired by the developer community during testing phases.
So, yes, I agree. My opinion really doesn't matter. But, if that's the case, then neither does yours. Whether the opinions themselves address objective or subjective matters, at the end of the day, they are nothing but feelings. And feelings don't matter. Only facts.
I don't really understand what you say about never getting back the old fluidity, I've found no problems myself: the few gestures they have are simple to adapt to, and I'd personally probably have gone the whole hog and replaced the back button with a swipe left on the pill (easier to reach than a button that's off to the left, though I've customised my nav bar to move it in closer). I genuinely haven't felt any loss of usability, and use some features more (i.e. I occasionally remember the quick swipe to switch to last app, never remembered the equivalent with the old recents button).
I actually prefer the new "recent apps". Mind you, I always disliked the old "rolodex" style, so pretty much anything would be an improvement, but I often find it useful that I can actually read information off my recent apps without switching to them (e.g. when I'm looking something up in one app and using the information in another). So it's a matter of what you use the phone for and how you use it, but overall I find it better. Please don't feel obliged to label me as a member of the "ignorant, child-like masses" for having a different opinion from you.
Aesthetically I would prefer a more muted colour scheme in the settings, but Oreo was also blindingly white. And at least you no longer need substratum if you just want a dark notification slider with a light wallpaper (though we are back to needing root for proper theming, which is a regression, though since this is XDA we shouldn't find that a big problem).
Besides which, Vista's problems were of a different order to this
jallenhayslett said:
Glad you like it, regardless of my opinion. I did, however, move on, or back, rather.
Interesting though that I am not the only one to have similar opinions. opinions that have been mentioned and discussed as far back as the first preview build. But our opinions don't matter, and they aren't about the preview builds, they're about the release build, and our opinions matter even less in regards to public release builds.
Why these opinions and the opinions of countless others matter, is because, while occasionally drenched in colorful, subjective language, they actually address some very objective, glaringly obvious missteps taken by the departments responsible for UI and UX. Missteps which, whether you like, dislike, approve, or disapprove, resulted in repeatable glitches, slowdowns, and inefficiencies. Missteps which those departments chose to gloss over and/or ignore for the sake of shipping a subjectively better looking, subjectively cleaner, and subjectively prettier product on schedule, despite grievances aired by the developer community during testing phases.
So, yes, I agree. My opinion really doesn't matter. But, if that's the case, then neither does yours. Whether the opinions themselves address objective or subjective matters, at the end of the day, they are nothing but feelings. And feelings don't matter. Only facts.
Click to expand...
Click to collapse
Again "glaringly obvious" is opinion based. You're treating your opinion as factual.
I'm not saying my opinion matters either, what I'm saying is based on fact. Whether or not you like it, or I like it, it exists and is how it is.
Now, again, you can adapt to it, or just not update ever. I don't really care what you do, but I don't think much else is going to cure your grievances.
For every person that didn't like it during tested, at least 1 did.
I suppose you could write to them and tell them they should design it how you like it. Or to hire you, since you obviously know what everyone else wants on the UI.
jallenhayslett said:
I started this off as a response to another thread inquiring about bugs or issues with 9.0, but ended up writing up a full piece about the useability and functionality of the system and decided to make it a new thread. In short, I suggest to anyone considering the update, if you're happy with your current set up and are not fond of relearning how to use something you carry and depend on every day, then you will probably want to stay on 8.1.
I used it from the day it released up until 2 days ago and found it to be a massive clusterf*ck of UI/UX inconsistencies, glaring white, and broken useability features. Notifications are a mess, settings and features which were organized into reasonable categories are now buried in unrelated submenus and renamed confusingly, reliable UI/UX features have been swapped with newer less obvious actions, gestures, and unclear UI elements, drastically unrelated font families have been thrown together to create a very visually jarring reading experience, the system UI has enough white-on-white you could use the phone as a beacon in a storm, and the color choices seem to have been based on focus groups conducted with toddlers. Maybe it's just me getting old and stubborn towards change, but the consistency and predictability of 8.1 is nowhere to be found in 9.0.
As for the backend, a lot has been added, more than I can recall or understand, but the PrivateDNS and MAC randomization are nice security upgrades that are actually useful for those who live in places with ubiquitous but often sketchy, less-than-open internet fuctionality. It is noticeably faster visually, but also particularly faster in dealing with larger files and database types of information. Small tweaks, like the media volume default, and the dynamic rotation icon in the navbar, are welcome additions, but those come at the expense of the god-awful, take it or leave it, reworking of the Recents overview page. I know it's currently optional, but I gave the new gesture system a go, and eventually got used to it. However, it's going to take some massive tweaking down the road for it to be anywhere near as efficient and simple as the old navbar and vertical card overview.
Core device functionality is fine and battery was fair, almost the same, but I run a very lean system and also disable a lot of services since I currently live in a country with restricted Google access and most of those features are useless to me. Camera is still best-in-class and shouldn't be expected to change since the core camera functionality is in the hardware, the Camera app, and the Pixel Visual Core extension app. Basically any system apps that update via the Play Store should and do function as expected without any noticeable problems. While not specifically a Google problem, it's still worth mentioning that some apps are not yet ready for 9.0 and need to be updated by their developers.
My personal opinion, 9.0 is Android's "Windows Vista" moment, and they'd be smart to pull the whole thing back to beta and hold the release until they get their UI/UX overhaul ready for a full primetime roll-out. The system runs like it was built and tuned specifically for the Pixel hardware, but the user experience made me cringe every time I picked up my phone.
I spent the last 36 hours downgrading to 8.1 from a full wipe, clean setup, and restoring an adb backup. I now have a phone that I actually enjoy using again and I couldn't be happier with it.
Edit:
In considering a few friends opinions regarding Betas and Developer Previews, I'm inclined to temper my opinions, but only slightly.
Yes, I agree, that taking part in the Beta and Developer Preview (DP) process of OS releases helps determine many important aspects of the OS. However, in the case of entities this large, that involvement is really only meant to be as bug chasers. Beta and DP user's opinions on UI/UX matters are largely ignored, as they do not fit within the framework of said entities larger goal: Mass Usage (i.e. the lowest common denominator, AKA the ignorant child-like masses). They only want you for your ability to create and willingness to report showstopping bugs. They don't need the developer or niche user community to make UI/UX choices, they have focus groups for that. Unfortunately, the customer isn't always right, and people don't usually know what they actually like or why. Chase opinions, focus groups, ad engagement, click data, and the fastest dollar, and eventually we'll all be living in a Fisher-Price world (see: Asia).
The second problem with participating in these not-really-beta and almost-but-not-quite-developer-previews is that, not only have they already made all of the major decisions about how it's going to look and be used, expert use and experience be-damned, but by participating in these programs, the user is effectively subjecting themselves to a brainwashing scheme meant to dull the discerning mind into believing that "vX.X is so much better now than when it first hit public preview". It's the equivalent of software Stockholm Syndrome. Public Beta and DP users have deluded themselves that this final release is ok based on how they saw it change from the first public preview release. It's still just as awful as it was when it first went public, it's just a slightly better shade of awful.
It's a damned shame such a powerful and well running OS feels like it had such an awful UI/UX thrown on top of it. It's inconsistent, half baked, and feels like a grab at the ignorant, screen-obsessed masses, if they were color-blind with 20/200 vision. This is professional grade coding with pre-alpha grade UI/UX. A system built for power with a GUI designed for infantiles, on a device aimed at enthusiasts. They should be ashamed.
Click to expand...
Click to collapse
Just buy a Samsung phone and you won't have to worry about Pie for another year or two.
DuckRuckus said:
Just buy a Samsung phone and you won't have to worry about Pie for another year or two.
Click to expand...
Click to collapse
This.
Large Hadron said:
Besides which, Vista's problems were of a different order to this
Click to expand...
Click to collapse
That we can agree on. It was a nightmare of a different sort. That's just the best analogy I could come up with at the time.
As for yours and everyone else's reponse regarding this being just opinion, I agree. I just had such a visceral reaction to the changes that it prompted me to write about it, and the more I wrote, the more disgusted I became. It's 90% subjective opinion.
I do, however, stand by what I've said, especially regarding their use of white, the color choices, and most specifically the mixing of unrelated font families within the same app. From a design perspective, theoretically, they just shouldn't work, but clearly they do for some people and that's just baffling to me. Moreover, it doesn't simply just not work for me, it makes me physically uncomfortable to use them. I've even gone so far as to turn off updates and detach from the market any of the apps which will be getting the MD2.0 makeover. For me they are so aesthetically revolting that using them is actually a chore.
So yeah, it is all subjective opinion. It's just very difficult for me to understand how something that elicited such a gut wrenching physical revulsion from me has either the opposite or no effect on other people. I would have expected a much larger amount of agreement. Such is the nature of opinion and perception, I suppose.
As for the "ignorant idiot" comments, that was not intended to make anyone feel as such. It was meant to illustrate how most of these companies, for the sake of money and reaching the widest possible audience, are in a race to the bottom. If 90% of the population happens to respond to infantile visuals, then that is what they will strive to create. The problem with that, however, is that it creates a negative feeback loop that results in ever decreasing usability and a perpetual dumbing down of not only the system, but of the people that use the system. It reaches a point where it's no longer about the balance between function and form, but whether or not a 3 year old will smile and giggle when they pick it up. Sophistication goes out the window in favor of raw simplicity. Think "Idiocracy", but applied to consumer tech instead of life and politics.
DuckRuckus said:
Just buy a Samsung phone and you won't have to worry about Pie for another year or two.
Click to expand...
Click to collapse
I'd rather die in a raging house fire in a cabin in the woods alone on Christmas Eve than ever buy another Samsung phone.
jallenhayslett said:
As for the "ignorant idiot" comments, that was not intended to make anyone feel as such. It was meant to illustrate how most of these companies, for the sake of money and reaching the widest possible audience, are in a race to the bottom. If 90% of the population happens to respond to infantile visuals, then that is what they will strive to create. The problem with that, however, is that it creates a negative feeback loop that results in ever decreasing usability and a perpetual dumbing down of not only the system, but of the people that use the system. It reaches a point where it's no longer about the balance between function and form, but whether or not a 3 year old will smile and giggle when they pick it up. Sophistication goes out the window in favor of raw simplicity. Think "Idiocracy", but applied to consumer tech instead of life and politics.
Click to expand...
Click to collapse
This is so hilariously pompous, you must have an insanely high opinion of yourself.
The fact that a UIs design elicits this degree of a response from you is ridiculous.
You seem to think that anyone that doesn't share your opinion on design is an idiot, which is pathetic.
"I don't really like Jackson Pollock" "Oh the world is burninggggg! it's Idiocracy! Wahhhhh"
crixley said:
This is so hilariously pompous, you must have an insanely high opinion of yourself.
The fact that a UIs design elicits this degree of a response from you is ridiculous.
You seem to think that anyone that doesn't share your opinion on design is an idiot, which is pathetic.
"I don't really like Jackson Pollock" "Oh the world is burninggggg! it's Idiocracy! Wahhhhh"
Click to expand...
Click to collapse
Funny. I actually don't really like Jackson Pollock. Good call.
I'm not having any of these problems, I went and did a complete wipe and Flash the factory image not the OTA, TWRP and rooted, with ElementalX kernel
This post threw me for a loop. I guess mileage will vary??? I've been on 9 for several days now and I love it. It's snappier and there are features available now that I debated selling the phone over. I'm glad I stuck with it. I had a touch screen latency problem that is gone now. If it wasn't I would have ditched it and moved on to something else. Not much substance or quantification in this post but my vote is solidly with 9.0. My opinion only. I firmly believe 8.1 looked good but had some serious issues. I've always believed form should follow function. It can look great but if it doesn't work, it doesn't matter.