Keeping my fingers crossed that Project Treble is the real deal and would actually make it possible for a "generic AOSP image" to be installed on virtually any mobile device that came with Android. That's the dream, isn't it?
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.
Is Project Treble "backwards compatible" with old models? If so I hope it will work out for Fairphone users, especially the first model which is doesn't receive as much support as the Fairphone 2
Not backwards compatible mostly this has seperated the hardware drivers from the os itself but unless the device system partition is repatitioned and the drivers been provided by the hardware manufacturer old phones won't get updated any time soon. Mostly the newer phones that are released with Android O will have the ability to update to the latest version of Android missing a few things that your phone doesn't support like iOS does with older iPhones even if the Oem no longer procides updates..
No. In theory you could backport it to older phones, and OEMs allegedly might, but I wouldn't expect that to be the norm and it's not mandatory from Google in order to get Oreo.
Would you care to explain why? (provided that when we speak of battery life, we mean how much time it can go without recharging, and not after how many years you have to change it)
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.
I have a daily routine, always charging my phone at the same time, always using it at the same time. If after an update I notice the day after my battery is drained one hour before the usual time, it sounds pretty safe to assume the update did something regarding it.
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.
Because when you install a new OS there's things that are optimized in the background, and you also tend to use it more because of the "new and shiny" factor.
Stop what? Been on Oreo release since it shipped (we're past the optimization window), plus beta. Went from 1.5 days of battery to .6-.7 days of battery after Oreo on the 5x. Was hoping it was just a beta issue. Unlees you like battery anxiety, you may wish to wait to upgrade if you have a 5x and you use it daily. Project Fi as carrier. YMMV.
Battery life was a little bit worse (not much) on my 5X with the preview releases of Oreo. 5X died from bootloop before I could upgrade to the final release.
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.
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).
If it's true that Chrome on Oreo genuinely prevents picture-in-picture for YouTube specifically, that's a troubling precedent to set. Why not allow all websites to enable/disable PiP (maybe via a meta tag, in the way that tab theme colours already work)? If I query https://m.youtube.com while emulating a Nexus 5X, the response contains:
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).
Then Chrome should have an option to stop the resize handler from firing when entering PiP mode. The user should always have the right to override what the website is doing.
So you would like us to not tell the page what the render is doing? I'm not sure how that would play out for any number of API's that exist on the web. Developer's have consistently had the means to override the default actions of the browser (think drag and drop) but I don't think hiding side-effects or user actions helps anyone.
I'd like to be able to tell my browser what it should tell the pages it's loading, especially if pages are leveraging it to do things against my will.
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 disputing the fact there was a casual offhand design, and I don't think hiding the state of the render or the browser helps anyone not least developers who need the information about the state of their page.
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.
> There's a broader question about a user's will and the sites intent especially when it comes to business plans of the site
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.
Sounds like you are advocating for something very different than the current APIs. You're asking that the browser define its own UI for an exit button. How does it know where to put that? What if it is a game in a `<canvas>` element and the button overlays some important UI in the game?
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?
I like the trust model that current browsers do. If I trust a page they can use the full viewport or screen, and a lot of keys, etc.
> 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.
Why not just restrict it to user-initiated events that can exit or enter full screen? Similar to how you have to press a button to enter full screen mode. It seems to make sense to do the same thing to exit, or other various actions.
>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.
There is a long history of browsers disabling or crippling features because they get abused by web pages. In fact is is almost a rule that if a feature can be abused, it will be abused.
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).
Well, the legal answer clearly places one side in the right (the user has the right to modify websites that are shown on their system however they wish to, and the right to circumvent all measures on that site, as in the countless ABP vs. ... cases has been ruled).
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...
Simple, it means that if the browser would decide to force YouTube into allowing PIP, that would be the browsers legal (and moral right).
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.
There are already numerous examples where browsers intervene to stop user-hostile pages. The reason pop-up ads largely don't exist any more is because browsers intervened to kill them.
This is not a legal discussion, no one is saying that the user doesn't have a right to block this behavior.
> 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.
> I don't think hiding the state of the render or the browser helps anyone not least developers who need the information about the state of their page.
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.
Actually, yes. I want that the user is able to force a page to do whatever the user wants, if they choose to do so.
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.
That would be an excellent way to force Google to switch distribution of all content via YouTube to HTML5 EME with Widevine DRM, given it's pretty clear their music agreements prohibit permitting this.
Most of YouTube content isn't music though. Why are they so user hostile - e.g. why can't I listen to talks/podcasters in the background while browsing the internet?
But I'm not, so I'm not allowed to. I wouldn't have a problem with it if I could - paying for ad-free YouTube with added features seems like a fair deal to me.
I wouldn't call "letting me turn off the screen or switch to another application while still consuming media" an "additional feature". Especially since they must go out of their way in the first place to detect when that is happening and to prevent me from doing so, as they do on their mobile website.
Good question. As they normally serve their content as separate audio and video streams, it should be perfectly feasible to do that. I wouldn't bet on it, however.
Try Firefox for Android - it allows background nedia streaming, and even puts controls in the notification drawer. It also allows adblocking, extensions, has the amazing reader mode which makes the most unusable websites readable again.
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.
Another reason to use Firefox is to resist the monoculture of just one dominating browser, that's also made by the same company that makes the most common mobile OS and a lot of dominating web services, like Youtube. Allo for the web still only works in Chrome, because Google know they can get away with it.
Nice suggestion, but note that, since Google started abusing the page visibility API for their scummy ends, using Firefox is not enough by itself in order to play YouTube media in background. To restore its ability to do so, you also need this add-on:
In a similar fashion, Firefox for Android should prevent YouTube from pausing when it detects it has lost focus, as that's clearly an abuse of power with the shameless intent to inhibit non-Chrome browser functionality. See my other comment a little up the tree.
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.
Responsive Web Design (RWD) is a Web development concept focusing on making sites look and behave optimally on all personal computing devices, from desktop to mobile. [1]
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.
Quick comment on notifications: it seems that Android has really worked them out nicely. Now I even more prefer Android notifications to iPhone notifications.
After my Pixel updated recently to Oreo, being frustrated by a constant notification for Twilight (a red-tinting background app) and starting to search on google for a solution -- I discovered quite a lot of people have been asking 'how to suppress notifications on oreo' recently.
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.
Gentle transition periods (I have mine set to a half hour), offsets from sunset/sunrise, hue (and other smart bulb) integration. A few other features that I don't use. I'm experimenting now with native compositor, which hopefully presents a better colour mix than Twilight was able to (good but not perfect).
I am using the built-in "Adaptive brightness" with my Pixel XL and have also used twilight, f.lux (on a rooted Nexus 6). I would say to just go with "Adaptive brightness." It has the least issues overall and definitely won't be a bother in terms of persistent background notifications or anything else, especially with the new Android.
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.
Great, how does that help me on my Nexus 5X? Alternatively, do you get Android Preview Releases on your Motorola Play?
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.
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.
My understanding was that unless you were rooted Twilight doesn't actually filter out blue light. Instead it does a red overlay. That makes the screen brighter which lets you turn down the overall brightness resulting in less blue light but it's not as good as a true blue light filter that actually removes blue (which is what the built in support does and why it needed hardware support).
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.
Yup, but I like it even more out of the way - the Tasker / script approach to (via the API) tell it to snooze notifications for some years is likely the best bet.
By default you can snooze notifications for, at most, 2 hours.
Can anyone confirm if they brought back the ability to select a wifi/Bluetooth connection via a drop-down from the swipe down option? You know, without having to click and go into the screen to select the device you want to connect to.
I knew Project Treble was exciting, but this is really interesting:
>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.
Can somebody say something about what Treble means for other open source OS for phones, e.g. Sailfish? Might it be possible to use the vendor provided Treble core for other OSs?
How many people build their own ROMs? When I bought my Pixel I tried my hand at building my own ROM, but I kept stumbling and eventually gave up. Admittedly, I was running a newer version of Ubuntu than the one they suggested in the docs, but I didn't expect it would break everything. Am I right in guessing that using a VM would be the easiest path to success?
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.
> Am I right in guessing that using a VM would be the easiest path to success?
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/
Using Fedora 25 building Android 7 for Nexus 5X is relatively simple. The only caveat is that to really take advantage of the hardware you need vendor blobs which you can get by running the scripts at https://github.com/anestisb/android-prepare-vendor
I haven't tried building my own ROM, but XDA is my first (and usually only) stop when I want to flash a new one. Don't most developers make the code open source? Perhaps poking through others' code would clarify some things. I'd be willing to bet people hang out in some IRC rooms, too.
you can probably achieve it by modifying framework-res.apk. At least it worked on Nougat, copied the colors from Pixel to get its blue theme on my Nexus 5
>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.
Perhaps slightly off-topic, but what are the best hardware/carrier options in USA currently if you want vanilla Oreo that updates reliably instead of a custom ROM (w/ no carrier or third-party overlays and skins)?
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.
Yeah, I saw that at the end of the article. A little short on details. I hope it really is low latency though, and can be used for real-time synths, trackers, dj mixers, etc. It would be nice in the future to have a small attachable audio interface we could hook up to our phones or tablets and work out some tunes on the go. I hope Android can start doing the same things as iOS in this regard.
Hopefully we'll see some reviews once hardware and apps make a foray into this new API.
129 comments
[ 5.2 ms ] story [ 115 ms ] threadBut 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.
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.
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).
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.
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?
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.
> 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 . )
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).
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...
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.
> 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.
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.
I think a better question is why would a talk/podcaster be using YouTube for distribution?
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...
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...
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'm surprised more people aren't complaining about this.
>> 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 ?
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.
Does this work for you?
By default you can snooze notifications for, at most, 2 hours.
>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'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.
[0] https://copperhead.co/android/
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/
>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.
I prefer T-Mobile.
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.
Hopefully we'll see some reviews once hardware and apps make a foray into this new API.