On 08/29/2013 07:11 PM, Ken Black wrote: > Yes. Totally valid comments. It may not be a good thing to overload the > hasSystemFeature() function for the reason you gave. > Or said differently, we are changing the semantics of what it means from > "Can it do X" to "Can it do X, and is it allowed to do X". > And this may be a bad change for other parts of the system. Maybe an > addition of isSystemFeatureAllowed() could be added that > checks the boolean. > > We are just throwing it out, because we've already implemented the > changes mentioned above to Settings and to other portions > of AOSP for our project, but immediately thought they were not ideal for > the reasons mentioned, and hoped for a better > solution that *may* be rollable into an upstream GIT.; but at the least > would be more in-line with the current SE Android direction. > One big question that occurred to us immediately, was: Is calling the > SELinux API to get the SEBoolean value from within the > general Android code base abusing the purpose of those SEBooleans? It is > needed (or something similar) if you want to dynamically and > gracefully change some core Android functionality, but calling it > directly causes your Java code to become tightly coupled w/ .te files. :-(
Yes, I agree that you want an abstraction layer around the boolean check along the lines of what you suggest (isSystemFeatureAllowed), as not only could the boolean name change, but the policy might deny the operation without even using a boolean - just by removing the associated allow rules altogether, or by labeling the resource differently. -- This message was distributed to subscribers of the seandroid-list mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe seandroid-list" without quotes as the message.
