Tag: android

Since its launch, sideloading has been a crucial component of Android, giving it a great deal of flexibility as well as a feeling of freedom and openness. The community (quite understandably) panicked when Google announced it would make significant changes to sideloading. However, since Google has now demonstrated how its new sideloading flow on Android will operate, I’m not only relieved that sideloading won’t completely disappear, but also that Google’s compromise is as close to ideal as I believe we can get.

Some have called “Android Developer Verification” the demise of Android’s open nature. The change, which would require developers to register with Google in order to permit their apps to be installed on Android devices, was introduced by Google last year as a restriction on app installation, including sideloading. At first, Google described this as verifying the “who” of an app, similar to an airport ID check.

Combating scams, such as “convincing” bogus apps, and reducing malware and other harmful attacks—particularly those caused by sideloading from sources outside the Google Play Store—were always the main priorities here. Over the years, Google has been more aggressively combating Android frauds, with some degree of success. One way it has done this is by preventing sideloaded apps that are used in scams.

Google officially unveiled the new “advanced flow” this week, which enables users (and developers) to sideload apps that aren’t created by registered developers.After asking the user to certify that “no one is directing me,” the four-step procedure begins a 24-hour delay. In order to initiate the timer, the user must restart their device. After admitting the risks once more, they can resume the sideloading procedure 24 hours later; if they choose to leave it on “indefinitely,” the delay just occurs once. In actuality, this is really a one-time obstacle. Developer options must be enabled, but you can later disable them, which is the largest “headache.”

Google has stated time and time again that a “crackdown” on sideloading is not about taking away freedom or functionality, but rather about protecting users and, most importantly, stopping scams that are common on Android in particular areas. Google doesn’t prevent developers or even consumers from accomplishing what they truly want to do by restricting sideloading as planned, but it puts a huge barrier in the way of con artists.

Scammers frequently use timed pressure and a sense of urgency. A waiting period of twenty-four hours with a few additional warnings? That is a difficult barrier against those kinds of frauds. For people who are being duped by more prevalent scams, it’s also a major inconvenience. For instance, a few weeks ago, after purchasing a low-cost fitness tracker, a family member called me to inquire as to why their homescreen had changed. It turns out that the product needed them to sideload an unidentified software in place of their launcher. I guided them through the uninstall process, but a 24-hour wait and all these extra warning screens? The installation would never have taken place.

It’s a careful method of striking a balance between functionality and user protection. Because developers and enthusiasts who need or want to sideload an app immediately may still utilize the standard ADB tools, whereas the “ordinary Joe” must wait for that 24-hour period to end. Those who truly can’t wait the 24-hour period (which, once again, only needs to be once) still have options, although that is a headache for “regular” users and even more so for fraudsters.

Not to mention that you won’t often have to deal with this anyhow. After developers apply for Google’s developer verification program, sideloading is no longer a problem and there are no waiting times or other “in the way.”

How do you feel about Google’s modifications to Android sideloading? There are undoubtedly still many people who disagree with this, but as previously stated, I don’t think there is a better solution.