Android 15 Could Bring Widgets Back To the Lock Screen

After removing the feature with Android 5.0 in 2015, Google appears to be bringing back lock screen widgets in the next version of Android. “There haven’t been any indications since then that Google would ever bring this feature back,” notes Android Authority. “But after Apple introduced widgets to the iPhone lock screen in iOS 16, many speculated that it was only a matter of time.” From the report: As for how they might do that, there seem to be two different approaches that are being developed. The first one involves the creation of a new “communal” space — an area on the lock screen that might be accessed by swiping inward from the right. Although the communal space is still unfinished, I was able to activate it in the new Android 14 QPR2 Beta 3 update. Once I activated the communal space, a large gray bar appeared on the right side of the lock screen on my Pixel device. After swiping inward, a pencil icon appeared on the top left of the screen. Tapping this icon opened a widget selector that allowed me to add widgets from Google Calendar, Google Clock, and the Google App, but I wasn’t able to add widgets from most of my other apps. This is because the widget category needs to be set to KEYGUARD in order for it to appear in this selector. KEYGUARD is a category Google introduced in Android 4.2 Jelly Bean that very few apps utilize today since the lock screen hasn’t supported showing widgets in nearly a decade. After adding the widgets for Google Clock and Google Finance, I returned to the communal space by swiping inward from the right on the lock screen. The widgets were indeed shown in this space without me needing to unlock the device. However, the lock screen UI was shown on top of the widgets, making things difficult to see. Clearly, this feature is still a work in progress in the current beta. […]

While it’s possible this communal space won’t be coming to all devices, there’s another way that Google could bring widgets back to the lock screen for Android phones: leveraging At a Glance. If you aren’t familiar, Pixel phones have a widget on the home screen and lock screen called At a Glance. The interesting thing about At a Glance is that it isn’t actually a widget but rather a “custom element behaving like a widget,” according to developer Kieron Quinn. Under the hood, At a Glance is built on top of Smartspace, the API that is responsible for creating the various cards you can swipe through. Although Smartspace supports creating a variety of card types, it currently can’t handle RemoteViews, the API on which Android app widgets are built. That could change soon, though, as Google is working on including RemoteViews into the Smartspace API.

It’s unclear whether this will allow raw widgets from all apps to be included in At a Glance, since it’s also possible that Google is only implementing this so it has more freedom in building new cards. Either way, this new addition to the Smartspace API would supercharge the At a Glance widget in Android 15, and we’re excited to see what Google has in store for us.

Read more of this story at Slashdot.

Google’s New Pixel Tablet Is a $500 Slate For the Home

Google has announced the Pixel Tablet after teasing it during last year’s Google I/O conference. The Verge reports: The Pixel Tablet is designed from the ground up to be good at what people typically use tablets for: watching video or playing games in the comfort of their own home. It is not, however, making any statements about the future of computing. The looks of the Pixel Tablet are relatively generic. It has an 11-inch, 16:10, 2560 x 1600 pixel LCD display, even bezels all around, and a matte back. It comes in three colors: white, dark green, and light pink, with the dark green model featuring a black bezel. Though it looks like plastic from a distance, the Pixel Tablet has an aluminum frame with a nanotexture coating, not unlike what Google did with the Pixel 5 smartphone.

Bundled in the box with the Pixel Tablet is a magnetic speaker dock. This serves multiple purposes and is meant to prevent the dreaded “dead tablet in a drawer” syndrome: it’s a place to store the Pixel Tablet when it’s not in use; it charges the battery; and it has a louder, fuller speaker better suited for communal listening than the speakers that are built into the tablet. If you’re playing music or watching a video on the tablet when you put it on the dock, it will seamlessly transfer the audio to the dock’s speaker. Pull the tablet off the dock while something is playing, and it will instantly switch to the tablet’s speakers.

When mounted on the speaker dock, the Pixel Tablet looks an awful lot like the Nest Hub Max, a $250 smart display that Google released back in 2019. But make no mistake, the Pixel Tablet is an Android tablet and not a smart display — it runs completely different software and has different capabilities compared to the Nest Hub. That said, when the tablet is docked on the speaker, it can show a slideshow of images from your Google Photos albums just like the Nest Hub. It also has a quick access button to the Google Home app so you can control smart home devices, and it can accept voice commands from a distance for hands-free Google Assistant queries. The lock screen won’t show any personal information like notifications — for that, you’ll have to unlock the tablet to access the accounts that are set up on it. The $499 slab is available for preorder starting today, and will begin shipping on June 20th.

Read more of this story at Slashdot.

Google Play Has Created a No-Win Situation For the Creators of Icon Packs

Jules Wang from Android Police reports on the cases of two icon pack artists who had their products taken down from the Play Store for supposedly violating the platform’s Repetitive Content policy. Despite both creators’ products being reinstated, they revealed that Google’s opaque application of its rules has caused frustration and hopelessness among developers. From the report: All this heartache stems from Google Play’s Repetitive Content policy. While on its face a well-meaning effort to reduce spammy apps and keep quality up, there’s a core problem with compliance when creators find themselves forced to use apps to distribute content: “If these apps are each small in content volume, developers should consider creating a single app that aggregates all the content.”

If you’ve browsed on the Play Store, you’ll immediately know this guidance isn’t universally followed: many artists like JustNewDesigns will have multiple designs in their portfolio and each of those designs will come in multiple colorways or shapeways — whether they’re changing out an accent in a line design or are implementing some sort of adaptive element.

Not only are there so many apps, but they also look so much alike — artists, many of whom might not consider coding their strong suit, tend to use open-source templates to create the actual app. You’ll likely see them credited to Sarsa Murmu, who runs a GitHub project called CandyBar, or Jahir Fiquitiva, the maintainer of the Blueprint repository. These resources take care of the “packaging” for the assets. They include integration compatibility with various popular launchers, a license scheme to prevent those who sideloaded the app for free from having the icons applied, and all sorts of other functionality. In addition to the icon assets, the apps may also house wallpapers and links to other apps. […] What is Google’s role and what should it be? Wang writes: Artists would have much to gain from a new or revised API. Adding and adapting new icon designs to existing products would be much easier. New designs may be able to take advantage of changes to the Adaptive Icons API as Google lays them out. There would be unease as to how the business model could shift — should publishers charge by the app, through in-app purchases, or both? But as it stands, the biggest benefit with such a change is that it would presumably get Play’s “RoboCops” off their back. Of course, we can’t be sure of that with how Google’s enforcement apparatus operates, but the notion of unfairness lends credibility to those supporting the status quo unless the company is willing to come to the bargaining table.

At the end of the day, Google is certainly within its right to build regulations around apps to respond to emergent scammers and distressing content. Automation is meant to render manageable the sheer volume of content the Play platform sees published on a daily basis. But so long as icon artists sit under threat from a rulebook that can be arbitrarily thrown at them at any time, if nothing changes, we may be on a road leading to the degradation of a core Android tenet that even the most casual tech consumer associates with the platform — user customizability.

Read more of this story at Slashdot.

Jack Dorsey’s Bluesky App Is Now On Android

Bluesky, the Twitter alternative backed by Twitter co-founder and CEO Jack Dorsey, has now rolled out to Android users. TechCrunch reports: The app, which promises a future of decentralized social networking and choose-your-own algorithms, initially launched to iOS users in late February and remains in a closed beta. The exclusivity is driving demand for the newer social network to some extent, but so is having Dorsey’s name attached. Bluesky aims to give users algorithmic choice, letting them eventually choose from a marketplace of algorithms that let them control what they see on their own feed, instead of having it controlled by some central authority.

At launch, however, Bluesky remains a pared-down version of Twitter without many of the features that make the social network what it is today, including basic tools for tracking likes or bookmarks, editing tweets, quote-tweeting, DM’s, using hashtags and more. It’s also building in decentralization with its own protocol — the AT Protocol — instead of contributing to the existing work around ActivityPub, the protocol powering the open source Twitter alternative Mastodon and a range of other decentralized apps in the wider “Fediverse” — the name for these interconnected servers running open software used for web publishing. That puts Bluesky on the outside of where a lot of the current activity is taking place around decentralized social networking. You can download Bluesky on the Google Play Store here.

Read more of this story at Slashdot.

How Much To Infect Android Phones Via Google Play Store? How About $20K

If you want to sneak malware onto people’s Android devices via the official Google Play store, it may cost you about $20,000 to do so, Kaspersky suggests. The Register reports: This comes after the Russian infosec outfit studied nine dark-web markets between 2019 and 2023, and found a slew of code and services for sale to infect and hijack the phones and tablets of Google Play users. Before cybercriminals can share their malicious apps from Google’s official store, they’ll need a Play developer account, and Kaspersky says those sell for between $60 and $200 each. Once someone’s bought one of these accounts, they’ll be encouraged use something called a loader.

Uploading straight-up spyware to the Play store for people to download and install may attract Google’s attention, and cause the app and developer account to be thrown out. A loader will attempt to avoid that: it’s software a criminal can hide in their otherwise innocent legit-looking app, installed from the official store, and at some convenient point, the loader will fetch and apply an update for the app that contains malicious code that does stuff like steal data or commit fraud. That update may ask for extra permissions to access the victim’s files, and may need to be pulled from an unofficial store with the victim’s blessing; it depends on the set up. The app may refuse to work as normal until the loader is allowed to do its thing, convincing marks into opening up their devices to crooks. These tools are more pricey, ranging from $2,000 to $20,000, depending on the complexity and capabilities required.

Would-be crims who don’t want to pay thousands for a loader can pay substantially less — between $50 and $100 — for a binding service, which hides a malicious APK file in a legitimate application. However, these have lower successful install rates compared to loaders, so even in the criminal underground you get what you pay for. Some other illicit services offered for sale on these forums include virtual private servers ($300), which allow attackers to redirect traffic or control infected devices, and web injectors ($25 to $80) that look out for victims’ visiting selected websites on their infected devices and replacing those pages with malicious ones that steal login info or similar. Criminals can pay for obfuscation of their malware, and they may even get a better price if they buy a package deal. “One of the sellers offers obfuscation of 50 files for $440, while the cost of processing only one file by the same provider is about $30,” Team Kaspersky says. Additionally, to increase the number of downloads to a malicious app, thus making it more attractive to other mobile users, attackers can buy installs for 10 cents to $1 apiece. Kaspersky’s report can be found here.

Read more of this story at Slashdot.

Android 14 Set To Block Certain Outdated Apps From Being Installed

To help reduce the potential for malware, Android 14 will begin fully blocking the installation of apps that target outdated versions of Android. 9to5Google reports: For years now, the guidelines for the Google Play Store have ensured that Android developers keep their apps updated to use the latest features and safety measures of the Android platform. Just this month, the guidelines were updated, requiring newly listed Play Store apps to target Android 12 at a minimum. Up to this point, these minimum API level requirements have only applied to apps that are intended for the Google Play Store. Should a developer wish to create an app for an older version, they can do so and simply ask their users to sideload the APK file manually. Similarly, if an Android app hasn’t been updated since the guidelines changed, the Play Store will continue serving the app to those who have installed it once before.

According to a newly posted code change, Android 14 is set to make API requirements stricter, entirely blocking the installation of outdated apps. This change would block users from sideloading specific APK files and also block app stores from installing those same apps. Initially, Android 14 devices will only block apps that target especially old Android versions. Over time though, the plan is to increase the threshold to Android 6.0 (Marshmallow), with Google having a mechanism to “progressively ramp [it] up.” That said, it will likely still be up to each device maker to decide the threshold for outdated apps or whether to enable it at all. The report notes that it’ll still be possible to install an outdated version of an app “through a command shell, by using a new flag.”

Read more of this story at Slashdot.

Android 13 Is Running On 5.2% of All Devices Five Months After Launch

According to the latest official Android distribution numbers from Google, Android 13 is running on 5.2% of all devices less than six months after launch. 9to5Google reports: According to Android Studio, devices running Android 13 now account for 5.2% of all devices. Meanwhile Android 12 and 12L now account for 18.9% of the total, a significant increase from August’s 13.5% figure. Notably, while Google’s chart does include details about Android 13, it doesn’t make a distinction between Android 12 and 12L. Looking at the older versions, we see that usage of Android Oreo has finally dropped below 10%, with similar drops in percentage down the line. Android Jelly Bean, which previously weighed in at 0.3%, is no longer listed, while KitKat has dropped from 0.9% to 0.7%. Android 13’s 5.2% distribution number “is better than it sounds,” writes Ryan Whitwam via ExtremeTech: These numbers show an accelerating pickup for Google’s new platform versions. If you look back at stats from the era of Android KitKat and Lollipop, the latest version would only have a fraction of this usage share after half a year. That’s because the only phones running the new software would be Google’s Nexus phones, plus maybe one or two new devices from OEMs that worked with Google to deploy the latest software as a marketing gimmick.

The improvements are thanks largely to structural changes in how Android is developed and deployed. For example, Project Treble was launched in 2017 to re-architect the platform, separating the OS framework from the low-level vendor code. This made it easier to update devices without waiting on vendors to provide updated drivers. We saw evidence of improvement that very year, and it’s gotten better ever since.

Read more of this story at Slashdot.

Google Reports Decline In Android Memory Safety Vulnerabilities As Rust Usage Grows

Last year, Google announced Android Open Source Project (AOSP) support for Rust, and today the company provided an update, while highlighting the decline in memory safety vulnerabilities. 9to5Google reports: Google says the “number of memory safety vulnerabilities have dropped considerably over the past few years/releases.”; Specifically, the number of annual memory safety vulnerabilities fell from 223 to 85 between 2019 and 2022. They are now 35% of Android’s total vulnerabilities versus 76% four years ago. In fact, “2022 is the first year where memory safety vulnerabilities do not represent a majority of Android’s vulnerabilities.”

That count is for “vulnerabilities reported in the Android security bulletin, which includes critical/high severity vulnerabilities reported through our vulnerability rewards program (VRP) and vulnerabilities reported internally.” During that period, the amount of new memory-unsafe code entering Android has decreased: “Android 13 is the first Android release where a majority of new code added to the release is in a memory safe language. ”

Rust makes up 21% of all new native code in Android 13, including the Ultra-wideband (UWB) stack, DNS-over-HTTP3, Keystore2, Android’s Virtualization framework (AVF), and “various other components and their open source dependencies.” Google considers it significant that there have been “zero memory safety vulnerabilities discovered in Android’s Rust code” so far across Android 12 and 13. Google’s blog post today also talks about non-memory-safety vulnerabilities, and its future plans: “… We’re implementing userspace HALs in Rust. We’re adding support for Rust in Trusted Applications. We’ve migrated VM firmware in the Android Virtualization Framework to Rust. With support for Rust landing in Linux 6.1 we’re excited to bring memory-safety to the kernel, starting with kernel drivers.

Read more of this story at Slashdot.