Managing Google system updates with Android Enterprise
It's more important than ever to keep your fleet of devices secure and optimized for work. That’s where Google system updates come into play. Delivering updates from Google to the Android operating system, Google Play Store, and Google Play services, Google system updates make your Android devices more secure and reliable, whilst introducing new, useful features. But these need to be delivered in a timely way that works for your business and employees. So with that in mind, let’s cover the two main tools that can help you manage your Google system updates. System update policies Ideal for: Dedicated devices Pros: Keeps devices up-to-date, without relying on end-users to accept update prompts. Context: Between kiosk mode and digital signage, some devices are constantly running, and don’t necessarily have an assigned end-user to accept update and reboot prompts. In these cases, system update policies offer the perfect solution. They update the device either as soon as the update becomes available, or during a pre-set maintenance window to avoid active hours, so devices remain up-to-date and secure, without user input. There are also options to postpone updates, and freeze updates for a set period for particularly busy times of the year. Google Play system updates (also referred to as Mainline updates) are automatically downloaded as soon as they become available, but are not installed until the next device reboot - whether that’s prompted by user, admin or policy. Compliance policies Ideal for: Knowledge workers Pros: Gives users the flexibility to update on their own terms, whilst making sure devices don’t fall out of compliance. Context: For devices that are assigned to a user, pushing updates as soon as they become available may not always be practical. There’s nothing worse than joining an important client-call flustered and embarrassingly late, after an ill-timed system update. But, then again, companies want to make sure they’re making the most of the new features and security patches that come with each update. Compliance policies offer a balance between security and usability. They ensure that devices remain current against a pre-set standard, whilst giving workers the flexibility to apply updates at a time that suits their work schedule. The device will be tested according to certain signals, such as when the last update was made, or what version OS is being used, and prompt the user to update within a certain time-frame. Next steps These policies can be layered to make sure updates across your fleet are handled securely, in a way that works for your business. For more details on these tools, check out this Help Centre article. You can see what’s new to Google System update policies here. Make sure to also explore the documentation from your EMM provider for support on how these tools can be configured. Let’s get those system updates up-to-date! Have you got a system in place to manage updates? Does your business use one of these methods or a combination of the both? Let us know if and how you leverage these tools - we’d love to hear how they work for you![Product Update] Lock and locate Corporate devices with Lost Mode
Lock lost corporate devices and get real-time location updates to recover them. Android Enterprise admins, have you discovered Lost Mode? It’s a new management feature designed to safeguard your organisation's data and recover misplaced devices. No more frantic "phone-finding" missions or compromised sensitive information - Lost Mode empowers you to take control in challenging situations. Lost Mode empowers device management through: Remote lock down: Instantly lock lost or stolen devices. Gone are the days of helplessly hoping lost devices remain untouched; Lost Mode helps prevent unauthorised access beyond incoming and emergency calls, securing your data, and peace of mind. If the need arises, enrolled devices can also be remotely wiped. Real-time location tracking: Track the location of a lost device in real-time. Whether nestled under a colleague's desk or left in a taxi, Lost Mode can remotely pinpoint a device's whereabouts for hassle-free recovery. Lock screen message: Communicate company contact information directly on the lock screen. If found by a passerby, the pre-set company message will tell them where to return it. Or they’ll have the option to ‘Call owner’ on your chosen contact number with a press of a button, making good deeds a breeze. Audible locator: Turn your device into a beacon. When Lost Mode is activated, the device begins to ring on full volume, guiding you, or a helpful passerby, towards its hidden location. It’s a step up from breadcrumbs or wasting time aimlessly retracing your steps - follow the audible trail and reclaim your missing tech. How does it work? IT admins can easily put a device into Lost Mode from their EMM console. Once the missing device is found, and is back in the right hands, employees can simply exit lost mode with their device passcode and resume business as usual. Or, IT Admins can exit Lost Mode from their EMM console. Beyond immediate recovery, having this security measure in place enables quick action, minimising the risk of data breaches, improving employee peace of mind and eliminating wasted time searching for misplaced devices. Next steps Lost Mode is exclusive to EMMs that use Android Management API, and is currently available for both Work Profile on company-owned devices running Android 13 or later, and fully managed devices on Android 11 or later. To check if this feature has been made available in their console, please contact your EMM. For a step by step on how to enable Lost Mode on company-owned devices, check out this article in the Help Center. Otherwise it would be great to hear from you, have you or do you plan to implement Lost Mode into your device strategy? Which feature do you think will be most useful?[Community survey] Android App Management features and security
Hello everyone, We've had a couple of surveys this month, so I hope you don't mind another. Here in the Customer Community, one of our most popular topic areas is on app management, so I'm hoping this survey is an interesting one for you all. 🤞 It would be great to hear your thoughts and ideas on ways you would like application management features and security to develop further. If you have a spare moment, please take the short survey below and if you have any additional questions, please to reply to this topic below (by clicking 'Reply'). All of the feedback will be passed over to our Product team. Feel free to share this with any colleagues or others working in this area, as it would be great to get a good amount of feedback around this. Thank you in advance for taking the time to do this. 😀 Lizzie Loading… Interested in other surveys? It would be great to hear your feedback on AE secure logs.
[Enhancement Request] Allow push notifications during OOBE setup process
Android does not allow any push notifications during the OOBE (out of box experience) setup process. This presents challenges during Intune enrollment because we require users to satisfy MFA (SMS or MS Authenticator) in order to complete Entra AD device registration and device enrollment. The inability to receive push notifications on the new Android they are configuring requires users to configure their MFA on a secondary device before starting the setup of the new device, or obtain a temporary access pass from our Security Team. If OOBE supported push notifications it would resolve this and provide a much simpler and easier enrollment/user experience.
(COPE) Hide app in work profile
Hello, I have a small case I'd like to submit to the community for help please. A customer use Mobile Iron, and use Zero Touch to enroll our Android 14 products. In their DPC extras, they enabled the system apps and need to keep that way: "android.app.extra.PROVISIONING_LEAVE_ALL_SYSTEM_APPS_ENABLED":true, "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":{ "workProfileEnabled": true, "quickStart":"true" } Now after the device is enrolled, the Work profile is filled with bunch of apps including unwanted ones like Netflix, Adobe, YT kids, ... From Mobile Iron, they want to hide/disable some apps, using "setApplicationHidden" but it doesn't work. At OEM side, we tested this API with the Test DPC and it works properly. My thinking was that as we are in COPE, and the apps that the customer wants to remove are from the Personal space, then this is not working as the MDM cannot interact with Personal space content. Does this make sense? Are there a way to hide the unwanted apps from the Work profile, despite having "leave all system apps" enabled from the ZT DPC extras? Anyone has any suggestions please? Thanks!
Enhancing Android Enterprise OS Update Management
Hi, The way the Android API implements OS update management on Android Enterprise devices is not particularly useful for devices with user affinity. Are there any upcoming API changes for EMM solutions like Microsoft Intune? From my experience with the current API: AUTOMATIC – The OS update is installed as soon as it becomes available via OTA, which is not practical for real-time scenarios. WINDOWED – Similar to AUTOMATIC but with the limitation that OS updates can only be installed within a defined maintenance window. This means that if a user needs to update their device due to a software bug fixed in the latest OS version, they may not be able to do so immediately if the maintenance window is set outside working hours. Source: https://support.google.com/work/android/answer/13791272?hl=en#zippy=%2Cmanaging-system-updates-using-system-update-policies Suggested Improvements: Provide an option to control OS updates on BYOD (Work Profile only). I understand that when enrolling a device through Work Profile, only the work container can be managed via EMM. Google may need to reconsider this approach. It would be beneficial to have an approach similar to Apple’s, where EMM admins can manage OS updates (e.g., push specific updates, set deadlines, etc.) through DDM (Declarative Device Management - Source: https://support.apple.com/en-gb/guide/deployment/depc30268577/web ), even on BYOD devices (Device Enrollment) — without requiring supervision like DO (Device Owner mode). I’m aware that Samsung Knox E-FOTA exists, but it is limited to Samsung devices. Expanding this capability to all Android devices (like Google Pixel devices) would greatly improve update management in enterprise environments. BR, Marco
requirements for provisioning an app on android 13
I have an app that I designed private for my company .... which gets permissions imei android ID block the use of factory restore unlock OEM unlock lock and unlock screen kiosk mode , and I install it by adb command and work perfect with all devices I have more than 170 devices made in this way and takes a lot of time , I would like to provision my app and placed as device owner through the QR the problem is that I do not know how to do it correctly try many things I saw on the internet , like for example the signed app get the sha256 from the apk and pass it to base64 make the json but I don't understand if I have to configure something else in the app for the provisioning I tried to scan a generated qr with everything correct and it didn't work it says contact your IT support for more information if someone can guide me it would be great, android 12+ a friend sent me some java and kt files for provisioning that worked for him, but for my app it doesn't work. my app has no icon because I need to pass silently and already does but as I say the problem is that I do not know if I am missing a file or a specific configuration I am missing only this and I would be grateful if someone can help complete it or guide me, I saw options like google workspace but I could not modify the block screen to be customized, try with the api google managament android and also does not let you create the company by command then I'm desperate and do not know what to do Thanks for read
Audio management in Android Enterprise
From the feature list in Android Enterprise from https://developers.google.com/android/work/requirements#4.25.-system-audio-management_1, I want to discuss the feature 4.25.2. IT admins can prevent users from modifying device volume settings (go to adjustVolumeDisabled). This also mutes the devices. In theory a very good feature, in certain areas when you want to block users from either changing the volume to silent or the other way. Our goal was to use with Samsung Service Plugin where you can set the default volume, but since blocking the volume buttons on the phone, you are also stuck with a mute device. So my feature request would be to have the feature without muting the device.
