Slashdot Asks: What Are Your Favorite Android Oreo Features? (thehackernews.com)

Yesterday, Android O officially became Android Oreo and started rolling out to Pixel and Nexus devices. While there are many new features available in the new OS, we thought we'd ask you: what are your favorite Android Oreo features? The Hacker News highlights eleven of the new features "that make Android even better" in their report: 1. No More 'Install From Unknown Sources' Setting: Prior to Android Oreo, third-party app installation requires users to enable just one setting by turning on "Install from unknown sources" -- doesn't matter from where the user has downloaded an APK file, i.e. from a browser, Bluetooth, transferred from a computer via USB or downloaded using another app. Android 8.0 Oreo has completely changed the way this feature works, bringing a much smarter and safer system called "Install other apps," in which a user has to manually permit 3rd-party app installation from different sources.
2. Autofill API Framework: Android 8.0 Oreo brings a built-in secure AutoFill API that allows users-chosen password manager to store different types of sensitive data, such as passwords, credit card numbers, phone numbers, and addresses -- and works throughout the entire system.
3. Picture-in-Picture: With Android Oreo, you can view a YouTube video while reading through a report in Word or be chatting on WhatsApp on your Android device -- thanks to Picture-in-Picture (PIP) feature.
4. Google Play Protect: Play Protect helps in detecting and removing harmful applications with more than 50 billion apps scanned every day.
5. Wi-Fi Aware (Neighborhood Aware Networking -- NAN): Android Oreo has added support for a new connectivity feature called Wi-Fi Aware, also known as Neighborhood Aware Networking (NAN), which allows apps and devices to automatically find, connect to, and share data with each other directly without any internet access point or cellular data.
6. Android Instant Apps: With Android 8.0 Oreo, you can now access a range of Instant Apps without downloading them.
7. Battery-Saving Background Limits: Google has blocked apps from reacting to "implicit broadcasts" and carrying out certain tasks when they are running in the background in an effort to enhance the battery life of Android device. Besides this, Android Oreo will also limit some background services and location updates when an app is not in use.
8. AI-based Smart Text Selection: Android Oreo brings the 'Smart Text Selection' feature, which uses Google's machine learning to detect when something like physical addresses, email addresses, names or phone numbers is selected, then automatically suggests the relevant information on other apps.
9. Notification Dots (Limit notifications): Oreo introduces Notification Dots that offers you to manage each app individually with "fine-grained control," allowing you to control how many notifications you see and how they come through.
10. Find my Device: Google has introduced a new feature, called Find my Device, which is a similar feature to Apple's Find my iPhone and allows people to locate, lock and wipe their Android devices in the event when they go missing or get stolen.
11. New Emoji and Downloadable Fonts: Android Oreo introduces 60 new emoji and a redesign of the current "blob" characters. The update also offers new color support to app developers and the ability to change or animate the shape of icons in their apps.

Comments

Find My Device?

[Anonymous Coward]

My Nexus 6P running stock (rooted) 7.1.2 already has a "Find Device" app from Google which can remotely locate, ring, lock, and wipe the device. I believe it used to be called Device Manager. Why is this listed as a new feature?

Re:Come again?

[Actually, I do RTFA]

How the fuck do you run a program without downloading it? Or is this some marketing bullshit where "downloading" has a different meaning than "installing"?

Like many things, XKCD explains how (and predicts the feature/product a few years in advance.

Treble \ Updates

[SumDog]

The most important feature doesn't seem to be mentioned: Treble.

https://source.android.com/devices/architecture/treble

This could be crucial in fixing a lot of the drivers/userspace/abi development issues by creating stable interfaces for manufacture hardware (instead of each vendor patching the fuck out of the kernel with their shitty drivers and tons of binary blobs). It could bring us closer to easily being able to put ASOP right on any phone, just like installing Windows fresh on a new laptop. ..but more than likely Google and the vendors will still fuck this up somehow and we'll end up with this mess:

http://penguindreams.org/blog/android-fragmentation/

Re:Treble \ Updates

[swillden]

Problem is this will never make it into the Mainstream kernel.

Treble has nothing to do with the kernel.

(Disclosure/disclaimer: I'm a Google Android engineer. I own two hardware abstraction layers in Android, meaning I define their requirements, write the specifications, create the interfaces, write the client code in the Android system that uses them, write the reference implementations and work with vendors to validate their implementations. So.... I know this shit :-). On the other hand, I'm not part of the Treble team, don't participate in long-term OS-level planning, and what I'm giving you is my worm's-eye view of the goals. You can trust the stuff I tell you about how it works. Take my comments about long-term goals and ecosystem effects with a pound of salt.)

Android has a set of Hardware Abstraction Layer (HAL) interfaces that mediate between the Android system services and the kernel. Traditionally, this layer has been fuzzy. Google has always created and published the HAL interfaces in AOSP, and written client software that uses them, but device makers have been free to modify all of it. They add new HALs, modify the existing HALs and change the code above the HAL interface to use their changes. Android has long had the Compliance Test Suite (CTS) that validates that the app-visible behavior is consistent across devices, so that apps will run everywhere, but everything below that has been mutable.

Treble is about making the HAL interface solid and closing it off to modification by device makers. Treble introduced a new HAL communications infrastructure that uses a modified form of Binder (Android's long-used IPC mechanism) for communications between system components and HALs. It also adds a Vendor Test Suite (VTS) that device makers will have to pass to be able to call their devices "Android", and VTS runs directly against the HAL interface. This ensures that vendors can't change the hardware interfaces. They can still create their own HALs, but they cannot add to, subtract from, or modify the semantics of the methods of the standard HALs.

Treble also creates a hard separation between the /system and /vendor partitions, and sets a firm requirement that nothing in /vendor can depend on anything in /system. All of the HAL implementations live in /vendor, and all of Android lives in /system. The kernel isn't in either, of course, and stuff in /vendor can and does depend on kernel version-specific features... but /system does not and cannot directly depend on kernel features.

This means that once the Treble vision is fully realized (and it's going to be a process; this is a huge change which may take device makers a couple of years to get fully up to speed on), it will be possible to flash a standard AOSP build onto any device with an unlockable bootloader, with confidence that it will be able to use the HALs in /vendor correctly. In theory, the device maker should even be able to continue updating /vendor and the kernel even though the system is AOSP. Any custom HALs provided by the device maker will not be loaded or used by a vanilla AOSP build, of course.

What's even better is that this and some other changes to verified boot infrastructure move us toward a world where it will be feasible for device makers to turn updating of /system over to Google. Not that they'll have to, but especially for smaller players it will be hugely attractive to be able to push the burden of managing updates off on Google. They'll still be responsible for maintaining /vendor and the boot image (kernel), of course. There's still a lot more work to be done before that can actually happen (i.e. the work in Oreo isn't enough), and the carriers are going to have to figure out how they're going to handle their testing processes, but Treble makes it possible.