It's all doom and gloom in the Android world, with reports of OnePlus' imminent demise swirling — but looking forward, this could actually be a great development.
Google Photos’ new AI wardrobe feature builds a digital closet from your photos, organizes outfits, and even offers virtual try-ons. I tried it on Motorola’s new Razr devices, and it’s a surprisingly compelling look at how AI could reshape your camera roll.
An anonymous reader quotes a report from Ars Technica: In January, the European Commission began an initial investigation, known as a specification proceeding, into how Google has implemented AI in the Android operating system. The results are in, and the EU says Android needs to be more open, which is not surprising. Meanwhile, Google says this amounts to "unwarranted intervention," which is equally unsurprising. Regardless of Google's characterization of the investigation, the commission may force Google to make Android AI changes this summer. This action stems from the continent's Digital Markets Act (DMA), a sweeping law that designates seven dominant technology companies as "gatekeepers" that are subject to greater regulation to ensure fair competition. Google has consistently spoken against the regulations imposed under the DMA, but it and the other gatekeepers have been subject to the law for several years now, and there's little chance the commission backs away from it.
The issue before the commission currently is the built-in advantage for Gemini on Android. When you turn on any Google-powered Android phone, Gemini is already there and gets special treatment at the system level. The European Commission is taking aim at the lack of features available to third-party AI services. The commission believes that there are too many experiences on Android that only work with Google's Gemini AI, and as a gatekeeper, Google must change that. "As we navigate the rapidly evolving landscape of AI, it is clear that interoperability is key to unlocking the full potential of these technologies," said Commission VP for Tech Sovereignty Henna Virkkunen in a statement. "These measures will open up Android devices to a wider range of AI services, so that users will have the freedom to choose the AI services that best meet their needs and values, without sacrificing functionality."
The commission does have a solid track record pushing for openness so far. Since the DMA came into force, Google has been required to make numerous changes to its business in Europe, like implementing search choice screens on Android, allowing alternative payment methods in the Play Store, and limiting data sharing across services. Now, the EU wants Google to make the Android platform more hospitable to third-party AI services. Google's objection focuses on preserving the autonomy for device makers (including Google) to customize AI services. "This unwarranted intervention would strip away that autonomy, mandate access to sensitive hardware and device permissions; unnecessarily driving up costs while undermining critical privacy and security protections for European users," said Google senior competition counsel Claire Kelly. The problem isn't that you can't install ChatGPT or Grok; it's that these chatbots don't have the same access to data and features as Gemini.
To address that imbalance, the EU is considering several requirements that would force Google to give third-party AI assistants deeper access to Android, closer to what Gemini currently enjoys. The proposed requirements include:
- Letting alternative AI tools be launched system-wide through hot words, gestures, or button presses.
- Allowing third-party assistants to see screen context when users invoke them.
- Giving non-Gemini AI tools access to local device data, with user permission, so they can generate proactive suggestions, summaries, and contextual help.
- Allowing other AI services to control installed apps and Android system features on the user's behalf.
- Ensuring third-party developers can access the necessary device hardware to run local AI models with strong performance, availability, and responsiveness.
- Requiring Google to create APIs that let outside AI providers plug into Android more deeply.
- Requiring Google to provide technical assistance to those AI providers.
- Making those APIs and support available free of charge.
The Samsung Galaxy A57 has a thin body, clean software, and a good-looking screen, making it great as an everyday phone. But it struggles with performance and photography.
During routine security research, we identified a severe intent redirection vulnerability in a widely used third-party Android SDK called EngageSDK. This flaw allows apps on the same device to bypass Android security sandbox and gain unauthorized access to private data. With over 30 million installations of third-party crypto wallet applications alone, the exposure of PII, user credentials and financial data were exposed to risk. All of the detected apps using vulnerable versions have been removed from Google Play.
Following our Coordinated Vulnerability Disclosure practices (via Microsoft Security Vulnerability Research), we notified EngageLab and the Android Security Team. We collaborated with all parties to investigate and validate the issue, which was resolved as of November 3, 2025 in version 5.2.1 of the EngageSDK. This case shows how weaknesses in third‑party SDKs can have large‑scale security implications, especially in high‑value sectors like digital asset management.
As of the time of writing, we are not aware of any evidence indicating that this vulnerability has been exploited in the wild. Nevertheless, we strongly recommend that developers who integrate the affected SDK upgrade to the latest available version. While this is a vulnerability introduced by a third-party SDK, Android’s existing layered security model is capable of providing additional mitigations against exploitation of vulnerabilities through intents. Android has updated these automatic user protections to provide additional mitigation against the specific EngageSDK risks described in this report while developers update to the non-vulnerable version of EngageSDK. Users who previously downloaded a vulnerable app are protected.
In this blog, we provide a technical analysis of a vulnerability that bypasses core Android security mechanisms. We also examine why this issue is significant in the current landscape: apps increasingly rely on third‑party SDKs, creating large and often opaque supply‑chain dependencies.
As mobile wallets and other high‑value apps become more common, even small flaws in upstream libraries can impact millions of devices. These risks increase when integrations expose exported components or rely on trust assumptions that aren’t validated across app boundaries.
Because Android apps frequently depend on external libraries, insecure integrations can introduce attack surfaces into otherwise secure applications. We provide resources for three key audiences:
Developers: In addition to the best practices Android provides its developers, we provide practical guidance on identifying and preventing similar flaws, including how to review dependencies and validate exported components.
Researchers: Insights into how we discovered the issue and the methodology we used to confirm its impact.
General readers: An explanation of the implications of this vulnerability and why ecosystem‑wide vigilance is essential.
This analysis reflects Microsoft’s visibility into cross‑platform security threats. We are committed to safeguarding users, even in environments and applications that Microsoft does not directly build or operate. You can find a detailed set of recommendations, detection guidance and indicators at the end of this post to help you assess exposure and strengthen protections.
Technical details
The Android operating system integrates a variety of security mechanisms, such as memory isolation, filesystem discretionary and mandatory access controls (DAC/MAC), biometric authentication, and network traffic encryption. Each of these components functions according to its own security framework, which may not always align with the others[1].
Unlike many other operating systems where applications run with the user’s privileges, Android assigns each app with a unique user ID and executes it within its own sandboxed environment. Each app has a private directory for storing data that is not meant to be shared. By default, other apps cannot access this private space unless the owning app explicitly exposes data through components known as content providers.
To facilitate communication between applications, Android uses intents[2]. Beyond inter-app messaging, intents also enable interaction among components within the same application as well as data sharing between those components.
It’s worth noting that while any application can send an intent to another app or component, whether that intent is actually delivered—and more broadly, whether the communication is permitted—depends on the identity and permissions of the sending application.
Intent redirection vulnerability
Intent Redirection occurs when a threat actor manipulates the contents of an intent that a vulnerable app sends using its own identity and permissions.
In this scenario, the threat actor leverages the trusted context of the affected app to run a malicious payload with the app’s privileges. This can lead to:
Unauthorized access to protected components
Exposure of sensitive data
Privilege escalation within the Android environment
Figure 1. Visual representation of an intent redirection.
Android Security Team classifies this vulnerability as severe. Apps flagged as vulnerable are subject to enforcement actions, including potential removal from the platform[3].
EngageLab SDK intent redirection
Developers use the EngageLab SDK to manage messaging and push notifications in mobile apps. It functions as a library that developers integrate into Android apps as a dependency. Once included, the SDK provides APIs for handling communication tasks, making it a core component for apps that require real-time engagement.
The vulnerability was identified in an exported activity (MTCommonActivity) that gets added to an application’s Android manifest once the library is imported into a project, after the build process. This activity only appears in the merged manifest, which is generated post-build (see figure below), and therefore is sometimes missed by developers. Consequently, it often escapes detection during development but remains exploitable in the final APK.
Figure 2. The vulnerable MTCommonActivity activity is added to the merged manifest.
When an activity is declared as exported in the Android manifest, it becomes accessible to other applications installed on the same device. This configuration permits any other application to explicitly send an intent to this activity.
The following section outlines the intent handling process from the moment the activity receives an intent to when it dispatches one under the affected application’s identity.
Intent processing in the vulnerable activity
When an activity receives an intent, its response depends on its current lifecycle state:
If the activity is starting for the first time, the onCreate() method runs.
If the activity is already active, the onNewIntent() method runs instead.
In the vulnerable MTCommonActivity, both callbacks invoke the processIntent() method.
Figure 3: Calling the processIntent() method.
This method (see figure below) begins by initializing the uri variable on line 10 using the data provided in the incoming intent. If the uri variable is not empty, then – according to line 16 – it invokes the processPlatformMessage():
Figure 4: The processIntent() method.
The processPlatformMessage() method instantiates a JSON object using the uri string supplied as an argument to this method (see line 32 below):
Figure 5: The processPlatformMessage() method.
Each branch of the if statement checks the JSON object for a field named n_intent_uri. If this field exists, the method performs the following actions:
Creates a NotificationMessage object
Initializes its intentUri field by using the appropriate setter (see line 52).
An examination of the intentUri field in the NotificationMessage class identified the following method as a relevant point of reference:
Figure 6: intentUri usage overview.
On line 353, the method above obtains the intentUri value and attempts to create a new intent from it by calling the method a() on line 360. The returned intent is subsequently dispatched using the startActivity() method on line 365. The a() method is particularly noteworthy, as it serves as the primary mechanism responsible for intent redirection:
Figure 7: Overview of vulnerable code.
This method appears to construct an implicit intent by invoking setComponent(), which clears the target component of the parseUri intent by assigning a null value (line 379). Under normal circumstances, such behavior would result in a standard implicit intent, which poses minimal risk because it does not specify a concrete component and therefore relies on the system’s resolution logic.
However, as observed on line 377, the method also instantiates a second intent variable — its purpose not immediately evident—which incorporates an explicit intent. Crucially, this explicitly targeted intent is the one returned at line 383, rather than the benign parseUri intent.
Another notable point is that the parseUri() method (at line 376) is called with the URI_ALLOW_UNSAFE flag (constant value 4), which can permit access to an application’s content providers [6] (see exploitation example below).
These substitutions fundamentally alter the method’s behavior: instead of returning a non‑directed, system‑resolved implicit intent, it returns an intent with a predefined component, enabling direct invocation of the targeted activity as well as access to the application’s content providers. As noted previously, this vulnerability can, among other consequences, permit access to the application’s private directory by gaining entry through any available content providers, even those that are not exported.
Figure 8: Getting READ/WRITE access to non-exported content providers.
Exploitation starts when a malicious app creates an intent object with a crafted URI in the extra field. The vulnerable app then processes this URI, creating and sending an intent using its own identity and permissions.
Due to the URI_ALLOW_UNSAFE flag, the intent URI may include the following flags;
FLAG_GRANT_PERSISTABLE_URI_PERMISSION
FLAG_GRANT_READ_URI_PERMISSION
FLAG_GRANT_WRITE_URI_PERMISSION
When combined, these flags grant persistent read and write access to the app’s private data.
After the vulnerable app processes the intent and applies these flags, the malicious app is authorized to interact with the target app’s content provider. This authorization remains active until the target app explicitly revokes it [5]. As a result, the internal directories of the vulnerable app are exposed, which allows unauthorized access to sensitive data in its private storage space. The following image illustrates an example of an exploitation intent:
Figure 9: Attacking the MTCommonActivity.
Affected applications
A significant number of apps using this SDK are part of the cryptocurrency and digital‑wallet ecosystem. Because of this, the consequences of this vulnerability are especially serious. Before notifying the vendor, Microsoft confirmed the flaw in multiple apps on the Google Play Store.
The affected wallet applications alone accounted for more than 30 million installations, and when including additional non‑wallet apps built on the same SDK, the total exposure climbed to over 50 million installations.
Disclosure timeline
Microsoft initially identified the vulnerability in version 4.5.4 of the EngageLab SDK. Following Coordinated Vulnerability Disclosure (CVD) practices through Microsoft Security Vulnerability Research (MSVR), the issue was reported to EngageLab in April 2025. Additionally, Microsoft notified the Android Security Team because the affected apps were distributed through the Google Play Store.
EngageLab addressed the vulnerability in version 5.2.1, released on November 3, 2025. In the fixed version, the vulnerable activity is set to non-exported, which prevents it from being invoked by other apps.
Date
Event
April 2025
Vulnerability identified in EngageLab SDK v4.5.4. Issue reported to EngageLab
May 2025
Escalated the issue to the Android Security Team for affected applications distributed through the Google Play Store.
November 3, 2025
EngageLab released v5.2.1, addressing the vulnerability
Mitigation and protection guidance
Android developers utilizing the EngageLab SDK are strongly advised to upgrade to the latest version promptly.
Our research indicates that integrating external libraries can inadvertently introduce features or components that may compromise application security. Specifically, adding an exported component to the merged Android manifest could be unintentionally overlooked, resulting in potential attack surfaces. To keep your apps secure, always review the merged Android manifest, especially when you incorporate third‑party SDKs. This helps you identify any components or permissions that might affect your app’s security or behavior.
Keep your users and applications secure
Strengthening mobile‑app defenses doesn’t end with understanding this vulnerability.
[1] Mayrhofer, René, Jeffrey Vander Stoep, Chad Brubaker, Dianne Hackborn, Bram Bonné, Güliz Seray Tuncay, Roger Piqueras Jover, and Michael A. Specter. The Android Platform Security Model (2023). ACM Transactions on Privacy and Security, vol. 24, no. 3, 2021, pp. 1–35. arXiv:1904.05572. https://doi.org/10.48550/arXiv.1904.05572.
This research is provided by Microsoft Defender Security Research with contributions from Dimitrios Valsamarasand other members of Microsoft Threat Intelligence.
Learn more
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
An apparent hack-for-hire campaign from a group with suspected Indian government connections targeted Middle Eastern and North African journalists and activists using spyware, three collaborating organizations said in reports published Wednesday.
The attacks shared infrastructure that pointed to the advanced persistent threat group known as Bitter, which most frequently targets government, military, diplomatic and critical infrastructure sectors across South Asia, according to conclusions from researchers at Access Now, Lookout and SMEX.
Each group took on a different piece of the puzzle:
Access Now got calls on its helpline that led it to examine a spearphishing campaign in 2023 and 2024. It contacted Lookout for technical support about the malware it encountered.
Lookout attributed the malware to Bitter, concluding it was a likely hack-for-hire campaign, using the Android ProSpy spyware.
SMEX dived into a spearphishing campaign targeting a prominent Lebanese journalist last year, collaborating with Access Now to discover shared infrastructure between the campaigns.
One of the victims, independent Egyptian journalist Mostafa Al-A’sar, said he contacted Access Now after receiving a suspicious link from someone he’d been talking to about a job position. He was skeptical because his phone had been targeted before, when he was arrested in Egypt in 2018.
The lesson for journalists and civil society groups is that cybersecurity “is not a luxury,” he said.
“I feel like I’m threatened,” Al-A’sar said, and even though he was living in exile, he feels like “they are still following me. I also felt worried about my family, about my friends, about my sources.”
The combined research found a wider campaign than just the original victims.
“Our joint findings expose an espionage campaign that has been operational since at least 2022 until present day primarily targeting civil society members and potentially government officials in the Middle East,” Lookout wrote. “The operation features a combination of targeted spearphishing delivered through fake social media accounts and messaging applications leveraging persistent social engineering efforts, which may result in the delivery of Android spyware depending on the target’s device.”
“Spying on journalists is often the first step in a broader pattern of intimidation, threats, and attacks,” said the group’s regional director, Sara Qudah. “These actions endanger not only journalists’ personal safety, but also their sources and their ability to do their work. Authorities in the region must stop weaponizing technology and financial resources to surveil journalists.”
Access Now said it didn’t have enough information to attribute who was behind the attacks it identified.
ESET first published research on the ProSpy malware last year, after finding it targeting residents of the United Arab Emirates.
Samsung is reportedly planning to roll out AirDrop-style file sharing for older Galaxy phones via a Quick Share update. Early reports suggest the feature is appearing on devices from the Galaxy S22 through the S25, though it is not actually working yet. Android Central reports: As spotted by Reddit users (via Tarun Vats on X), a Quick Share app update is rolling out via the Galaxy Store on older Samsung devices that appears to add support for AirDrop file sharing with Apple devices. Users report seeing the same new "Share with Apple devices" section we first saw on Galaxy S26 devices in the Settings app after updating Quick Share.
The update is reportedly showing up on Galaxy models ranging from the Galaxy S22 to last year's Galaxy S25 series. The catch, however, is that the feature doesn't seem to be working yet. It's appearing on devices running One UI 8 as well as the One UI 8.5 beta, but enabling the toggle doesn't activate the functionality for now.
Users say that turning on the feature doesn't make their device visible to Apple devices, and no Apple devices show up in Quick Share either. It's possible Samsung or Google still needs to enable it server-side, but it does confirm that broader rollout to older Galaxy devices is coming. The feature could arrive fully with the One UI 8.5 update.
Google is expanding Android Automotive from the infotainment screen into the broader non-safety "brain" of software-defined vehicles. With its new Android Automotive OS for Software-Defined Vehicles, the in-car experience will feel "much more cohesive and the latest features will reach your driveway faster," Matt Crowley, Android Automotive's group product manager, writes in a blog post. "From a truly integrated voice experience to proactive maintenance reminders, your car will become a true extension of your digital life," Crowley adds. The Verge reports: With its new software, Google is promising faster over-the-air software updates, better voice assistants, and more proactive vehicle maintenance alerts. Non-driving functions like climate control, lighting, and seating adjustment would fall under Android's control. And the system would move beyond basic infotainment to create a unified ecosystem for features like remote cabin conditioning, digital key management, and personalized driver profiles.
For automakers, the new system promises less expensive software development costs and an opportunity to focus on what matters most to them: branding. By providing the "foundational code and a common language for their software," Google says automakers will be free to design cool experiences for their customers. Google says its already working with companies like Renault Group and Qualcomm to bring its new software-defined vehicle version of Android Automotive to more cars. A variety of automakers already use regular Android Automotive, like Volvo, Polestar, General Motors, Nissan, and Honda.
An anonymous reader shared this report from Tom's Hardware:
GrapheneOS, the privacy-focused Android fork, said in a post on X on Friday that it will not comply with emerging laws requiring operating systems to collect user age data at setup. "GrapheneOS will remain usable by anyone around the world without requiring personal information, identification or an account," the project stated. "If GrapheneOS devices can't be sold in a region due to their regulations, so be it."
The statement came after Brazil's Digital ECA (Law 15.211) took effect on March 17, imposing fines of up to R$50 million (roughly $9.5 million) per violation on operating system providers that fail to implement age verification...
Motorola and GrapheneOS announced a long-term partnership at MWC on March 2, to bring to bring the hardened OS to future Motorola hardware, ending GrapheneOS's long-standing exclusivity to Google Pixel devices. A GrapheneOS-powered Motorola phone is expected in 2027. If Motorola sells devices with GrapheneOS pre-installed, those devices would need to comply with local regulations in every market where they ship, or Motorola may need to restrict sales geographically.
Or, "People can buy the devices without GrapheneOS and install it themselves in any region where that's an issue," according to a post on the GrapheneOS BlueSky account. "Motorola devices with GrapheneOS preinstalled is something we want but it doesn't have to happen right away and doesn't need to happen everywhere for the partnership to be highly successful. Pixels are sold in 33 countries which doesn't include many countries outside North America and Europe."
Tom's Hardware also notes that GrapheneOS "isn't the first and won't be the last company to outright refuse compliance with incoming age verification laws."
"The developers of open-source calculator firmware DB48X issued a legal notice recently, stating that their software 'does not, cannot and will not implement age verification,' while MidnightBSD updated its license to ban users in Brazil."
An anonymous reader quotes a report from Ars Technica: Google is planning big changes for Android in 2026 aimed at combating malware across the entire device ecosystem. Starting in September, Google will begin restricting application sideloading with its developer verification program, but not everyone is on board. Android Ecosystem President Sameer Samat tells Ars that the company has been listening to feedback, and the result is the newly unveiled advanced flow, which will allow power users to skip app verification. With its new limits on sideloading, Android phones will only install apps that come from verified developers. To verify, devs releasing apps outside of Google Play will have to provide identification, upload a copy of their signing keys, and pay a $25 fee. It all seems rather onerous for people who just want to make apps without Google's intervention.
Apps that come from unverified developers won't be installable on Android phones -- unless you use the new advanced flow, which will be buried in the developer settings. When sideloading apps today, Android phones alert the user to the "unknown sources" toggle in the settings, and there's a flow to help you turn it on. The verification bypass is different and will not be revealed to users. You have to know where this is and proactively turn it on yourself, and it's not a quick process. [...] The actual legwork to activate this feature only takes a few seconds, but the 24-hour countdown makes it something you cannot do spur of the moment.
But why 24 hours? According to Samat, this is designed to combat the rising use of high-pressure social engineering attacks, in which the scammer convinces the victim they have to install an app immediately to avoid severe consequences. "In that 24-hour period, we think it becomes much harder for attackers to persist their attack," said Samat. "In that time, you can probably find out that your loved one isn't really being held in jail or that your bank account isn't really under attack." But for people who are sure they don't want Google's verification system to get in the way of sideloading any old APK they come across, they don't have to wait until they encounter an unverified app to get started. You only have to select the "indefinitely" option once on a phone, and you can turn dev options off again afterward. "For a lot of people in the world, their phone is their only computer, and it stores some of their most private information," Samat said. "Over the years, we've evolved the platform to keep it open while also keeping it safe. And I want to emphasize, if the platform isn't safe, people aren't going to use it, and that's a lose-lose situation for everyone, including developers."
Starting in September, even Android developers not in Google's Play Store will still be required to register with Google to distribute their apps in Brazil, Singapore, Indonesia, and Thailand, with Google continuing "to roll out these requirements globally" four months later. Even developers distributing Android apps on the web for sideloading will be required to register, pay Google a $25 fee, and provide a government ID.
But there's a new theory on what's secretly been motivating Google from an unnamed source in the "Keep Android Open" movement, writes long-time Slashdot reader destinyland:
"You can't separate this really from their ongoing interactions with Epic and the settlement that they came to," they argue. Twelve days ago Epic Games and Google announced a new proposal for settling their long-running dispute over the legality of alternative app stores on Android phones. (Rather than agreeing to let third-party app stores into their Play Store, Google wants them to continue being sideloaded, promising in a blog post last week that they'll even offer a "more streamlined" and "simplified" sideloading alternative for rival app stores. "This Registered App Store program will begin outside of the US first, and we intend to bring it to the US as well, subject to court approval.")
So "developer verification" could be Google's fallback plan if U.S. courts fail to approve this. "If the Google Play Store has to allow any third-party repository app store, Google essentially has given up all control of the apps. But if they're able to claw back that control by requiring that all developers, no matter how they distribute their apps, have to register with Google — have to agree to their Terms & Conditions, pay them money, provide identification — then they have a large degree of indirect control over any app that can be developed for the entire platform."
But that plan threatens millions of people using the alternative F/OSS app distributor F-Droid, since Google also wants to have only one signature attached to Android apps. Marc Prud'hommeaux, a member of F-Droid's board of directors, says that "all of a sudden breaks all those versions of the application distributed through F-Droid or any other app store!"
Prud'hommeaux says they've told Google's Android team "You know perfectly well that you're killing F-Droid!" creating an "existential" threat to an app distributor "that has existed happily for over 10 years." But good things started happening when he created the website Keep Android Open:
There's now a "huge backlog" of signers for an Open Letter that already includes EFF, the Software Freedom Conservancy, and the Free Software Foundation. He believes Android's existing Play Protect security "is completely sufficient to handle the particular scenarios they claim that developer verification is meant to address"...
The Keep Android Open site urges developers not to sign up for Android's early access program when it launches next week. (Instead, they're asking developers to respond to invites with an email about their concerns — and to spread the word to other developers and organizations in forums and social media posts.) There's also a petition at Change.org currently signed by 64,000 developers — adding 20,000 new signatures in the last 10 days. And "If you have an Android device, try installing F-Droid!" he adds. Google tracks how many people install these alternative app repositories, and a larger user base means greater consequences from any Android policy changes.
Plus, installing F-Droid "might be refreshing!" Prud'hommeaux says. "You don't see all the advertisements and promotions and scam and crapware stuff that you see in the commercial app stores!"
Login
TechRadar - All the latest technology news
SecurityWeek RSS Feed
Microsoft Security Blog
