Related
Hey guys very very important question , it's about the sar rating when we make calls . Sar represents radiation hazards to the brain and , most phones have predetermined valuethat is approved before they are sold for safety . Please can somebody do a test about this
htc hd2 running on winmo is safe but running on builds like the ones here we are not sure
i hope that the forum members and the developers for tons can find out and let us know.
Very very important !!!
im taking a guess here, but wouldn't it depend on your radio rom not the build?
can someone confirm or dispute this?
primaraly your looking at hardware such as antana and shielding. im doubtfull that diferent radio packages are going to boost things to unacceptable levels, otherwise mfg's wouldnt cook them up.
both winmo and android runs on the same radio regardless of wich one is booted.
does that make you feel more warm and fuzzy on the inside?...... or is it from to much radiation?
Once again, cell phone radiation poses absolutely no dangers to the tissues of your body.
You want to know why?
There is not enough energy in the radio waves.
There is less energy coming off of your cell phone's radio transmitter than there is coming off of your computer screen that you interpret as visible light.
Learn2highschoolphysics
enneract said:
Once again, cell phone radiation poses absolutely no dangers to the tissues of your body.
You want to know why?
There is not enough energy in the radio waves.
There is less energy coming off of your cell phone's radio transmitter than there is coming off of your computer screen that you interpret as visible light.
Learn2highschoolphysics
Click to expand...
Click to collapse
That's right
But if it does still, you won't die because of this radioation. It will only make you sterile if you carry your phone always near of your balls.
But then again if there are safety requirements about this than it is only
Logical to know that if a device exceeds a safe limit then it means
It could pose a health issue.
With that in mind , I hope that a test could be done to resolve the worry.
The radiation also has to with the antenna and battery consumption during
When the phone is searching for signal etc.
Thank you for the reply some of you have given.
ok, first, try educating your self before posting the same drivel in a bunch of diferent threads.
had you spent as much time searching how sar is tested as you did posting , you would have found that its tested @ the hardwares max output.
hmm... the software comes no wheres near pushing the hardware to the limit.
the radio software is the same in both WM mode and in Android mode
therefore this would lead to the conclusion that if it passed federal standards for sar emissions when run @ full hardware output, and we arnt driving it that hard, that we are at a level LOWER than what it was tested...
fariez44 said:
I hope that a test could be done to resolve the worry.
The radiation also has to with the antenna and battery consumption during
When the phone is searching for signal etc.
Thank you for the reply some of you have given.
Click to expand...
Click to collapse
please fwd me your bank info, and each specific condition you would like it tested.
its not cheep
http://www.metlabs.com/Services/Wir...ywgP2vhaUCFSBugwodfX3aOw.aspx?_kk=SAR+testing
http://www.ce-mag.com/archive/03/01/miller.html
http://www.rfexposurelab.com/
Well thanks for the information , I was looking for an explanation as such
It seems you resolved my doubts and thanks once again.[/B]
Need to take care of ourselves
I keep seeing people who claim to have headaches in the morning whenever they use specific builds. We also know some builds provide better cell signal and wifi capabilities. I strongly guess there is a difference between radiation levels of different builds.
If someone leads us to measure the SAR levels of builds under this forum to get an "XDA approval", we can surely all donate to her/him. Then we also can prefer the builds acording to their radiation levels.
Someone with knowledge please help us to determine:
- methods of measurement
- rules and standards of approving the builds
- safety classification according to SAR levels
Radiation is no joke. We are the only big enough developer community to provide this standardization to custom builds.
Radio waves are not ionizing, and thus do not carry enough energy to pose any danger whatsoever.
It is physically impossible.
enneract said:
Radio waves are not ionizing, and thus do not carry enough energy to pose any danger whatsoever.
It is physically impossible.
Click to expand...
Click to collapse
The effect of mobile phone radiation have been studied by a lot of scientists. There are thousands of articles about this topic. I agree that there are contradicting results but no single one claims as you said: "it is physically impossible" Or no scientist refused to do the research assuming that the high school physics is enough to finish the argument.
In fact a lot of researchers came into the conclusion that there is a corelation between cancer and mobile phone radiation.[1,2,3]
It has been basicly studied for the short and long term hazards. Long term hazards have not been completely studied yet due to the short history of word wide mobile phone usage. Short term hazards have been proven such as decrease in cognitive functions and prolonged response times. [4]
1. http://journals.lww.com/epidem/page...=2004&issue=11000&article=00003&type=abstract
2. http://oem.bmj.com/cgi/reprint/64/9/626.pdf
3. http://www.ncbi.nlm.nih.gov/pubmed/19285839
4. http://onlinelibrary.wiley.com/doi/...ionid=69BCBB4C4AC1B054C0B953A974547C77.d03t01
baybenbey said:
I keep seeing people who claim to have headaches in the morning whenever they use specific builds
Click to expand...
Click to collapse
Id bet that has wayyyy more to do with screen settings, size, brightness resolution refresh rate comparative brightness of the room( dark room more eye strain) than radiation.
Take two or three flights and you'll already have been exposed more than a small transmitter will give in its lifetime.
I have to admit I keep getting headaches with some phones when having long phonecalls. I'm sure it has nothing to do with the screen (always off during calls) or heating up of the phone (all about the same temperature while in use). In the past I would have laughed, but since I paid attention on when and where those headaches started, I'm pretty sure it has something to do with the phone radiation. Yes, the general radiation levels are pretty low, but still, they are concentrated at our heads and some of us might be more receptive than others.
First I noticed it with my old HTC Trinity. When I moved to an area with generally low reception, I kept getting headaches during phonecalls, while not having them in other areas where the reception was fine. Those headaches always started on the side of the head, where I held the phone. When switching to a bluetooth headset (which has much lower radiation levels) the headaches were gone.
Another example was the Nokia N73 which I had to use for a job I did. I never had a phone before and after which had such an excellent reception. Areas where I couldn't even get a signal with other phones, were no problem for the N73. I could make and receive phone calls without any problems (1-2 bars). For 3 days I had the phone around my neck with a lanyard. So it was resting on my chest all the time. And I can say for a fact that I got a weird feeling at exact that point. When removing the phone from the lanyard or replacing it with a dummy unit or switching it off, it stopped ...
There are various other phone where I can reproduce that. Unfortunatly.
I'm pretty sure too, that different builds have different radiation levels and the radio rom is not the only thing affecting those. When running WP7 on the HD2 I got headaches very fast (after 5 minutes) being on the phone. With Android (at least the ROM I use) and WM 6.5 those headaches only start after 1+ hour on the phone and even then much less. The radio rom might limit the maximum output, but the specific reception control still comes from within the OS.
So since I seem to be pretty sensitive on this, I'm cool with Android on the HD2. I don't get any more headaches than with Windows Mobile 6.5 (or other "low-SAR-phones"). However with WP7 on the HD2 I had serious problems having long conversations over the phone, comparable to my experience with the HTC Trinity in low reception areas. But I don't think that any of those levels are life threatening - it's just an inconvinience (at least for me). But being a gadget fan and geek that's a little bit of a letdown, having to admit that those things might actually be harmful in one way or another.
baybenbey said:
The effect of mobile phone radiation have been studied by a lot of scientists. There are thousands of articles about this topic. I agree that there are contradicting results but no single one claims as you said: "it is physically impossible" Or no scientist refused to do the research assuming that the high school physics is enough to finish the argument.
In fact a lot of researchers came into the conclusion that there is a corelation between cancer and mobile phone radiation.[1,2,3]
It has been basicly studied for the short and long term hazards. Long term hazards have not been completely studied yet due to the short history of word wide mobile phone usage. Short term hazards have been proven such as decrease in cognitive functions and prolonged response times. [4]
1. http://journals.lww.com/epidem/page...=2004&issue=11000&article=00003&type=abstract
2. http://oem.bmj.com/cgi/reprint/64/9/626.pdf
3. http://www.ncbi.nlm.nih.gov/pubmed/19285839
4. http://onlinelibrary.wiley.com/doi/...ionid=69BCBB4C4AC1B054C0B953A974547C77.d03t01
Click to expand...
Click to collapse
Yet, every study focusing on the overall cancer rate in comparison to cell phone adoption has found no correlation. There are numerous experimental problems with actually studying the supposed effect directly (in fact, there was a new york times article earlier this week written by an oncologist enumerating those problems, and why the research, either way, on this subject is fundamentally flawed).
However, the fact remains that if you are scared of this latest nonsensical boogeyman, you should also avoid exposure to all EM radiation of radio and higher energies - you know, radio waves, microwaves, infrared and visible light - goodluck!
I have to admit I keep getting headaches with some phones when having long phonecalls. I'm sure it has nothing to do with the screen (always off during calls) or heating up of the phone (all about the same temperature while in use). In the past I would have laughed, but since I paid attention on when and where those headaches started, I'm pretty sure it has something to do with the phone radiation. Yes, the general radiation levels are pretty low, but still, they are concentrated at our heads and some of us might be more receptive than others.
Click to expand...
Click to collapse
Obviously there is no way that you can get a headache from listening to a speaker placed a few millimeters from your ear for an extended period of time. Obviously, no bloody idiot would think that.
Re-read my post ;-) the speaker has nothing to do with the headaches...
Jeez this whole discussion sounds like one of those stupid news lead-ins like 'find out whats killing your kids... ...right after the break'
Surely there are worthier things to worry about than the radiation from cel phones. Just tune in to Fox News, you'll find plenty of ridiculous crap to worry about. Ask yourself this : if you know for sure that when you're 70 you'll have cancer from using cel phones all your life, will that be enough to make you stop using them now? I'll take the cancer over going back to pagers and pay-phones.
Sent from my HTC HD2 using XDA App
What's the problem discussing possible downsites of customizing our devices? It's not black and white, you know. We can discuss this stuff, and use phones accordingly to our findings and knowledge.
And as said before: It's not (only) about cancer (or any other long term damage this might cause). There are obviously short term effects for some people, why not try minimizing those?
I think it's no difference between WinMo or android builds radiation because the hardware it's the same whit its limitations....even if this wasn't true the livel of sar are not so high to damage our brain(it's possible some biological effect)...so take it easy...only God knows...perhaps
It is really weird that some people here, agrssively oppose individuals who are sharing their concerns by stating some scientific findings about the hazards of SAR. What is the purpose of trying to insult and silence people on the discussion of such a potential risk? Weird!
In the previous references I shared, more than one study of 10+ year of mobile phone usage statistics point out an increased incidence of brain cancer. There are many studies with this result.
And secondly, I found few articles which completely refuses the hazards and defends the safety of mobile phone radiation by agressively opposing(like some people here) the related scientific data. Most of them are suspiciously published from Finland(Country of Nokia). These articles are written in an ideologic and biased manner and falsify all the findings which prove the cancer corelation as nocebo effect or false positive. Or they study the effects of SAR on skin epitheliel cells(relatively resistant against radiation) instead of brain glial cells(sensitive to radiation) and -no surprise- in the end there is no serious harmfull effect... These articles urge to come into the conclusion that SAR is as lovely as blessing of God! Take a look at the discussion section of wikipedia on this topic. All editors complain biased and frequent editing of the page by someone who is adding suggestive sentences to defend the safety of SAR. Hmm...
According to some people here, by looking at the relative wavlength and frequency, microwaves are supposed to be less harmfull than visible light. In fact we can cook a chicken in a microwave oven but not in a sunny beach. SAR can not be found safe by comparing only wavelength/frequency. Who tries to do that obviously misses 3 major points which are:
- distance from source
- intensity of rays
- duration of exposure.
Anyway, even the fanatic SAR defenders in scientific community do not defend it by such a point of view.
http://www.anandtech.com/show/5630/indepth-with-the-windows-8-consumer-preview/1
Very LONG read, for those who haven't looked at it yet
But very well written. Not biased much at all. He brings up some good points, and makes very logical arguments.
I do want to point out one thing tho - almost every average joe PC user used a mouse as the sole input method, unless words need to be written, then you use the keyboard. As the author of the article pointed out, to use W8 with any type of efficiency you need to use either a touchscreen or lots of keyboard shortcuts. all of us tech geeks (and yes, if you're reading this, even if you're a noob that means you know exponentially more about tech than most people) are willing to learn and adapt, but most people don't even know that windows HAS keyboard shortcuts. it took me 20 minutes to understand hot corners 100%. how long do you think it'll take your tech illeratite mother to figure it out? a month? my mother still doesn't grasp how bookmarks in Chrome (which i installed for her so she could have an adblocked web) work, and she's had it for about 6 months.
point stands, yes, for us the learning curve isn't that bad. but for your average user off the street who doesn't know what a browser is (seriously, watch this http://www.youtube.com/watch?v=o4MwTvtyrUQ ) the learning curve is going to be too high to handle.
It is a well written article. To me the biggest argument is does it even matter for the average person to know all of the ins and outs of the start screen. As long as they can figure out how to click on the big icon labeled Internet, they can probably get to what they need. Once you're in the browser, metro is no longer applicable.
I think the basics are pretty easy to grab with minimal time on the system. So far I haven't had anybody NOT get it when I let them use it. Only a few minor questions at first which is normal for anything new.
Hmmm....
Well, the problem is that average users are very reluctant in breaking their old habits and often do not even WANT to learn something new. Unless something works roughly the same it used to before, they are not interested and write it off, because the "old one" was "so much better". I'm not saying all the people are like that, but a great deal really is, I used to work at tech support for quite a while and I think the video above is pretty accurate in terms of literacy in this field. People are very quick to write things off for the pettiest of reasons and 'interest' and plain curiosity fade fast.
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
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.
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.