Logitech produces a lot of keyboards and mice, but one of the company’s best budget keyboards is the K380. It’s a simple Bluetooth keyboard, but the rounded keys and support for multiple connections makes the K380 stand out from most other competing keyboards. Now you can get a refurbished model from Woot for $20.99 — $9 less than the current price for a new model on Amazon.
This is a compact keyboard with no number pad (sorry, Excel users), capable of storing Bluetooth connections with up to three devices. You can switch between connections with the three yellow keys at the top. The Logitech K380 works with anything that supports Bluetooth keyboards, including most Windows PCs, Macs, Android devices, iPads, and more.
The main catch here is that Woot is only selling the dark grey model, and not any of the fun other colors Logitech has produced. The listing is also labelled as refurbished, which Woot defines as “buyers’ remorse returns and products whose defects have been repaired.” It’s not clear if the keyboard ships in its original packaging.
Android and Chrome OS are closely connected. That makes sense as both operating systems are developed and maintained by Google. The best part about this connection is the convenience of using an Android phone with your Chromebook. If you use an Android phone and Chromebook together, there are a number of useful features that improve your daily workflow. In addition to this tight integration with your phone, you can also use Android apps directly on most newer Chromebooks.
In this tutorial we’ll cover how to improve your Chrome OS experience by pairing to your Android phone. We’ll cover Phone Hub, Smart Lock, and other useful features. Finally, we’ll suggest some Android apps that are optimized for Chromebooks compatible with the Play Store.
Connect your Android phone to your Chromebook
You can easily connect your Android to your Chromebook during initial setup. But if you still haven’t done that, it’s a quick process:
At the bottom right corner, select the time.
Select Settings .
Under Connected devices, next to Android phone, select Set up.
Enter your password and follow the steps. Once completed, you’ll get a confirmation on your phone.
On your Chromebook, click Enabled, and select which features you want to turn on (see below).
Enable Smart Lock and Instant Tethering
From here you can toggle on a number of nice features. For instance, Smart Lock unlocks your Chromebook using your phone. If the phone is detected nearby and is unlocked, Chrome OS automatically skips the account login screen, so you don’t need to enter your password to get in.
There’s also Instant Tethering. With this feature, your Chromebook will give you the option of getting online using your phone as a hotspot (this will count against your data plan of course) if it can’t detect a standard wifi connection. Everything is handled for you, including activating your phone’s hotspot feature — all you need to do is click Connect in Chrome OS.
Access Messages from your phone on your Chromebook
Next up is Messages. Click Setup to turn this on, and your Chromebook will open the Google Messages web interface and ask you to sign in using a QR code. In the Messages app on your phone, you’ll need to tap the three dots in the top right-hand corner on the main interface, then Device Pairing to scan the QR code.
Keep in mind if you don’t use a Pixel phone, you’ll likely need to download Google’s Messages app and set it as the default. Other messaging apps from OEMs like Samsung are not supported for integration with your Chromebook.
Enable Phone Hub for more integration
Released earlier this year, Phone Hub is a relatively new option for pairing your Android phone and Chromebook. Once it’s enabled, you get the Phone Hub toggle switch in Chrome OS Settings, plus toggle switches for Notifications (which shows your phone notifications on your Chromebook) and Recent Chrome tabs (which lets you access Chrome tabs you’ve recently opened on Android through Chrome OS). Google says you’ll soon be able to access shared photos via Phone Hub, but this feature hasn’t rolled out to everyone just yet.
To access all of these sweet hub features, you’ll see a phone icon down on the right-hand side of the taskbar shelf. Click this to get access to the hub (and to enable it in the first place). You’ll also need to enable access to notifications for Google Play Services on your phone, but you’ll be guided through the process and it’s quite fast. Notifications from your phone look just like any Chrome OS alert, but your phone’s name will be appended to the top.
If you bring up the Phone Hub from the Chrome OS shelf, you can see (and open) browser tabs that have recently been accessed in Chrome for Android. There are also toggle switches for turning on your phone’s hotspot feature, muting your phone, and locating your phone (which will force it to ring even if your phone is on silent mode).
At the top of the dialog box, you can see the signal strength and battery life for your Android device. Clicking on the cog icon will take you to the same device connection settings we saw earlier.
Use familiar Android apps on your Chromebook
After connecting your Android phone to your Chromebook, you might want to actually use some Android apps on your Chromebook. Most modern Chromebooks support the Google Play Store, allowing you to download and use your favorite Android apps. This is an excellent feature if you use an Android phone daily.
You probably already have a list of apps you enjoy for productivity, social media, and streaming content. Now you can bring those apps to your Chromebook using a few simple steps:
How to download Android apps on your Chromebook:
Turn your Chromebook on and log in.
Open the app drawer. Either tap on the Launcher icon, or swipe up from the bottom.
Find the Google Play Storeapp and open it.
Search or browse for your app of choice. If you’re looking for options, see our list of best Android apps coming up in this article.
Click on Install.
Wait for the app to install, and it’ll appear in your app drawer shortly after.
Below are a few examples of apps that are optimized for Chrome OS. For a full list of recommended Android apps, check out our Android apps guide for Chrome OS.
While there are several 3rd-party Twitter apps on Android, they’re mostly all hampered by Twitter’s API restrictions. Because of this, the official Twitter app is still the way to go for Android or Chrome OS. Follow your favorite conversations and participate in polls or group DMs. All of the latest Twitter features come to your Chromebook with this Android app.
Pretty much everyone uses Netflix these days. If you have a Chromebook, the chances are you want to stream some of your favorite shows on it. Check out award-winning series, movies, documentaries, and stand-up specials. With the mobile app, you can get Netflix while you travel, commute, or just take a break with your new Chromebook.
Microsoft Office is the most popular productivity suite, offering Android apps for Word, Excel, Powerpoint, and so on. Overall, the Android version of each Office app runs quite well on Chrome OS. Basic editing features are free in all of the apps, but on devices over 10 inches in size — which accounts for most Chromebooks — you’ll need a Microsoft 365 subscription to enable all features. Unfortunately, the Android version of OneDrive doesn’t work properly on Chromebooks. You can now download Word, Excel, and Powerpoint in a single app, making organizing your app drawer a bit easier.
As you can see, using an Android phone with your Chromebook can enable some pretty cool features. You can improve your workflow, or just get social media notifications on your computer. You can also run Android apps on your Chromebook, opening up all the possibilities of the Google Play Store.
If you’re still searching for the perfect Chromebook, check out some of the best Acer Chromebooks you can buy today. Let us know in the comments how you integrate your Chrome OS device with your Android phone.
Microsoft has announced the Windows Server Insider Preview builds are currently on hold. That means that there won’t be anything new for a little while while the team “gears up for the next development cycle”. Not only that, but the current Windows Server Insider Preview, build 20344, has been pulled from the download page.
The next development cycle, of course, is Windows 11. Here’s how this goes. Microsoft is still working on Windows Server 2022. Just because the preview builds are gone doesn’t mean that the thing they were working on is gone. There’s also still going to be a Semi-Annual Channel release later on this year. But now that Windows Insiders are testing out a client version of Windows 11, some of that is going to translate into the Server end of things.
We’ve seen it before, where Windows Server 2016 was built around Windows 10, and Windows Server 2012 was built around Windows 8. They even share a lot of the same UX. While Microsoft hasn’t confirmed or denied this, it’s entirely possible that Windows Server 2022 will have the Windows 11 UX.
Another thing that’s possible, even likely, is that the Semi-Annual Channel is going to go away. Windows 11 client is going to be updated annually, instead of biannually like Windows 10 is. The reason is because it allows for more stable updates for businesses. Doing two updates a year simply didn’t work. Since client is making this change, it would be surprising if Server didn’t do the same.
You can expect to hear more about Windows Server Insider Previews soon, but Microsoft has a lot to talk about first. It has to unveil the new version, talk about how it’s going to do updates moving forward, and so on. After it does all of that, then you can expect to see new preview builds.
Once they are available, you’ll be able to download them here. As of right now, the dropdown menu only has one item that says, “Preview builds are temporarily on hold”.
Last November, Google announced that developers will be required to publish new apps on the Play Store using the Android App Bundle (AAB) format instead of an APK. Just the other day, Google reminded developers of this upcoming requirement, setting off a firestorm of controversy from users who believe that Google is killing APKs, eliminating sideloading, hindering third-party app stores, and whatnot.
It’s true that Android App Bundles are a pretty big departure from the classic APK format you might be used to, both as a user and as a developer. While there are quite a few benefits to using App Bundles, there’s one key aspect to making them that has some developers and security experts rightly concerned.
In this article, we’ll cover the criticisms we’ve seen of the switch to Android App Bundles as well as some proposed solutions, and we’ll also talk about Google’s proposed solution to these problems.
Background
Before that happens though, we need to talk a bit about how app distribution works on Android in general. If you already know how app signing and App Bundles work, you can skip this part.
APKs
For the most part, apps on Android are distributed inside of APK files. An APK contains all of an app’s code and resources, along with some security features like a signing manifest. When an APK is installed, it’s basically just copied to a specific folder and added to an internal database of installed apps.
The contents of an APK file can be explored just like archive file formats like .zip.
Signatures
During installation, that app’s signature is also verified to make sure it’s valid. If the app is already installed, Android checks the new app’s signature against the one that’s already installed. If the signature isn’t valid or doesn’t match, Android will refuse to install the app.
That signature checking is an important part of security in Android. It makes sure the app you’re installing is valid and at least from the same source as the one you already had installed. For example, if you install, say, my Lockscreen Widgets app from the Play Store, you can be reasonably sure that I’m the one who signed it and that it’s authentic. If you then try to install an update to Lockscreen Widgets from some shady third-party site and it fails, you’ll know that someone tampered with that APK, possibly to add malware.
The key used to sign an app is (ideally) never publicly released. This is known as the private key. The private key is then used to generate the key shown in the app’s signature, known as the public key. This is what Android and app stores use to verify an app’s validity. I won’t get into how exactly you can generate a public key without exposing the private key, since it involves a lot of encryption math. If you want more details, check out Google’s documentation on signing APKs or do some research on one-way math functions.
Signing an app when you manage your own app signing key. Source: Google.
Another feature of app signatures is the ability to restrict permissions only to apps with matching signatures. Android does this internally for a lot of functions, where only apps signed with the same key as the framework can access certain features.
App Bundles
So now that we’ve given a quick overview of APKs and signatures, let’s talk about App Bundles. This is where APK resources come in. Resources are things like layouts, images, audio, etc. Basically, they’re anything that isn’t code. To better support different display configurations and different languages, developers can make multiple versions of the same resource that are used depending on the device and language.
But in an APK, all of those resources exist, no matter which you use. And they take up space. Depending on the complexity of your app, there could be a lot of unused resources for a lot of devices. This is what App Bundles are made to solve. Developers can generate an App Bundle just like an APK, and that App Bundle can then be uploaded to the Play Store, just like an APK can.
The contents of a sample Android App Bundle showing one base module, two dynamic feature modules, and two asset packs. Source: Google.
Google then uses that App Bundle to generate a whole bunch of different APKs for different device configurations. Each App Bundle only contains the resources needed for that configuration. When a user goes to download that app, they’re served the generated APK that matches their configuration. This helps to reduce both app download and install sizes, saving bandwidth and storage space.
A graphic that shows how dynamic delivery can result in fewer resources being installed on a device. Source: Google.
Of course, installing an APK specific to your device means it’s harder for you to just copy it to another device and install it without issue. Depending on your perspective, this can be a good or a bad thing. On the one hand, it makes piracy more difficult, since users don’t have the whole app anymore. On the other hand, it makes legitimately archiving apps more difficult, for the same reason.
App Signing
Since Android App Bundles aren’t APKs, you can’t just open an AAB file and install it directly onto a device. When you upload one to the Play Store, Google uses the bundle to generate different (unsigned) APK files. Those APKs have to then be signed before they can be installed.
Instead of asking the developer to sign and reupload those generated APKs, Google instead manages the signing itself. The Play Store either uses a new key it creates or asks the developer for the key they use to sign APKs. With either option, Google handles the public signing for the developer and provides an upload key. Google uses the upload key for internal verification and makes sure the App Bundle (or APK in some cases) the developer is uploading is the right one.
Signing an app with Play App Signing. Source: Google
If an upload key is compromised or lost, developers can request a new one, and the signing key used to distribute the app remains unchanged.
There’s a lot more to App Signing, but this is what’s relevant to this article. If you want, you can read more about App Bundles and App Signing on this Medium article by Wojtek Kaliciński.
Criticism
In theory and in practice, App Bundles are pretty great. They reduce data usage and install size, all without the user having to do anything. But because of how it’s implemented, some developers and security researchers in the past few months have raised concerns. Before I sum up these concerns, I want to take a moment to say that most of what’s written below is directly based on a series of articles by developer Mark Murphy of CommonsWare. You should absolutely check his articles out, since they provide more details and criticisms from the perspective of a developer.
Security
In the classic distribution model, a developer keeps the key they use to sign an APK private. It’s never shared to the public and only authorized people should have access to it. This ensures that only those people can generate a valid APK.
But if you use App Bundles on the Play Store, Google is the one managing the key that signs the APKs users receive. The default behavior for new apps uploaded to Google Play starting August 2021 is for Google to create its own distribution key which it keeps private from the developer.
Recap of what’s changing for Google Play developers starting August 2021. Source: Google
Developers submitting new apps will have Google manage their private key for them by default, though developers submitting updates to existing apps can continue using APKs while generating a new key for Google to use for new users. Existing apps aren’t required to switch from APK distribution to Android App Bundles, though that option is available to them should they choose. After some pushback, Google will even make it possible to upload your own private key for Google to sign with, for both new and existing apps. None of these situations are ideal, as no matter what, Google will have access to your private key if you want to use Android App Bundles (and developers have no choice in the matter if they want to submit a new app after August 2021!)
While we’re confident that Google takes security very seriously, there’s no company on Earth that’s immune from data breaches. If the key Google uses to sign your app for distribution is in one of those breaches, then anyone can sign a version of your app and make it look like it was signed by you. And some developers and security experts aren’t happy about this possibility. It’s a very, very slim possibility, yes, but the fact it’s a possibility at all scares some in the infosec community.
“Having developers sign Android APKs means anyone can verify APKs from Google Play, blind trust is not required. It is an elegant design that provides verifiable security. App Bundles turn that on its head, and seem structured to promote vendor lock-in. There are many alternate technical approaches that would provide small APKs still signed by developers, but these would not preference Play. For example, all of the APK variants could be generated and signed by the developer, then uploaded to any app store. ”
There are certainly arguments to be made about whether it’s better to leave the secure storage of private keys in the hands of Google or individual developers. But those developers (probably) aren’t usually using a central repository for their keys. By forcing developers to use Play App Signing, a malicious attacker only needs to breach Google’s security once to retrieve thousands or millions of keys.
For what it’s worth, here’s what Google says about how it protects your signing key on its infrastructure:
“When you use Play App Signing, your keys are stored on the same infrastructure that Google uses to store its own keys.
Key access is governed by strict ACLs and tamper-evident audit trails for all operations.
All artifacts generated and signed with the developer’s key are made available to you in the Google Play Console for inspection/attestation.
Furthermore, to prevent key loss, we make very frequent backups of our primary storage. These backups are strongly encrypted and we regularly test restoring from these backups.
As great as that all sounds, loss and theft are still possible. And audit trails only help prevent future attacks; they won’t get breached keys back.
Potential for Unauthorized Modifications
One big issue with the way Google has set up App Bundles is the potential for unauthorized modifications to be added to an app. The process of extracting APKs from an App Bundle inherently involves modifications, since Google has to manually build each APK. While Google has promised that it does not and will not inject or modify code, the problem with the App Bundle process is that it has the power to do so.
Here are a couple examples of what a company in Google’s position has the power to do:
Say there’s a secure messaging app that people use to communicate without the risk of government surveillance. This could be an incredibly useful tool for people protesting an authoritarian government, or even people who just want to maintain their privacy. That government, wanting the ability to see what app users are saying, could try to coerce Google into adding a surveillance backdoor into the app’s code.
This example is a bit more innocuous, but it’s also something that concerns some people. Say there’s an app that gets millions of downloads a day, but it doesn’t have any ads or analytics in it. That’s a huge data source with no way to access that data. Google, being an advertising company, might want to access that data.
In the classic APK model of app distribution, Google can’t modify the apps without changing the signature. If Google changes the signature, especially on a popular app, people are going to notice because the update won’t install. But with App Bundles and App Signing, Google could silently inject its own code into apps before distributing them. The signature wouldn’t change because Google would own the signing key.
In the classic APK distribution scheme, an updated APK file must be signed with the same key used to sign the original APK. This key is ideally held only by the individual developer. Source: Zachary Wander.
To be clear, these examples are incredibly unlikely to happen. Google tends to simply pull out of troublesome markets altogether, rather than adapt. But even though it’s unlikely, it’s still possible. Just because a company promises something won’t happen, it doesn’t guarantee it.
Code Transparency
Google, hearing these concerns, this week introduced a new feature called Code Transparency for App Bundles. Code Transparency allows a developer to essentially create a second signature that’s shipped with the app to users. This extra signature should be created from a separate private key that only the developer has access to. However, there are some limitations to this method.
How code transparency for Android App Bundles works. Source: Google
Code Transparency only covers code. That might seem obvious given the name, but it also means it doesn’t let users verify resources, the manifest, or anything else that isn’t a DEX file or a native library. While malicious modifications to non-code files usually have much less impact, it’s still a hole in the security of the app.
Another issue with Code Transparency is that there’s no inherent verification. For one, it’s an optional feature, so developers have to remember to include it for every new APK they upload. At the moment, it has to be done from the command line and with a version of bundletool that doesn’t come with Android Studio. Even when a developer includes it, Android doesn’t have any sort of verification built in to check that the Code Transparency manifest matches the code in the app.
It’s up to an end user to check for themselves by comparing the manifest against a public key the developer can provide, or by sending the APK to the developer for verification.
While Code Transparency allows for confirmation that no code in an app is modified, it doesn’t include any sort of verification for other parts of an app. There’s also no inherent trust in the process. You could argue that if you don’t trust Google, you’re probably up to the task of verifying independently, but why should you have to?
There are other issues with the Code Transparency feature, as pointed out by Mark Murphy from CommonsWare. I recommend reading his article for a more in-depth analysis of the feature.
Developer Convenience and Choice
A third (and final for this article) reason some developers take issue with App Bundles is reduced convenience and choice.
If a developer makes a new app on the Play Store after Google begins requiring App Bundles and they choose the default option of letting Google managing the signing key, they won’t ever have access to that signing key. If that same developer then wants to distribute that app on another app store, they’ll have to use their own key, which won’t match Google’s.
That means that users will have to either install and update from Google Play or from third-party sources. If they want to change the source, they have to completely uninstall the app, potentially losing data, and reinstall. APK aggregators like APKMirror will then also have to deal with multiple official signatures for the same app. (Technically, they already have to do this because App Signing lets you create a new, more secure key, for new users, but it’ll be worse for them and other sites when everyone has to do it.)
Google’s response to this issue is to use the App Bundle explorer or Artifact explorer in the Play Console to download the resulting APKs from the uploaded bundle. Similarly to Code Transparency, this isn’t a complete solution. The APKs downloaded from the Play Console will be split for different device profiles. While the Play Console does support uploading multiple APKs for one version of one app, many other distribution channels don’t.
Thus, a lot of the benefits of using App Bundles go away when developers are managing multiple stores, making distribution more difficult. With news that Windows 11 is gaining Android app support thanks to the Amazon Appstore, some believe that the App Bundles requirement will disincentivize developers from distributing on Amazon. Of course, Google’s primary concern is with its own app store, but that’s exactly what landed them in hot water with competitors leading them to make small, conciliatory changes to how third-party app stores work on Android.
Relevant: Epic’s direct distribution of Fortnite on Android is via APK. And Microsoft’s new Windows 11 support for Android apps is based on APKs.https://t.co/2stinObIsf
A couple related issues to multiple stores are app interconnectivity and rapid-fire testing.
Let’s start off with app interconnectivity. Have you ever downloaded an app that locks features behind a paywall? Almost definitely. Some developers put the features behind an in-app purchase, but others may choose to make a separate, paid, app. When that add-on app gets installed, the main app’s features are unlocked.
But what prevents someone from just installing the add-on from a pirate source? Well, there are a lot of options for developers, but at least one involves using signature-protected permissions. Say the main app declares a signature-protected permission. The add-on app then declares that it wants to use that permission. Ideally, the add-on app will also have some sort of license verification functionality in it, that connects to the internet to make sure the user is legitimate.
If both apps have the same signature, Android will grant the permission to the add-on app and piracy protection checks will pass. If the add-on app doesn’t have the right signature, the permission won’t be granted, and verification will fail.
With the classic APK distribution model, a user can get either app from any legitimate source and be done with it. With current default App Bundle model, the signatures on the main and add-on apps won’t match. Google’s going to make a unique key for each app. The developer could always do away with the signature-protected permission and use direct signature hash verification, but that’s a lot less secure.
And then there’s rapid-fire testing. Users email developers all the time about issues in their apps. Sometimes those issues are simple fixes: reproduce the issue, find the problem, fix it, and upload a new version. But sometimes they aren’t. Sometimes developers can’t reproduce an issue. They can fix what they think is the problem, but then the user has to test it. Now assume that user installed the app through Google Play.
With the APK model, a developer can change some code, build and sign a new APK, and send it off to the user for testing. Since the signature of the test APK matches the one the user has installed, it’s a simple process to update, test, and report back. With App Bundles, this falls apart. Since Google signs the APK the user originally installed, it won’t match the signature of the APK the developer sends. If this app is published after the App Bundles deadline, the developer won’t even have access to the key Google uses. In order to test, the user would have to uninstall the current app before installing the test version.
There are a bunch of problems here. First, there’s inconvenience, both on the developer and user side. Having to uninstall the app just to test a fix isn’t fun. And what if the problem goes away? Was it the changes the developer made, or was it because the user effectively cleared the app’s data? The Play Store does have Internal Testing, which is supposed to let developers do rapid-fire builds and distribution, but it requires the user to uninstall the release version first. It doesn’t really fix anything.
In case this all sounds like a bunch of hypothetical nonsense, here’s a very real example of a developer who will have these problems if they let Google generate a private key for them: João Dias. He’s the developer of Tasker, along with a whole bunch of plugin apps, including the AutoApps suite. With the new App Bundles requirement, João’s development cycle may get a lot trickier, at least for new apps. Sending testing versions directly will be less convenient. Verifying licenses will be less effective.
João Dias maintains a lot of apps that all rely on a shared license. If there are two signing keys involved, things could get really complicated for him.
This may sound like a bit of an edge-case, but it’s not like João is some small developer, and it’s likely he’s not alone. There are many apps on the Play Store that rely on signature verification to detect illegitimate users.
Of course, with the new option for developers to upload their own signing keys to Google, these issues are at least somewhat alleviated. But developers have to opt-in to enable the option for each app. If they don’t, interconnects will fail and rapid-fire support will require uploading a Bundle to Google and waiting for APKs to be generated, before sending the correct one to the user. Plus, it still means they have to share their private key, which brings us back to the concerns we discussed earlier.
Solutions
This is an old issue given the App Bundle requirements were publicized months ago, so there have been quite a few solutions proposed in the interim.
One solution is to avoid the need for Play App Signing. Instead of generating an App Bundle that Google then processes into APKs and signs, that processing could be done by Android Studio. Then, developers can just upload a ZIP full of locally-signed APKs for each configuration that Google would have generated.
With that solution, Google wouldn’t need access to developers’ keys at all. The process would be very similar to the classic APK distribution model, but would involve multiple, smaller, APKs instead of just one.
Signing your app in Android Studio with your own upload key. Source: Google
Another solution is to just not require the use of App Bundles and continue to allow developers to upload locally-signed APKs. While App Bundles may be a better experience for the user in many cases, some apps don’t actually benefit from being split up per-configuration, with minimal size reduction.
If Google implemented both of these solutions, then a developer who wants to use App Bundles won’t have to hand over signing to Google, and a developer whose app won’t benefit much from the format won’t have to use it at all.
Google’s Responses
Self-Signing
When they were first asked about allowing developers to handle the signing for App Bundles, Google’s response was very noncommittal:
“So, I talked briefly about the requirement next year for new apps to use app bundles, and one thing that comes with that is that by extension we will require Play App Signing. So developers will need to either generate the App Signing key on Play or upload their own key to Play… because that’s a prerequisite for app bundles. We’ve heard from developers that some of them just don’t want to do it. They don’t want to have keys managed by Play. And currently that’s not possible if you want to use app bundles.
But, we’ve heard that feedback, and… I can’t talk about anything right now, we don’t have anything to announce, but we are looking into how we could alleviate some of these concerns. It doesn’t necessarily have to be allowing to keep your own key while uploading bundles. We’re looking into different options. We just don’t have a solution to announce right now. But, we still have around a year until the requirement, so I’m really hopeful that we’ll have an answer for developers for this.”
That was in late November last year, and nothing seems to have happened. With only a few months left before the App Bundles requirement goes into effect, there still isn’t a way for developers to handle signing their own apps. While Google has now made it possible to upload your own key for both new and existing apps, this still takes the signing part out of the hands of the developer.
Code Changes
While Google has specifically promised that the Play Store isn’t going to modify app code, a promise isn’t a guarantee. With App Bundles and App Signing, there’s no technical limitation that we know of preventing Google from modifying uploaded apps before distribution.
Google has introduced Code Transparency as an optional feature, and while this helps somewhat, it has its fair share of problems, as we discussed earlier.
Self-Made Bundles
When Google was asked about allowing developers to make their own app “bundles” (ZIPs containing split APKs), the response was basically “we’re not going to do that”:
“Probably not as it’s described in the question, as this would make the publishing process even more difficult for developers, and we actually want to make it simpler and safer. However, again, we’ve heard this feedback, and we will be looking into options how to make this possible, however probably not in the way that was described here.”
Interestingly, Google’s justification seems to be that it would make publishing more complicated. However, Google could still make the process automated as part of the APK generation dialog in Android Studio. Furthermore, if the app in question is being distributed on multiple stores, it would actually make the publishing process simpler, since developers wouldn’t have to manage multiple signing keys and complaints from users.
And with the introduction of Code Transparency, it seems that complication isn’t exactly an issue after all. Code Transparency, for now at least, requires the developer to use a command-line tool and for users to explicitly verify the validity of the app they’re served. This is more complicated than a process to self-make bundles, and it’s unclear why this is the solution Google prefers.
Going Forward
App Bundles will be the required distribution format for new apps submitted to Google Play starting August 1st. While Google has at least somewhat addressed most of the issues raised by developers and security experts, the responses leave a lot to be desired. There are many obvious benefits to App Bundles as the next-generation distribution format, but there will always be lingering concerns with giving partial or total control of app signing to Google.
Google’s responses and efforts are certainly appreciated, but some, like Mark Murphy, feel they haven’t gone far enough. With solutions like self-made bundles not being implemented and the deadline for Android App Bundles being required fast approaching, it doesn’t look like developers on Google Play will be able to retain full control of their apps for much longer.
We’ll be talking about the implications of the Android App Bundle requirement in a Twitter Space later this afternoon, so join us!
Join XDA at 5PM ET on July 1st for a discussion about what’s happening to APKs, sideloading, Android App Bundles, and more!
Finding a good laptop in the sea of options out there today can sometimes prove to be a bit complicated. It’s even more challenging when you’re trying to spend as little money as possible. HP makes some really great laptops, but when the budget is tight, it can be hard to find one you can actually afford. We’ve already rounded up some of the best laptops you can buy for under $600, and HP makes an appearance a couple of times. But if you’re absolutely keen on the brand, these are the best HP laptops you can get on a budget.
For this list, we’re mostly trying to stick to a budget of around $600, but we made one notable exception, which we’ll get to later. At this price point, you won’t find anything that blows you away, but there are a few options that nail the basics and offer a great overall experience. We’ve included laptops of different sizes, operating systems, and form factors. This should help you find something that fits your needs.
Already making an appearance on our budget laptop list, the HP Pavilion x360 14 is a fantastic option on a budget. Starting with an 11th-generation Intel Core i3 and 8GB of dual-channel memory, it’s already a great option for your everyday tasks. If you can stretch your budget, you can upgrade to an Intel Core i5 with Iris Xe Graphics, double the RAM, with a couple more upgrades available. It also comes with a good supply of ports, including USB Type-C with DisplayPort and Power Delivery, HDMI 2.0, and more.
The one you might want the most is actually the display. Out of the box, it comes with a 14-inch touchscreen at 1366 x 768 resolution. This is still quite common among cheaper laptops, but the upgrade to Full HD can make a world of difference. Everything will look sharper and you’ll be able to see a bit more content on the screen. Regardless, it’s a fantastic entry-level convertible for its price.
We’ve quickly arrived at our exception to the $600 price point, but there’s a good reason for it. The HP Pavilion Gaming is an exceptional machine for its $699.99 asking price. Packing an AMD Ryzen 5 5600H, it has six CPU cores and 12 threads, making it a very fast laptop right out of the gate. Couple that with the Nvidia GeForce GTX 1650, and you’ll be able to use this to play most modern games at decent settings. Sure, you won’t be using ray-tracing, and the most demanding games may require you to lower some settings, but almost everything should at least be playable.
The base configuration only includes a 256GB SSD, but if you can spare an extra $70, you can double that to 512GB so you can store more games. This can be essential with some titles taking almost 200GB by themselves (we’re looking at you, Call of Duty: Warzone). You can also upgrade to a 144Hz display for $20, so you can stay under $800 and still have a great gaming experience. It’s cheaper than most laptops on our budget gaming laptops list, but you may want to check that out if you have a bit more money to spend.
If you’re looking for a classy-looking 15-inch laptop that still gets the job done, the new HP Pavilion 15 is a pretty great choice. It’s packing AMD’s latest Ryzen processors, starting at a Ryzen 3 5300U. That’s still a quad-core, eight-thread CPU clocked at 2.6GHz, and it has six GPU cares to help with graphics tasks. You’re not going to be running intensive games on it, but older 2D titles are manageable, and day-to-day tasks won’t be a problem for this CPU. You also get 8GB of dual-channel memory as the base configuration, which is a great start.
Once again, one of the upgrades we’d recommend here is going for the Full HD display, instead of the 1366×768 panel in the base configuration. That will set you back $40, but if you can make it fit your budget, it’s a major step up. There are actually plenty of upgrades you can make here to improve your experience, including the CPU, RAM, and storage. Even at the base level though, you’re getting a solid experience here.
Chromebooks are great education machines, and they’re well-known for being affordable. However, the lowest-priced Chromebooks probably won’t give you the best experience. If you want something a little more capable with a premium touch, the HP Chromebook x360 14 is one of the best you can find. It comes with an Intel Core i3-1125G4, which is a solid CPU with four cores and eight threads. That also means it includes things like Wi-Fi 6 and Bluetooth 5, so it’s a future-proofed machine. What’s more, it has 8GB of RAM and 128GB of SSD storage, which is more than enough for a Chromebook. There aren’t a lot of upgrade options, but you’re getting a solid build from the get-go.
Another highlight of this one is the Full HD touchscreen in the base configuration. Most Windows laptops at this price offer lower-resolution panels, so this is already great if you’re just looking to browse the web or enjoy some media content. On top of that, the display is protected by Gorilla Glass 5, another rare sight on laptops at this price. This should make it a durable PC for the children taking it to school and tossing it in a backpack. Oh, and it even has a fingerprint reader to make logging in easier.
The HP Chromebook x360 14 is one of the best Chromebooks you can get, featuring an 11th-gen Intel Core i3, a fingerprint reader, and high-quality display.
Aside from winning the award for most generic laptop name, the HP Laptop 17 is a great option if you enjoy bigger displays. It’s packing Intel’s 11th-generation Core processors, and while it starts with a Core i3, you can go as high as the Core i7 if your budget allows for it. You can even pair it with GeForce MX450 graphics if you want to be able to do some light gaming. You get 8GB of 3200MHz dual-channel memory in the base configuration, and a 1TB HDD, which is this laptop’s Achilles heel. If you can spare an extra $70, the 256GB SSD will greatly improve your experience, even if it misses out on some capacity.
The 17-inch panel starts at 1600×900 resolution, but you can upgrade to Full HD for an extra $60. Either way, the base resolution is higher than on similar 15-inch laptops, which helps accommodate the larger screen size. There’s also a touch option, but it’s not available with the Full HD panel, which is a shame. Regardless, this is a great laptop with a lot of upgrade options that let you fine-tune it to your taste and budget.
Finding a good business laptop in this price range is difficult, but the HP 250 G8 is a solid entry-level choice. What contributes to the higher price tag is that business laptops like this come with Windows 10 Pro instead of the Home edition. That means you get access to features like Remote Desktop, Hyper-V, BitLocker, and Windows Defender Device Guard. These are features meant for professionals, and if you need them, you have to be willing to make some trade-offs.
In terms of specs, you get an Intel Core i3-1005G1, which is no longer Intel’s newest, but it still offers two cores and four threads, with boost speeds of up to 3.4GHz. You get 8GB of single-channel RAM and a 256GB SSD, along with a healthy supply of ports including RJ45 Ethernet. The display is 15.6 inches and it comes in a 1366×768 resolution.
The HP 250 G8 Notebook covers most of the business basics and comes with Windows 10 Pro, getting you access to professional features like Remote Desktop.
These are what we consider to be the best HP laptops you can get on a budget. There’s quite a bit of variety on this list, so whatever you’re looking for, we have something for you. If you’re still exploring other options, we have more budget laptops from other brands in our budget laptop roundup. There are quite a few options out there.
Cooler Master, a Taiwanese peripheral and PC hardware maker, is launching its MM720 lightweight gaming mouse in five brand new colorways. Cooler Master has teamed up with NachoCustomz, a Miami-based mouse modder and designer, to design the new mice.
The limited-edition Cooler Master x NachoCustomz MM720 series is available for pre-order now at $99, with official sales set to kick off sometime in September. The new color options include Vivid Red, Electric Blue, Erika Pink, Beryl Green, and Light Yellow.
“As one of the world’s best mouse modders and custom artists, NachoCustomz has always been at the top of our list of potential collaborators. We’re excited to finally work with his incredible eye for detail to make new, strikingly sexy versions of the already-popular MM720,” said Bryant Nguyen, Peripheral General Manager, Cooler Master.
In case you’re not stoked by the new colors, the good news is that Cooler Master will be putting the existing Black and White MM720 models on a limited-time sale on July 4. The company hasn’t revealed the discounted prices, but you’ll be able to check out the deal at this link when it goes live.
Launched last year, the Cooler Master MM720 is a lightweight RGB mouse aimed at gamers. It features a unique honeycomb shell design and weighs just 49g. The mouse uses an optical sensor that is adjustable up to 32000 DPI and features durable switches graded for 20 million presses, according to the company. It also has an ultra-weave cable which the company says significantly reduces cable drag while swiping and improved PTFE feet that offers super-smooth gliding. Similar to other gaming mice, you can also customize the RGB lighting, create macros, switch between different profiles, and more.
Last week, Microsoft officially unveiled Windows 11. While it won’t be available to the general public until the end of this year, the first preview build of Windows 11 is already out to Windows Insiders. Alongside the x64 build that most users have installed, there’s also an ARM64 build for Windows on ARM devices like the Surface Pro X. The ARM64 build is intended to be installed on supported Qualcomm processors, but that’s not stopping tinkerers from using it to port Windows 11 to unsupported devices.
A few days ago, we saw developers manage to get Windows 11 running on a Lumia 950 XL and Raspberry Pi 4. Now, a few developers have booted up Windows 11 on an Android phone. Some of the developers behind the Renegade Project — a team that ports EDK2 to various platforms — successfully got Windows 11 booting on the OnePlus 6 and OnePlus 6T. One of the team members shared a video that we’ve embedded below which showcases Windows 11 on ARM being installed on a OnePlus 6T.
The video shows user edi194 using a OnePlus 6T that’s already running Windows 10 on ARM. The user then proceeds to flash the preview build of Windows 11 on ARM, and although installation does take quite a while, the phone does manage to successfully boot up the new OS in the end. As the user reports, features like touchscreen, USB, and GPU (partially) are working. However, Wi-Fi, Bluetooth, and audio over speaker seem to be broken.
It’s far from perfect, but seeing Microsoft’s brand-new, full-fledged desktop OS running on a smartphone designed to run Android is cool nonetheless.
The team has also put together a spreadsheet of games they have been testing on the OnePlus 6/6T. Surprisingly, the OnePlus 6T can handle quite a few PC titles, including GTA IV, CS:GO, Far Cry, Minecraft, Need for Speed: Most Wanted, SimCity 5, and more.
This is, of course, not the first time we have seen someone running Windows on a Snapdragon 845-powered device. Back in 2019, Bas Timmer (who goes by the username NTAuthority) managed to boot Windows 10 on a OnePlus 6T as well as a Google Pixel 3.
If you’re interested in learning more about the project and maybe try booting up Windows on your Snapdragon 845-powered device yourself, you can learn more about the Renegade Project from its website. Meanwhile, you can find its GitHub page here and the Telegram group here.
