What I'm not really sure if this should be the default policy (as there can't be more than one policy engine at a time installed in the comppsitor), or if it should be present in the source code for people to use if needed. A deny-all policy is basically the allow-all policy but negated, there is nothing more to it. As I don't have a mechanism to switch dynamically between policy engines or have some kind of scripting behaviour, the compositor needs to be re-compiled and pointed at the desired policy engine.
Or maybe have the deny-all policy installed and have the demo apps listed as allowed?
Environment
None
Activity
Show:
Walt Miner
July 10, 2020 at 5:30 PM
Close for JJ RC1
Marius Vlad
June 29, 2020 at 9:11 AM
Changes have been merged.
Scott Murray
June 5, 2020 at 2:17 PM
I'd be okay with it just being in the source tree as example code, to show how to use the policy hooks. If it was a compile option, perhaps having only homescreen, launcher, and one or two app names/roles explicitly allowed would be workable, so that starting other apps could be done to act as a test/demo of the policy hooks.
Minor
This is a follow-up from SPEC-3412.
What I'm not really sure if this should be the default policy (as there can't be more than one policy engine at a time installed in the comppsitor), or if it should be present in the source code for people to use if needed. A deny-all policy is basically the allow-all policy but negated, there is nothing more to it. As I don't have a mechanism to switch dynamically between policy engines or have some kind of scripting behaviour, the compositor needs to be re-compiled and pointed at the desired policy engine.
Or maybe have the deny-all policy installed and have the demo apps listed as allowed?