Android 8.0 Oreo, thoroughly reviewed
arstechnica.com
arstechnica.com
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, target-densityDpi=medium-dpi">
Just as a quick point and I will drop it in the article comments too. I'm the lead for our Chrome Developer Relations team.
Chrome doesn't disable picture in picture for Youtube, Youtube disable it in Chrome. They listen to resize events iirc and then exit fullscreen mode (the only way to currently get to pip mode in Chrome).
That applies to blocking Google ads, as well as fixing Youtube malfeatures.
Of course, it's understandable you won't see this from a browser paid for by Google. But you can't paint in broad brush strokes like "I don't think hiding side-effects or user actions helps anyone."
I'm not saying that there can't be meaningful response from the browser to user hostile actions, I don't think anyone disagrees.
There's a broader question about a user's will and the sites intent especially when it comes to business plans of the site that I'm not sure if access to features native in the browser is aligned with say ad blocking or tracking etc... I don't know.
The site's business plans are not my problem. Basically, my phone and my computer should do what I want. Why is there even an API to make a video player enter/exit full-screen mode ? That's 100% a user decision and there is no valid reason why that should ever be exposed to JS.
There absolutely are valid reasons and responsible uses for the browser to expose that API. Instead the argument should be around the irresponsible uses justifying hiding that part of the API.
Valid reasons to expose full-screen to the API:
* An "Always full-screen videos when I play them" button. * Remote control of demo displays, kiosks, etc. Force them to all fullscreen and play a video synced up. * Disable unnecessary features when website is full screen (e.g. stop polling website for changes) * Exit full-screen on certain conditions. For example on a shared streaming site like Rabb.it, maybe if someone joins your chat room (assume this is configurable by the user)
In short, you can use JS to respectfully enact user decisions.
I'll also mention a related case. On Safari iOS, you can't autoplay a <video> element unless the user has interacted with it via tapping it. The goal, obviously, is to stop autoplaying videos. The goal, of stopping annoying autoplaying videos, is noble, but at the cost of removing the possibility of responsible usage. Maybe it's worth it, maybe it's not, but there is an undeniable tradeoff.
A possible solution is having a "responsible app mode" in browsers. Whitelisted webpages have full access to these privileged APIs which would otherwise be stubbed out and non-functional (hopefully in a way that a webpage can't detect).
Also, especially for video, the browser should be able to play it full screen without any distractions.
Of course, there are optional enhancements (subtitles, or different audio tracks) driven via JS. And for those the controls have to go somewhere.
Ideally, if there were a standard for those, the browser could handle it. (But then we're at the problem of an ever bloating browser.)
I think you're overreacting to one bad-actor. Inevitably your suggestion here leads to good-actor pages having much less power to present good UI to its users. The browser has to think of all use-cases and have options for that, rather than defining lower-level hooks that pages can do what they want with.
Would it make you feel better that there already many other ways that pages can do user-hostile things? Have you ever visited a page that blocks right-click? Would you want to forbid Mouse Events because of this?
> You're asking that the browser define its own UI for an exit button.
Yes. Currently firefox puts a "to exit full screen press esc" OSD already on videos, that also interferes with visual presentation of sites/directors. So ... directors already don't put shit there.
The same thing goes for walled gardens (like Apple's - they don't allow some things), the problem is not that it's curated, the problem is that there are insufficient tools available for users to put their walls where they want.
Yes, by default I don't want to allow blocking right click. (You might be familiar with the saga of this bug https://bugzilla.mozilla.org/show_bug.cgi?id=78414 . )
No, the left mouse button is for interaction with the webpage, the right mouse button is mine. Just don't send any events for the right mouse button.
The historical answer does the same, as browsers were explicitly designated User Agents, as their whole purpose is to act in the name of the user, and fulfill whatever the user wishes to, which also clearly places the will of the user over everything a website may wish to.
How you interpret this is obviously left to you...
> The historical answer does the same, as browsers were explicitly designated User Agents, as their whole purpose is to act in the name of the user, and fulfill whatever the user wishes to, which also clearly places the will of the user over everything a website may wish to.
The browser is a User Agent, I agree. This doesn't mean they can predict all user hostile behavior and fix it before it ever happens. Browsers often fix bad behaving websites over time. Recently there's been a lot of effort to fix pages that cause scrolling jank when they load ads in the background.
There’s been countless cases brought against ad blockers, and all that were about ad blocking, were decided favourable for the blockers.
Additionally, there’s a precedent that users want to be able to control what a site does, and are willing to take extra steps to achieve this, so a browser should implement such functionality ideally in the first place.
I don't care about helping developers who want to hinder my usage of my browser on my hardware. It's my CPU they are executing on, and thus it should be I & I alone who determines what is executed.
Just like my browser blocks popups, and my browser blocks those sites that try to prevent right-click, and my browser blocks those sites that spawn dialogs when you try to leave them, Just in the same way I want my browser to force websites to allow PiP.
The current version 55 is a little slower than Chrome on my 3 year old phone, but performance in the past few major versions has definitely improved. The nighty developer build of Firefox 57 absolutely flies.
Mozilla is doing an amazing job with their Firefox modernization, it's a shame how little attention it gets on Android.
Video Background Play Fix https://addons.mozilla.org/en-US/firefox/addon/video-backgro...
I think a better question is why would a talk/podcaster be using YouTube for distribution?
Browser block popups, forcefully enable right-click on sites that disable it, browsers allow users to forcefully enable zoom, or background playback.
And just like that, browsers should also allow users to forcefully enable PiP.
Too bad Mozilla won't ever dare to defend themselves from Google's bullying and will happily accept having background playback on YouTube, until now one of the primary motives for people to try Fennec out, being taken away.
https://bugzilla.mozilla.org/show_bug.cgi?id=1355407
RESOLVED WONTFIX
If not, then since Chromium is open-source, I imagine you could hack it in to a personal copy.
E: This is a simple and earnest question. Why the downvotes?
The viewport meta tag is part of what makes RWD possible. [2] The viewport meta tag does not relate to PiP in any way that I can imagine.
[1]: https://developer.mozilla.org/en-US/docs/Glossary/Responsive...
[2]: https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/View...
I've been a bit frustrated with android's sparse docs and unreliable build tool. Whenever I try searching for additional information, all I find are questionable tutorials and xda-developer threads. I don't have anything against the forum itself, but I find it a bit questionable to see so many people happily propagating and flashing random binaries. Is xda-developers still the main place to go when looking for help, or have any other communities started to overthrow them?
Now with 8.0 out, it seems like a good chance to retry building my own ROM. I'm thinking of forking CopperheadOS [0], and applying some minor patches on top. Is anyone here running their own ROM, or Copperhead in particular? I'd love to hear about your experience, along with any pros and cons. F-Droid seems to be capable of handling all of my requirements. My only big remaining concern would be with Project Fi; I'm uncertain if the service will work if Google Apps aren't installed.
I've been able to successfully build Android on Arch Linux. Depending on which particular ROM you're building, much of the required build environment is packaged with the source. I just needed repo's dependencies and to rebuild the prebuilt Bison with the included source.
> I've been a bit frustrated with android's sparse docs and unreliable build tool.
The guide at https://source.android.com/source/ should result in a working AOSP build. I've followed it before without problems. My guess is you're trying to do something weird that makes sense to you that isn't really supported.
> Is xda-developers still the main place to go when looking for help, or have any other communities started to overthrow them?
XDA is still the primary place ROM development is carried out, yes. Finding a ROM's IRC channel can be helpful too.
> Is anyone here running their own ROM, or Copperhead in particular?
I built Copperhead for my Pixel but unfortunately it resulted in a bootloop so I gave up on it. I'm running PureNexus right now and might try Copperhead later.
> My only big remaining concern would be with Project Fi; I'm uncertain if the service will work if Google Apps aren't installed.
I don't think it'll work totally bereft of Google services but you might be able to manage it with MicroG: https://microg.org/
The Good
Project Treble isn't a silver bullet for Android's update problems, but it's the first time in a long time Google has changed Android to make system update development easier.
I love the smaller "by the way" notification section. It really cleans up the notification panel, while still letting the user read less-important notifications at their leisure. I just wish I could demote any app to "less important," regardless of what version of Android it targets.
The automatically-colored media notifications look amazing! Sometimes I cycle through songs with the notification panel just to see what it comes up with.
The background processing lockdown has been a long time coming. Finally, we'll see the end of wakelocks.
Picture-in-picture on a phone is great for videos, and Google's experiments with things like Google Maps look very promising.
EmojiCompat and downloadable fonts means Android users should get new emojis super fast. You don't even need Android O for this to work—it will work on Android 4.4 and up!
The Bad
Google's revamp of notification controls has the side effect of removing fine-grained notification controls for most apps. We'll have to wait for every app to upgrade to get the controls back.
The ambient notification display gets a huge downgrade, changing from showing the full notification panel to only showing tiny status bar icons.
Snoozing notifications could be a great feature, but the timing options are so limited that it's useless. A max of one hour? Seriously? Give me a time picker.
The disabling of Chrome's picture-in-picture support specifically for youtube.com is downright sleazy. That's not how Web browsers are supposed to act.
The Ugly
Updates—they're still a huge problem. Here's hoping Treble actually helps.
Chrome doesn't disable picture in picture for Youtube, Youtube disable it in Chrome. They listen to resize events iirc and then exit fullscreen mode (the only way to currently get to pip mode in Chrome).
FWIW you can control the notification snooze timeout, but you're going to need Tasker [1] (or similar). Interestingly I evidently bought this several years ago - can't remember why - and haven't installed it on at least the last two phones, since some version of Android a few years ago shipped with whatever native functionality Tasker used to provide for me.
[1] https://play.google.com/store/apps/details?id=net.dinglisch....
I have enabled it and will get to try it in 12 hours from now.
Twilight has Hue integration, gentle transition, and a few other nifty features, which I'm probably not going to want to abandon - though I'm sure the native feature will gently encourage me to re-fit out my Home with a confusingly named Google product.
Edit: And adding a little more I just read, because it uses a red overlay it red tints what was pure black pixels which isn't helpful.
>> After my Pixel updated recently to Oreo, being frustrated by a constant notification for Twilight
It draws a red layer on top of everything else. This is why the system displays a notification : it wants you to know that an app is drawing on top of everything.
The system settings works very differently, it directly applies a matrix to what needs to be displayed. This is way more efficiencient since applying this matrix is basically free instead of adding one layer with alpha composition.
It also allows other customizations, like adapting the screen for deuteranomaly.
Ideally, Google should open the API behind this feature at some point.
Since 8.0, it is impossible to get any kind of night light on the Nexus 5X without a custom rom.
The issue is that there’s no device suitable for development (meaning that you get preview releases, so you can fix your bugs before users have the new android) which also supports Night Light.
Also, why do you need to test night light on O ?
Does this work for you?
By default you can snooze notifications for, at most, 2 hours.
I'm surprised more people aren't complaining about this.
>Treble promises to change everything. Malchev says that Treble standardizes Android hardware support to such a degree that generic Android builds compiled from AOSP can boot and run on every Treble device. In fact, these "raw AOSP" builds are what will be used for some of the CTS testing Google requires all Android OEMs to pass in order to license the Google apps—it's not just that they should work, they are required to work.
Ron paints a rosy future here:
>Custom ROMs shouldn't need to be painstakingly hand-crafted for individual devices anymore—a single build should be able to cover multiple Treble devices from multiple manufacturers. Imagine the next time a major new version of Android is released—on Day One of the AOSP code drop, a single build (or a small handful of builds) could cover every Treble device with an unlocked bootloader, with a "download Android 9.0 here" link on XDA or some other technical website.
If this comes to fruition, the ROM community is going to go nuts. This is enormously exciting and Oreo will turn out to be a real turning point for Android.
One thing that is interesting though is the implication that Android updates will get more iOS-y in the future. By that I mean certain features will be missing from updated phones because the HAL layer doesn't support it.
(Copied over from previous discussion here: https://news.ycombinator.com/item?id=15167138)
What features are you referring to? Also, will that be worse than the current situation for Android devices?
I prefer T-Mobile.
But I think we've been burned too many times by Google's promises to "make it easier" for OEMs to update devices and other such promises, or at least these projects always sounded much better than they turned out to be. Hopefully this time it is different.
I would be curious to know when Project Treble started. I imagine something like this, and if it was serious enough, would take 3-4 years of development and thought put into it? If it's less than two years then I would probably be worried about just how much thought and development Google put into it. I would also be disappointed that Google only started taking such a project seriously two years ago - or seven years after Android officially launched. Some could say this "feature" should have been enabled from day one.
I would really love that. It would take the "how crappy is the vendor UI?" problem out of the equation when looking to purchase a phone.
>Google shared a fun statistic at I/O 2017: The company expects one-third of Android devices shipped in 2017 to cost under $100.
Even more so considering that the US is the 2nd largest market for phones of that price point.
> While the long term goal is to tackle the 5 billion users without internet access, immediately this helps the US market too. Google says the US will be the second most popular market for these sub-$100 phones.
Hopefully we'll see some reviews once hardware and apps make a foray into this new API.
If anything O makes you think that Google plans to keep Android around for the long run since it aims at putting it in a good architectural position for the next 5/10 years.
You cannot judge battery life after only a few days, specially after an update.
1. Do you charge it to 100% and live it alone until charge goes to 0%?
2. Do you unplug it in the morning and use it "normally" and see what charge will be left when you put it again on a charger when you go to sleep?
Different use cases drains battery at a different rate and its hard to use a new phone/a phone with a new OS "normally" because more time than usual will go into trying to understand it.
It may also happen that you start using the phone at a time when your phone usable is above your average.
But I won't decide I know for sure it's a problem for everybody, obviously (which doesn't mean either it isn't).
EDIT: but as philjohn mentioned, you can expect to use your phone more after an update (especially a major release) to try new features and because of renewed interest.