Google Play transforms digital loyalty into real-world prizes at Gamescom with interactive challenges and exclusive rewards.
Google partners with Delaware to provide free Career Certificates and AI training to residents statewide.
A new LTC version 150.0.7871.252 (Platform Version: 16700.62.0), is being rolled out for most ChromeOS devices.
If you have devices in the LTC channel, they will be updated to this version. The LTS channel remains on LTS-144 until October 6th, 2026.
Release notes for LTC-150 can be found here
Want to know more about Long-term Support? Click here
Andy Wu
Google Chrome OS
Gemini can transform your questions and complex topics into custom, interactive visualizations — directly within your Gemini app chat.
Previously, responses were largely text with static diagrams. Now, we’re delivering functional simulations that can help you better understand the topic you’re asking Gemini about. Whether you’re rotating a molecule or simulating a complex physics system, you can explore further with just one prompt. Responses include visual elements — like tables, grids, and simulations — made specifically for your question. For example, ask about a topic that could be explained visually, like “show me how DNA works in 3D,” and you’ll be able to interactively rotate and zoom into a 3D DNA structure. Or ask to watch a pendulum trade energy back and forth, or learn about cash burn rates through an interactive table.
At Google, we believe our products should be secure by design, which is why we built the Android Automotive Operating System for Software Defined Vehicle (AAOS SDV) on existing, market-proven platforms, leveraging virtualization technologies like Cuttlefish. While our release announcements focused on the features, this blog post outlines some of the security concepts.
The current trend of consolidating Electronic Control Units (ECUs) into a single chip reduces isolation by running multiple domains side-by-side.
While AAOS SDV instances provide internal isolation mechanisms, it is often preferable to run logical domains independently. For instance, a cluster and an infotainment system have distinct requirements. We use virtual machines to run multiple instances in parallel, ensuring that sharing remains explicit and isolation is the default behavior.
AAOS SDV evolved from Microdroid, a minimalistic Android version optimized for privacy virtual machines (pVM). This lineage provides Android platform engineers with established security features they already know.
AAOS SDV follows Android’s User ID (UID)-based isolation model to set up a sandbox for each application. Each service runs in a dedicated process with a unique UID to manage access rights, data directories, and other restrictions. We employ Portable Operating System Interface (POSIX) capabilities to strictly limit operations and pair this with Security-Enhanced Linux (SELinux) to enforce a "deny-by-default" posture. This approach restricts each service to the absolute minimum required, meaning missing configurations block access rather than creating an over-permissive system. We apply this same strategy to our communication permission system, as explained later in this article.
AAOS SDV integrates Android’s mature security response and vulnerability management infrastructure to identify, triage, remediate, and disclose security findings. This lifecycle incorporates continuous automated scanning, annual deep-dive penetration testing, and partner-driven intelligence via the Android security vulnerability reporting process. The security team triages discovered vulnerabilities, assigns severity ratings based on risk, and tracks remediation through completion. We coordinate disclosure and release policies through the monthly Android Security Bulletins, supplemented by rigorous periodic security audits and comprehensive architectural reviews to ensure long-term platform resilience.
Beyond guaranteeing process isolation, a secure platform must ensure code integrity before execution. We secure software delivery through the following approaches:
AAOS SDV provides two installation methods. First, we install software directly to read-only system, product, or vendor partitions, which validate signatures on every boot. This secures basic system components.
Second, we utilize Android Pony EXpress (APEX) packages for services. Each APEX encapsulates software and its dependencies, treating the package as a partition with mandatory signature validation. In AAOS SDV, APEX treats code signing as a continuous, hardware-enforced contract. APEX ensures malicious code execution is mitigated through four core pillars:
apex_payload.img file directly as a raw storage device using the read-only loopback, mounting it with the strict MS_RDONLY flag.root privileges, they cannot modify the running APEX code because the file system layer rejects all write commands.dm-verity to verify the signature for every 4KB data block on-the-fly. If an attacker modifies a raw block on the flash memory, the kernel detects the hash mismatch and halts execution immediately./apex./system partition, while updates reside on the mutable /data partition.apexd daemon marks it as "failed" during early boot. The system instantly swaps symbolic links back to the /system partition. This atomic recovery helps ensure the system does not remain in a broken state.Verified loading protects the system from external modification, but platform resilience also depends on how the underlying code is built. For new components developed for AAOS SDV, we prioritized memory safety.
AAOS SDV targets small systems with fast availability requirements; this prevents building on the full Android stack, so we limited our scope to the native framework. To create the required infrastructure for a distributed system, we developed multiple components in addition to existing infrastructure and adopted Rust as the primary language. We also use Rust to develop the business logic of services, helping partners write secure software. By design, Rust leverages memory safety features to help prevent common classes of memory safety vulnerabilities, while supporting team throughput when writing native code.
Software-defined vehicles require secure interactions between isolated domains. The AAOS SDV mesh provisioning architecture addresses this complexity by cryptographically verifying the version and author of every communication endpoint.
The AAOS SDV Mesh establishes authentication by mathematically binding the network identity of every component to its actual binary execution state. This model replaces implicit software trust with hardware-rooted verification.
Mesh authentication is designed to be continuous and cryptographic. This prevents scenarios where, for example, a service like a vehicle gateway trusts a compromised infotainment VM just because it has the right IP address.
Hardware-enforced isolation and automated quarantine protocols secure the platform. Peer devices within the SDV mesh use DICE-based authentication and attestation, as detailed in the following section, to help identify and contain unauthorized code execution or configuration tampering.
The Golden Rule of DICE (Device Identifier Composition Engine): If a single line of code in the firmware changes (even a minor update or a malicious exploit), the derived Compound Device Identifier (CDI) changes entirely, generating a completely different Alias Key.
DICE and TLS (Transport Layer Security) integrate to solve the fundamental challenge of zero-trust architecture: authenticating a machine while simultaneously verifying its software integrity.
The combination of DICE’s hardware-backed identification and TLS’s encrypted handshake allows a receiving machine to verify both the caller's identity and its exact software state.
Traditional certificates only prove possession of a secret; they cannot detect firmware tampering. DICE addresses this via measured boot layering:
Strict access controls govern service interactions within the AAOS SDV mesh. Just like all AAOS SDV software, these access controls are authenticated, and their integrity is protected at the device level and across devices in the mesh through the DICE-based authentication.
AAOS SDV employs a defense-in-depth strategy to enable dynamic vehicle updates without compromising access mechanisms. This model relies on two primary trust layers:
This model allows OEMs to balance security with updatability. For non-security-sensitive services, permissive VM-level policies enable installation via lightweight APEX updates rather than full VM redeployments.
Conversely, permissions for security-sensitive signals must be hard-coded into every VM. The tradeoff is that introducing a security-sensitive service to a new VM requires updating the VM-level permissions system-wide. This necessitates an update to all VMs within the mesh.
AAOS SDV extends Android’s security architecture to address specific automotive requirements through a secure-by-design approach. By leveraging virtualization for domain isolation and enforcing "deny-by-default" access policies, the platform establishes a resilient environment for software-defined vehicles. Cryptographic integrity is maintained via hardware-enforced, on-the-fly verification of executed code.
The platform integrates continuous security lifecycles, ranging from proactive vulnerability management to hardware-rooted identity verification via DICE. These multi-layered defenses allow OEMs to balance advanced feature updatability with the robust security necessary for modern automotive environments. Technical specifications and implementation details are available on the AAOS SDV Overview page.
What people are searching in the leadup to National Parks Week — plus, how Google can help turn your wanderlust into a well-planned adventure.
What people are searching in the leadup to National Parks Week — plus, how Google can help turn your wanderlust into a well-planned adventure.
A look at the winning entries from the Gemma 4 Good Challenge.
On August 26, 2026, we are officially launching our updated user interface for Neat touch controllers and the Poly TC8.
Overall, the design allows users to concentrate on their meetings rather than searching for controls, resulting in a more efficient and aesthetically pleasing experience.
Here's what you can expect:
 |
Pre-meeting experience UI refresh Neat/Poly touch controller will now have |
 |
In-meeting experience UI refresh featuring quick action controls |
This launch brings the modern UI experience to an expanded lineup of hardware, ensuring visual consistency across your meeting rooms. These improvements are designed to reduce user friction and support tickets by mirroring the exact interaction layout users are already accustomed to on their individual workstations.
Expanding availability
With the addition of Neat Pad andPoly TC8, we are continuing our commitment to expanding support for the new UI across all Google Meet touch controllers, including various Android Open Source Project (AOSP) ecosystem devices.