On 08/29/2013 02:46 PM, rpcraig wrote:
>
> c) "Combine" the handling of the availability of a feature [e.g.
>PackageManager.hasSystemFeature(PackageManager.FEATURE_CAMERA)] and a
>"pre-defined", named SE Boolean, so that:
> hasSytemFeature() returns "true", iff "device supports
>camera" AND "SE Boolean allows its use";
> Reflect this also in the method "getSystemAvailableFeatures()";
>
I certainly get that having a boolean to toggle the state of the camera
would be confusing if the device doesn't even have a camera. With your
proposed changes though, what if the camera use is toggled back on via
the boolean but the hasSytemFeature() has already executed and reported
back that no camera exists. Just a thought.
Not sure what the above paragraph means. But to clarify what we are
suggesting:
One specific use-case is this: In the Settings app, menu items are
displayed or hidden based on something like this sort of code:
if (!getPackageManager().hasSystemFeature(PackageManager.FEATURE_WIFI)) {
target.remove(header);
}
We'd like to enable/disable menu items, or other functionality based on
SEAndroid booleans. So that even if the tablet has FEATURE_WIFI, if the
SEBoolean "secure_wifi_allowed" is FALSE, the menu item will be hidden.
I believe the FEATURE_WIFI means: "Does this H/W support WIFI?" and the
Boolean means "Is this tablet allowed to use/configure wifi". The latter
being set by a higher authority.
The way this was accomplished thus far is by making the above if into
something like this:
if (!getPackageManager().hasSystemFeature(PackageManager.FEATURE_WIFI) ||
!SELinux.getSecureAllowedValue(SELinux.SECURE_WIFI_ALLOWED) ) {
target.remove(header);
}
Both values must be true for the menu to appear. There are (at least)
two problems with this style:
1) This code must be sprinkled all over settings, hence the suggestion
of hiding the checking of the SE Boolean in the hasSystemFeature() call.
2) This code (or at least the boolean name: SECURE_WIFI_ALLOWED) is now
tightly coupled with the names in the .te file where the booleans are
defined.
This second problem is the uglier of the two. Esp since we've added
several booleans related to many poss H/W accessories/devices (e.g.
wifi, bluetooth, NFC, etc); and as we rev over time, we see more
booleans of the same ilk being added to the "standard" sepolicy files,
with different names.
So, we're trying to minimize code changes throughout the AOSP tree,
(especially in settings and framework/base areas); and trying to
eliminate (or constrain to a single place) the dependency on specific
SEboolean names. Finally, trying to deal with the overlap in
functionality with the hasSystemFeature(.<SOME_FEATURE_NAME>).
--
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.
