APKs, sideloading, and Google Play: How to really assess the risk

If you browse Android forums, you’ll keep running into the same attitude:
“I only install apps from the Google Play Store. APKs and sideloading are too risky for me.”

On the surface that sounds reasonable. Google has review mechanisms, Play Protect, policies, and you’re constantly seeing warnings about “apps from unknown sources.” At the same time, the term “sideloading” has turned into a catch‑all for anything that smells like malware, code loading, or bypassing security mechanisms.

The problem: that equivalence is technically wrong and leads to a dangerous distortion. You ignore how much malware actually ends up in the Play Store, and you underestimate how safe a signed APK delivered directly by a security vendor can be.

Why so many users reflexively consider APKs “dangerous”

Android sets the tone itself: by default, the system blocks installations from “unknown sources.” If you try to open an APK from your browser or a file manager, you’re greeted with some pretty clear warning messages. In the default setting, that’s reasonable—for classic end users who would otherwise try every “Free Full Version” download they come across.

The psychological effect is obvious:
Everything that doesn’t come from the Play Store automatically feels unsafe. At the same time, Play Store apps are perceived as “vetted”—and most users instinctively equate that with “clean.”

In reality, the picture is much more complex. Even Google’s own guidelines don’t say “everything outside the Play Store is bad,” but instead talk about trusted sources—and that most definitely can include a developer’s official website.
So the blanket formula “APK = dangerous, Play Store = safe” is already questionable at the conceptual level. To understand why, we first need to look at what we’re actually dealing with technically.

What an APK is technically—and what it isn’t

An APK is simply Android’s installation package format. Protectstar’s FAQ describes it very aptly: an APK file is the format Android uses to install apps—the same format the Google Play Store itself downloads and installs in the background.

Comparing to other platforms helps:
On Windows you often install software via .exe installers. On macOS it’s .dmg images or .pkg packages.
On Android it’s .apk.

Inside that file you’ll find:

• compiled bytecode (Dalvik/ART, DEX),
• resources like graphics, layouts, strings,
• the manifest with permissions and components,
• the developer’s signature.

When you install an app from the Play Store, the system is doing exactly the same thing as with a sideload—just automated: it downloads an APK from Google’s servers and installs it via the PackageManager.

The file type itself is neither illegal nor automatically infected. As Protectstar puts it in its FAQ: an APK is not inherently illegal or infected with malware—it’s just a container. What matters is where it comes from and who signed it.
Source: https://www.protectstar.com/en/faq/apk-are-apk-files-harmful-are-apk-files-illegal-if-not-downloaded-from-google-play-store

Legality, trust chain, and why the source is everything

If you look at the ecosystem with a cool head, you can distinguish three types of sources:

• Official developer websites
  One example is the Protectstar website. There you get APKs straight from the vendor, signed with their original key, unmodified, with no “middlemen.” The Protectstar FAQ rightly describes this variant as generally legitimate, safe, and clean—as long as you are really on the official domain.
• Official app stores (Google Play, some OEM stores)
  Here you get additional filters: automated scans, policy checks, sometimes manual reviews. For average users, that’s a huge improvement over randomly clicking on APKs across the web. But as we’ll see in a moment, this layer is far from perfect.
• Illegal portals, “Free APK” sites, cracks
  This is where most horror stories come from. There are explicit warnings against downloading “free” versions of otherwise paid apps from shady sites, because those packages are often tampered with and bundled with spyware or trojans.

From a security perspective, an APK from a legitimate vendor site is closer to an enterprise deployment or an MDM push than to a “random APK from the internet.” So the problem isn’t the fact of sideloading itself—it’s the trust chain:
Domain → Vendor → Signature → App architecture.

Sideloading is not the same as “loading extra code”

Next we need to clearly separate two concepts that are constantly mixed up in everyday language:

• Sideloading means: you install an app from a source other than the Play Store. That could be a browser download, an MDM push, an ADB install, or an enterprise store. It describes nothing more than the installation path.
• Dynamic code loading means: after installation, the app downloads additional executable code from the internet—often as a DEX file, ZIP container, or modular plugin—and executes it at runtime.

From a threat‑model perspective, dynamic code loading is the truly critical part. That’s the exact mechanism used by many Android malware families: a seemingly harmless app acts as a dropper, later fetches the actual payload, and transforms itself into something completely different from what was originally scanned and approved.

And this has absolutely nothing to do with whether the initial installation came via Google Play or sideloading. There are Play Store apps that contain such loaders and only “turn bad” later; and there are signed APKs delivered directly by reputable vendors that deliberately don’t load code dynamically and only change via regular updates.

So if you equate “sideloading” with “malware loaded later on,” you’re mixing up two layers. The more accurate view is: you should avoid apps whose architecture is designed to load new, unverified code modules at runtime—regardless of where you installed those apps from.

How much malware actually lands in the Google Play Store

If you only listen to the Play Store warnings about “unknown sources,” you might think:
“As long as I stick to the Store, I’m on the safe side.”
Current reality paints a different picture.

A recent report from Zscaler, summarized among others by Tom’s Guide, shows that between June 2024 and May 2025, 239 malicious apps were identified in the Google Play Store, totaling over 40 million downloads. That corresponds to an increase of around 67% in mobile malware compared to the previous year. The focus: spyware and banking trojans targeting mobile payment systems and login credentials.

In parallel, researchers from ThreatLabz and Zscaler analyzed a campaign in summer 2025 in which 77 malicious apps with more than 19 million installations in total were discovered in the Play Store and later removed. These apps distributed, among others, the banking malware Anatsa (TeaBot) as well as Joker and Harly variants.

The pattern is always similar:
First, the app appears as a supposedly useful tool, for example a document viewer, health app, or “cleaner.” After installation, it acts as a dropper, connects to a command‑and‑control server, downloads additional encrypted DEX code, and only then activates its actual malicious functionality: from intercepting SMS messages to sneaking you into premium services to targeted tampering with banking apps.

Protectstar’s security experts also find apps in the Google Play Store almost daily that are infected with the Android Joker trojan—despite Google’s extensive review processes.
The bottom line of these reports is clear:

The Play Store reduces risk, but it is not a “malware‑free zone.” Even with Play Protect, machine‑learning scans, and policy checks, highly‑sophisticated malware keeps slipping through the review process, staying online for weeks or months and reaching millions of devices before being noticed and removed.

So if you say “I only trust the Play Store, everything else is too dangerous,” you’re overlooking the fact that a significant portion of modern Android malware is being distributed through that exact channel.

Why security vendors deliberately offer APKs outside the Play Store

The obvious question is: if the Play Store at least provides an extra review layer, why do security vendors like Protectstar forego that “bonus” and offer their Premium, Professional, or Government editions as direct APK downloads?

The answer has several parts:
First, many security‑relevant features are restricted by Play Store policies. That includes aggressive ad‑blocking, certain firewall mechanisms, deeper system interactions, or secure SMS and data wiping like in iShredder. Google forbids or limits such features because they conflict with generic usage policies or business interests. The APK versions delivered directly by Protectstar can include these features in full.

Second, the Play Store approval process is a bottleneck for security‑critical updates. Every new version has to be submitted, reviewed, and approved. Protectstar points out that their apps, when downloaded directly as APKs, use their own update system—allowing them to ship important patches and new features often several days earlier than via the store.

Third, it’s about privacy and transparency. A direct download from the vendor’s site means: no extra tracking SDKs, no store‑dependent telemetry layers, and no payment model where a third party—Google in this case—takes up to a 30% cut, which in turn pushes many developers toward additional monetization pressure.

And finally, there’s a very practical point:

Companies and professional users often want to deploy security tools via their own workflows and manage licenses centrally—independent of personal Google accounts, Play Store policies, or regional restrictions. Signed APKs with MY.PROTECTSTAR integration are much easier to fit into those scenarios.

From an experienced user’s perspective, this creates a completely different picture: skipping the Play Store here is not a security risk—it’s actually a prerequisite to even make a full‑featured, quickly updated, and privacy‑friendly version of a security app possible.

Android System SafetyCore: When “security” itself becomes a black box

A good example of how complicated things have become is Android System SafetyCore.

Protectstar dedicated a separate blog post to this service (https://www.protectstar.com/en/blog/android-system-safetycore-hidden-installation-and-what-you-should-know). It describes how, on many Android devices, a new system app called “Android System SafetyCore” suddenly appeared—no icon, no official opt‑in, visible only among the system apps in some cases.

According to Google, SafetyCore is meant to scan images locally on the device, for example to detect nudity or other “sensitive content,” and to blur or filter it if necessary. Google emphasizes that scans run on‑device and photos are not uploaded. Still, the behavior is unsettling: the app was silently rolled out in the background via system or Play services, without users actively consenting.

Protectstar rightly points out that the core problem isn’t necessarily the bare function itself, but the lack of transparency and control. When a vendor pushes a deeply integrated scanning component onto your device without notice, the line between “security feature” and “surveillance potential” becomes very thin, and questions of trust are unavoidable.

What’s especially interesting in our context: SafetyCore is distributed via the very infrastructure that’s labeled “trustworthy” by default—Google system services and the Play ecosystem channel. That shows how pointless it is to base trust solely on the “Play Store vs. APK” channel distinction. The key question is: who is in control, how transparent is the function, and how much insight do you have into what’s happening in the background?

Tools like Anti Spy, Antivirus AI, and Firewall AI are therefore consciously designed to detect and analyze system processes like SafetyCore and, if you wish, cut them off from the network—and again, they’re delivered as signed APKs directly from the vendor, not dependent on the Play Store’s goodwill.

How to use APKs professionally as an experienced user

If you’re technically savvy, you typically don’t want to “block everything that isn’t from Google,” but rather have a sensible threat model. When dealing with APKs, that means:
You don’t formulate a dogmatic rule like “never sideload,” but distinguish based on trust anchors and architecture.

1. In practice, that looks like this:
   You check the vendor behind every app, regardless of how it’s installed.
   Is this a known vendor with a track record, legal imprint, support structure, and clear privacy policy? Or is it a brand‑new developer account with no reputation whose first app just happens to be a “battery optimizer,” “super cleaner,” or “document viewer”? Those are exactly the kinds of utility apps that have repeatedly turned up in recent years as carriers for Joker, Harly, or Anatsa campaigns.
2. You look at the permissions and ask whether they match the purpose.
   An app that only sets a wallpaper doesn’t need SMS read access; a cleaner doesn’t need Accessibility Services; a document viewer doesn’t necessarily need full access to all files. In many analyzed Joker & co. campaigns, the warning sign was precisely that combination of innocuous‑sounding category and overblown permissions.
3. You actively reduce your attack surface.
   You uninstall apps you don’t really use anymore instead of leaving them around as “maybe later.” Every additional app—whether from the Store or via APK—increases your potential attack vectors.

Where things are heading: verified developers and more professional sideloading

Another development you should keep an eye on is Google’s new Developer Verification Program: in the coming years—2026 is the target—every app on certified Android devices will have to be tied to a verified developer account, including verified identity and contact information.

What may first sound like another hurdle against sideloading is actually a step toward a more professional ecosystem. Disposable, anonymous accounts will have a harder time pushing large numbers of malicious apps—regardless of whether they come through the Play Store or alternative channels. Serious vendors, especially in security, will work with verified accounts and can still distribute their APKs via their own infrastructure.

For you as a power user this means: the line will increasingly run between “known, verified vendors with a traceable identity” and “somebody who’s here today and gone tomorrow.” That directly supports the model we’re discussing here: not black‑and‑white thinking along the Play Store boundary, but risk‑based evaluation per vendor and per app.

Side note: Do you even need antivirus on Android?

If you’re very disciplined about what you install, carefully check permissions, and keep Play Protect enabled, you’ll lower your risk—but you won’t eliminate it. The reason is simple: attackers have adapted their tactics. Even within the official Google Play ecosystem, campaigns keep appearing that only “go live” after installation, for example via dynamically loaded code. That’s how inconspicuous “tools” manage to slip past millions of users for weeks before they’re banned—between June 2024 and May 2025 alone, 239 malicious Play Store apps with over 42 million installations were documented. That’s not a theoretical threat; it’s backed by independent reports.

The important distinction again is between sideloading and code loading: sideloading only describes the installation path, not the app’s behavior at runtime. An app from the Play Store can absolutely download payloads later on and turn into something different from what the Store initially reviewed. Conversely, a signed APK delivered directly by the vendor can be designed not to load arbitrary third‑party code and to change only via signed updates. For your personal threat model, the channel matters less than the architecture.

That’s exactly where Antivirus AI and Anti Spy come in—as an additional protection layer that doesn’t depend on any particular app channel. Antivirus AI targets the broad malware spectrum with a dual‑engine approach (classic signatures plus learning AI) and runtime monitoring; Anti Spy focuses on the niche of spyware and stalkerware, including persistence tricks like abusing Accessibility Services, hidden package names, and unobtrusive background services. Together they close gaps left by “careful installing” and Play Protect alone.

So you don’t have to rely solely on vendor promises; there’s hard evidence. AV‑TEST regularly certifies Android security apps in standardized lab scenarios. Antivirus AI has been awarded across multiple test cycles and is confirmed again in 2025 as “third year in a row”; the product page and news items highlight, among other things, 99.8% real‑time detection and 99.9% detection of widespread malware. Anti Spy received an AV‑TEST certificate back in January 2024; the report shows 99.8% real‑time detection and 100% detection in the four‑week set. That’s a solid indication that both products deliver not just on paper but under lab conditions.

The second pillar is the app security architecture. Through the App Defense Alliance, DEKRA evaluates whether an app meets the MASA L1 standard (based on OWASP MASVS L1), checking whether basic security controls are implemented properly—for example encrypted communication, no storage of sensitive data in plain text, correct permission and export design, and safe library usage. Both Antivirus AI (package com.protectstar.antivirus) and Anti Spy (com.protectstar.antispy.android) have passed MASA L1; the official ADA reports list the validation type as “Level 1 – Verified Self,” note the scan verification by DEKRA, and the respective issue dates (03/17/2025 and 03/06/2025). For you, that means: it’s not just detection quality that checks out, the underlying app architecture is hardened according to recognized criteria.

And that combination of lab performance and clean architecture is visible outside the security bubble as well. In 2025, Antivirus AI received the BIG Innovation Award and the AI Excellence Award from the Business Intelligence Group—not technical certifications in the narrowest sense, but clear signals that the technology approach and roadmap are convincing. Company updates document these awards and place them in the context of product development.

Putting all this together, you get a sober picture: Play Protect is still a sensible baseline, discipline always helps, but modern campaigns deliberately exploit the gray areas where static checks react too late. A lightweight, certified extra layer like Antivirus AI plus Anti Spy significantly reduces your residual risk—regardless of whether you get apps from Google Play or install signed APKs directly from the vendor. And especially for security apps, getting them directly is not a contradiction but an advantage: faster security updates, full functionality, and a traceable trust chain from domain to signature to product.

Conclusion: Move away from myths toward a mature security model

If you put everything together, you get a much more mature picture than the usual “Play Store good, APK bad”:
An APK is nothing more than Android’s standard installation format. The Play Store itself works with APKs under the hood.
Sideloading only describes how an app gets onto the device—not whether it later loads malicious code. The truly dangerous technique is dynamic code loading via dropper structures, and unfortunately that keeps showing up in Play Store apps as well.

Current numbers show that hundreds of malicious apps with tens of millions of installations have been discovered in the official store before being removed. The Play Store is an important but far from perfect security layer.

A signed APK directly from a specialized security vendor like Protectstar can give you full functionality, faster security updates, and more privacy control than would be possible via the Store—especially for Professional or Government editions.

In the end, the decisive factor isn’t whether you install an app from the Play Store or via APK. What matters is whether you have a clear, technically grounded trust model:

• You know which vendor you entrust with your most sensitive tasks.
• You have a basic understanding of how their apps work technically—especially when it comes to permissions and code loading.
• You complement that with your own security tools that operate independently of the store ecosystem and give you real transparency into processes and network traffic.

If you follow this approach, you don’t need to be afraid of the words “APK” or “sideloading.” On the contrary: you consciously use the advantage of dealing directly with the vendor where it makes sense - and in return, you get exactly the level of security you actually want as an experienced user: complete, fast, transparent, and not watered down by store policies.