It would be nice to have (UI) tests for features relying on restricted profiles. We probably won't get much manual testing coverage. Since we are hiding and disabling features for restricted profiles this part of the code is great for introducing regressions. So let's investigate whether we can test these things somehow.

Having UI tests for restricted profiles seems to be out of scope for 42. But I'd like to have at least a simple test that verifies that all restrictions are not enforced (isAllowed(*) == true) whenever using a normal profile.

(In reply to Kevin Brosnan [:kbrosnan] from comment #1)
> If this ends up being too difficult to automate we can create a set of
> manual tests and define some critical steps that must be tested every
> release.
Kevin: What would be the process to create this set of manual tests? Most v1 bugs are about hiding features and UI elements. So I guess most manual tests would verify that these features are still accessible with a normal profile and hidden with a restricted profile. Restricted profiles can be configured by the device admin so another test could be to verify that with all restrictions set to OFF the restricted profile behaves almost like a normal profile.

After talking the gbrown, the conclusion is that automated tests cannot happen until the migration to autophone occurs. the tablet emulator is not running a new enough version and the actual hardware are not tablets.

To clarify..."Normal" automated unit tests run on emulated Android 2.3 tablets and emulated Android 4.3 phones, and neither configuration supports restricted profiles.
Autophone runs a select group of tests against a variety of real devices. Theoretically, we could run new autophone tests for restricted profiles, limited to certain appropriate (4.3+) devices (perhaps manually pre-configured with a restricted profile?). This is not technically blocked by the project which is migrating Android Talos tests to autophone, but the people who are most familiar with autophone are currently focused on the Talos migration. autophone tests run today on most trees, but are hidden (they are "Tier-2" jobs). The obvious challenges for restricted profile autophone tests are simply:
- writing the test(s)
- finding appropriate devices
- ensuring sufficient capacity for running the new test(s)