Slashdot Mirror
Android O First Developer Preview Featuring Notification Channels, Background Limits Now Available (googleblog.com)
A year after Google released the Android N Developer Preview, the company has made available the developer preview of the next major version of Android, "Android O." You will not want to put it on your primary Android smartphone as the preview is likely to have rough edges. Google says as much. "it's early days, there are more features coming, and there's still plenty of stabilization and performance work ahead of us. But it's booting :)."
The company is using the developer preview to give beta testers a sneak peek into some new features, such as "notification channels," which will offer users the ability to group notifications. There is also Picture in Picture, which will enable you to have a video appear in a small window on top of homescreen or any application. Google is also adding "multi-display support" and improved "keyboard navigation." Your guess is as good as mine as to what these features will actually do. There's also better "background limits" which will supposedly help save battery, and wider Wi-Fi support to include things like Neighborhood Aware Networking (NAN).
No word on what "O" in Android O stands for.
The company is using the developer preview to give beta testers a sneak peek into some new features, such as "notification channels," which will offer users the ability to group notifications. There is also Picture in Picture, which will enable you to have a video appear in a small window on top of homescreen or any application. Google is also adding "multi-display support" and improved "keyboard navigation." Your guess is as good as mine as to what these features will actually do. There's also better "background limits" which will supposedly help save battery, and wider Wi-Fi support to include things like Neighborhood Aware Networking (NAN).
No word on what "O" in Android O stands for.
Oh.
O MG I'll need a magnifying glass to see all the shit they want to put on my puny phone-not-uh-kumpewter screen.
I switched away from Android a while ago, mainly because I could not control permissions individually per app. E.g., I couldn't install a news app and just deny access to my location - I could say yes to all permissions and install, or no to all permissions and skip installation. Will that be addressed?
Well .... O for Android Oreo seems fitting.
O is for Ouzo which is licorice flavored.
Oreo...
Color Management was introduced in Microsoft Windows... 95! And yet, here we are in 2017, and it is FINALLY being added to Android!? HOLYSHIT, Been seriously waiting YEARS for this. Now if only Apple could get their head out of their ass and support it in iOS too...
.... you do know that all Android builds have a candy/dessert that the letter stands for, right?
Ice Cream Sandwich, Jellybean, KitKat, Lollipop, Marshmallow, Nougat, etc.
Please tell me your comment is because you're mortally stupid.
I believe they meant which tasty treat starting with the letter O would become the codename.
N if for Nougat
O is for O.....
how about being able to cast to your TV and still have a screen on your phone to control video? or whatever?
deleting the extra space after periods so i can stay relevant, yeah.
Comment removed based on user account deletion
Google is also adding "multi-display support" and improved "keyboard navigation." Your guess is as good as mine as to what these features will actually do.
My guess is that former adds support for multiple displays and the latter improves the navigation of the keyboard.
systemd is Roko's Basilisk.
The summary doesn't ask what it means; it asks what it stands for.
systemd is Roko's Basilisk.
Comment removed based on user account deletion
The O stands for Observation
I wonder why Android can't have some bigger improvements to it. Google has a lot of developer resources, and some items added might make it a lot more developer and enterprise friendly:
A hypervisor comes to mind, so Android can have a VM for work, a VM for home, etc. This is especially useful with dual-SIM phones, or a phone using the SIM for one VM, and Google Voice for another.
A filesystem like APFS with deduplication, bit rot protection, encryption provisions on a block level, and other items.
A way to have nandroid built into the OS, so not just /data, but the entire phone, ROM, apps, and stored stuff can be dumped out as a backup. This would make life a lot easier should an OTA update cause a bricking.
The ability to scale down the OS to fit on phones 4+ years old, and work well (as in run all existing apps.) If Windows, which is an OS far more complex, can do this, it would be useful if Android could run on devices with far fewer CPUs/RAM/storage, as there is a big market for lower end Android devices, especially as the economy worsens.
The ability to do containerization.
The ability to do OTA updates as compressed diffs, so even if /system was modified, updates can still take.
Are we getting zram configured with swap device size = 4x RAM, mem_limit = 50% RAM, vm.swappiness = 100? That will give effective doubling of RAM for approximately no performance hit.
've not found the performance asymptote yet. The crude theoretical limit is exchanging 100% of working RAM for 3x the compressed space (100% compressed to an average 3:1, although 4:1 happens sometimes--typically you average 3:1). The frequency of page decompression increases as you reduce the working RAM (the part not holding compressed data). Page decompression takes approximately twice as much time as a worst-case CPU cache miss (full row-precharge, RAS, and CAS), so decompressing pages with relative infrequency is cheap, and can be effectively free.
Generally, a block of code operates multiple instructions per byte of an immediate working set, so e.g. 16KiB eats 400,000 CPU cycles decompressing and then the application spends 4,000,000 cycles operating on that area. The application will use part of its hot working set as well, so the time spent working on that page spans more cycles than just that. Depending on how fast the program works through working set, you can end up expending approximately 0% of CPU on swapping into zram; or, if the working set space is tiny and swapping is frequent, you can expend much of your time swapping in and out.
Prefetching and caching further complicates this. The Linux kernel can background-prefetch swap by reading sequential pages ahead or by taking explicit hints via madvise() such as WILLNEED (get the page ready), SEQUENTIAL (aggressive read-ahead), or RANDOM (read-ahead not useful) from the application. If the system uses 99.7% of the CPU, then there are 3mS per 1 second interval to decompress pages into a cache (without freeing from zram), and to compress pages into zram (without freeing from RAM--mark as not-dirty). That's 4.8 million cycles per 1.6GHz core--on a 4 core phone, that's plenty to compress many pages per second, and decompression is way fast. Efficient prediction can really reduce the cost of swapping into zram to a real-time 0.
As I said: that's if you have the CPU time unused. At 3mS per 1 second interval, as above, with 26 cycles per byte, a 4k page takes 106,496 cycles to decompress. With four cores loaded to 99.7%, that's 45 pages per core or 180 pages, 720k per second you can afford to swap in--no room for swapping out. If you're not running through that much cold-set data per second, zram costs power usage, but not performance. As well, the amount of data you can churn through is limited by nominal CPU usage, and the churn in practice is nowhere near the theoretical limit (effectively a MOV %eax,$addr loop with $addr+=4096 iterations), so low-CPU-usage operation would tend to inflict less power consumption.
I didn't go looking for the performance asymptote because the return between 2x and 3x RAM capacity isn't worth bothering with. With half the working set, the amount of swapping is negligible; even when you start digging deep into swap, the rate of data moving in and out of zram is low enough to not inflict a visible performance impact. The real-time impact vanishes as soon as the CPU is more-idle, so if there's a 30mS stall every 10 seconds you suddenly have time to catch up on 3mS of slowdown and break even. This is, thus, a fine place to simply settle for now, without worrying about the variability of workloads like you'd have to if you pushed to the limit based on large data analysis of common workloads.
Support my political activism on Patreon.
Ossum
https://www.youtube.com/watch?v=YaIZF8uUTtk
This didn't occur to anybody else?
The Android of O
I'm betting on Oreo for Android O
No word on what "O" in Android O stands for.
My money's on "Ovaltine", which is both in keeping with their naming scheme and a fun reminder of A Christmas Story.
It sounds like Google is seriously working on improvements for Superbooks, desktop docks, and similar arrangements where the phone takes on PC-like properties. I have been using my S7 with a keyboard/mouse and a DisplayLink adapter for a short while, and the two problems that plague it, besides poor video framerate, are the inability to operate the displays at different resolutions, and the awkward UI design/keyboard bindings that were clearly not designed for desktops. What Google is doing makes perfect sense to me.
Perhaps we are about to see a spate of laptop/desktop-like Android products, for which these changes are needed?
What Is SEO Content? A Beginner's Guide to Creating Content for SEO
Web Designer Psychology Makes Client Satisfaction
The Creative Process Behind Website Design
Avoid Common Website Mistakes
Customise Your WordPress Website