update feature requests

_src/android/android-enterprise-feature-requests.md

@@ -10,13 +10,11 @@ tags:
 layout: base.njk
 eleventyNavigation:
   order: 1000
-discourse_permalink:
-    - 'https://discuss.bayton.org/t/android-11-cope-changes/355'
 ---
 
 Related to [this](/blog/2022/12/android-features-2023/) and [this](/blog/2019/01/what-id-like-to-see-from-android-enterprise-in-2019/) blog post. Here's my FR wishlist. Feel free to [request an edit](https://github.com/jasonbayton/11ty/blob/main/_src/android/android-enterprise-feature-requests.md) to add more!
 
-## Platform-agnostic (TV, Wear, Automotive, Mobile)
+## All platforms (TV, Wear, Automotive, Mobile)
 
 1. Granular app update management ([ref](/blog/2022/12/android-features-2023/#Granular-app-update-management))
 2. Granular (FOTA-esque) system update management ([ref](/blog/2022/12/android-features-2023/#Granular-system-update-management))
@@ -32,22 +30,25 @@ Related to [this](/blog/2022/12/android-features-2023/) and [this](/blog/2019/01
 6. Data management
     1. Data caps
     2. App-type allow/blocklists
-7. Terminology updates – allowlist for whitelist, blocklist for blacklist (but in a way that doesn't break APIs, we don't need more of those)
-8. More dedicated default APIs (like SMS recently – launcher, phone, browser, etc, etc). Preferred intent _works_ for tested use cases but it could be improved.
+7. ~~Terminology updates – allowlist for whitelist, blocklist for blacklist (but in a way that doesn't break APIs, we don't need more of those)~~ - These are showing up over time.
+8. More dedicated default APIs (like SMS recently – launcher, phone, browser, etc, etc). Preferred intent _works_ for tested use cases, but it could be improved.
 9. Provisioning app caching for enrolment (DPC extras)
     1. Allow extras to list apps to pull at time of provisioning, rather than waiting for enrolment; particularly for required\_for\_setup this can speed things up a fair bit. Allow DPC to "take over" if provisioning is quick and/or apps are slow to DL.
 10. Admin acceptances of T&C's & SUW prompts (GMS core). I know this has been a point of contention for years, but ultimately whether Google wants end users to accept them or not, the reality is the hundreds of thousands staged and/or set up remotely from end users means they never check the boxes anyway.
-    1. For dedicated, multi-person devices, allow a config to accept SUW prompts for management and T&Cs on behalf of the company/admin, not the user. This is a massive time-suck for us today and doesn't suit the EDLA style deployment environments we work in. Allow ZT to be closer to actually ZT for stagers and provisioners
+    1. For dedicated, multi-person devices, allow a config to accept SUW prompts for management and T&Cs on behalf of the company/admin, not the user. This is a massive time-suck for us today and doesn't suit the EDLA style deployment environments we work in. Allow ZT to be closer to actually ZT for staging and provisioning.
     2. Allow force-skip OEM SUW panels. Often these block enrolment until something is done on the device.
     3. Admin-configured SUW panel for support and/or enterprise information
-11. Config of display density
+11. Config of display density (zoom)
 12. Config of time zone after provisioning
 13. Config of locale after provisioning
 14. A universal Android "offline solution" akin to what Apple offers for backup/restore. Swapping devices is still such a pain even on 13; cloud services are OK in what they restore, and the OEM solutions (Pixel, Samsung, etc) are a little better, but it's almost never guaranteed to be a carbon copy from one device to another, or even restoring the same device. I used to leverage TWRP, then later Helium, occasionally ADB backups, to do backup & restore as needed, but it's all too much effort or too technical for the wider market – it's such a low-hanging fruit
-15. Passwordless Factory Reset Protection (FRP), allowing organisations to restrict setup of a device without the need to provide authentication for it (that often needs changing). Instead, set the device in a state that requires and auth/unlock code generated from an account, or lean on passkey/other auth methods instead.
-16. EMM persistence after a factory reset, similar to FRP but allowing the DPC to write a persistence bit to disk, allowing a device to be reset in an unauthorised manner while still requiring a device goes back into management rather than permitting unmanaged setup.
+15. Passwordless Factory Reset Protection (FRP), allowing organisations to restrict setup of a device without the need to provide authentication for it (that often needs changing). Instead, set the device in a state that requires an auth/unlock code generated from an account, or lean on passkey/other auth methods instead.
+16. EMM persistence after a factory reset, similar to FRP but allowing the DPC to write a persistence bit to disk, allowing a device to be reset in an unauthorised manner while still requiring a device goes back into management rather than permitting unmanaged setup where ZT/equivalent is not used
 17. Enforce support for DPC migration, and improve UX for customers. See what [apple are doing](https://9to5mac.com/2023/07/29/an-upgrade-return-to-service-will-increase-mdm-vendor-flexibility/) for comparison.
+    1.  [Partially added](https://bayton.org/blog/2024/01/amapi-migrations/) in AMAPI in Jan 2024, but as weakly implemented as you can imagine.
 18. Logging/debugging capability during setup/enrolment
+    1.  Give admins a means of allowing the existing feedback option in ADP to be shared with the system share activity. 
+    2.  Allow admins to generate a bug report during setup
 
 ## Mobile devices
 
@@ -65,12 +66,13 @@ Related to [this](/blog/2022/12/android-features-2023/) and [this](/blog/2019/01
     6. Layout/folder management
     7. Config of app shortcuts (long-press menu)
 3. Enhance roaming APIs to include forced on, rather than just blocked.
-4. Add DO permission options for battery optimisation & accessibility APIs for EMM control (two frequent OEMconfig APIs!)
+4. Add DO control over all special permissions on fully managed, company owned devices.
 5. Block adding apps as device admins (WP/COPE/FM)
 6. Configure emergency alerts. _I've had my fair share of devices showing amber alerts and similar in deployed locations – not really the expectation of a managed device_
 7. Configure print services
     1. Push and default a print service
     2. Fathom a system of printer remote add/configure
+    3. <span style="color:var(--blood-orange);"><b>A `PrintingPolicy` API [has been added](https://developers.google.com/android/management/reference/rest/v1/enterprises.policies#printingpolicy) in AMAPI for 9.0 and above</b></span>
 
 ## Wear
 
@@ -96,10 +98,14 @@ Related to [this](/blog/2022/12/android-features-2023/) and [this](/blog/2019/01
 8. Industrial use case support (wear for wearable barcode scanners, data input, etc) so we can justify building with wear rather than AOSP as is the case today for small-screen industrial devices.
 9. Open up wear to more OEMs (this isn't a FR, so much as a biz decision to boost wear in the ecosystem)
 
+## Non-mobile
+
+1. Align unified provisioning method options across all non-mobile platforms - TV, Android Automotive, Wear. (I'm hoping BTE will handle this with managed Google accounts)
+
 ## Ecosystem 
 
 1. Cuttlefish builds for TV, Automotive, Wear allowing virtual enterprise testing. Polestar aren't interested in loaning me a car.
-2. Zero-touch customer device uploads
+2. Zero-touch customer device uploads. Every other OOBE solution on the market allows for customer-driven uploads. Resellers are a frustrating friction point harming ZT adoption for existing exstates
 3. Multi-app selection/import in Google Play iFrame
 4. AMAPI feature parity with on-device APIs (seriously, where's offline firmware update management?)
-5. DPC/enterprise migration without device wipe
+5. DPC/enterprise migration without device wipe (Make DPC Migration Useful Again™️)