Related
Hello.. I have been sinking my teeth into this realm for several weeks, and have noticed there seems to be a fairly important topic that is rather underdocumented.
People throw the word "ROM" around, but really with these devices there are several layers of software at work in this regard. I'm about to sound like the ultimate noob, so forgive me. But for example, users hear of a "splash screen ROM".. we read about SPL and its variants.. and of course the OS images everyone here loves.. somewhere in here there is a region accessed and manipulated by MTTY. So what it means to "flash a ROM" can vary wildly.
What I need (and many others would benefit from) is a link to a document that maps this out, describing each of the divisions of the device's low-level software, how they fit into the boot sequence and overall picture, and ideally, which of our tools they are connected to.
What happens once Windows loads is well documented, but what happens before this seems to be as crucial as it is undocumented (that I know if). Many people on these forums are quite technical, despite admitted ignorance of mobile device architecture. A better understanding of the playing field would eliminate much of the confusion users face. Many of the tools themselves are well documented in terms of usage, but their actual technical impact is a mystery to many.
Can anyone recommend any such reference(s) that might de-mystify the architectural aspect of our beloved phones and ROMs?
Yep, basically tackling Java and Android at the same time.
I've no problem with OOP, I just tend to find it... inefficient in terms of CPU usage. I'm curious though (considering I've actually never had any 'formal' programming training in the 15+ years I've been programming), as far as smart phones go, and current technology - is there a lot of difference between OOP and procedural coding still?
Let me use an example - let's say I'm wanting to pull some information, say.... doing a basic lookup.
The way I tend to program this, would be in my general program, I'd just do a direct lookup. I've got a co-worker who is a big OOP proponent, and his method would be to build a small function that performs the lookup, and call that function instead.
Am I wrong in thinking that would waste extra cycles calling the other function vs just coding what would be in that function directly in-line in the program?
The reason I'm even asking this, is I'm working on breaking down my first Android program (just a basic phone analyzer) into various activities, and it got me thinking about OOP on Android in general. I can see how the various activities all flow one to another - that's not what I'm talking about, here.
It would seem to me that with limited resources, you'd want to maximize what you've got.
Maybe I need to build a little benchmark program to test this out... it may turn out that very little is wasted, and hey, maybe I just don't have as firm a grasp on what's going in in the DVM as I'd like
A good compiler will optimize away much unnecessary code. GCC will for example if told to put (properly made) function calls inline so your method of doing lookups is in reality worse. It'll make code cluttery, hard to maintain and no better performing.
Of course using a vm will have a negative impact on performance compared to perfectly written and built C code but this is for obvious reasons very seldom possible. The speed of developing is oh so much faster using OOP than true procedural programming. Even java is way to clunky many times. It does not matter that code that is ran once or twice or trice is twice as many instructions it could be. Profiling the application and using good algorithms is were gains can be made and all of the sudden the easily replaced oop code is alot more efficiant approach than just sitting down and take the easy route.
There is no way to code in java that is procedural that I can think of... every file is a class with methods and properties. You have no choice but to code using OOP.
procedural = garbage anyway.
Am I wrong in thinking that would waste extra cycles calling the other function vs just coding what would be in that function directly in-line in the program?
Click to expand...
Click to collapse
Yes... you are wrong. The reason being that each method or property is a different memory address essentially... and the more code you have in each address the slower the program.
@OP,
If you have a bunch of small & simple functions that are related to eachother that you want to call from all over your application, you may want to make it a pure static class. That way you won't have to initialize an object. That being said though, if you want to get into serious java/android development, you are best off learning some OOP principles anyway. At the very least things like inheritance, RAII, factories, etc.
There is no correlation between OOP-ness of a language and its speed.
androidworkz said:
procedural = garbage anyway.
Click to expand...
Click to collapse
That's why the linux kernel (android!) was written with a procedural language, right?
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.