On Thu, Aug 29, 2013 at 3:20 PM, Ken Black <[email protected]> wrote:
> 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: > <snip> > > 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>). > > I guess I needed to be a bit more verbose with my thoughts. If the proposed changes are just to things like the Settings app and other menu UI things, then I can see the real utility in this. I'm more worried about pushing the changes inside the hasSystemFeature() function. I would think we need to be mindful of cases like the following. You start with a policy that has the "bluetooth" boolean set to disabled (or even your init.rc sets the boolean to disable). When the system server starts it does a routine check on hasSystemFeature(FEATURE_BLUETOOTH). Because the policy is blocking use of bluetooth your new logic would have hasSystemFeature() return false. Because of this the bluetooth manager service is never registered with the Service Manager. Then, when the phone has booted I decide to toggle the bluetooth boolean back to enabled or maybe a new policy is pushed to my phone that enables bluetooth. How would you now get access to bluetooth given that it's not registered with the Service Manager? Maybe we could always start with bluetooth enabled or just reboot the phone.... But these are the types of cases I think we should be taken a closer look at. FYI, there are other similar cases like this, i.e FEATURE_USB_HOST, FEATURE_WIFI_DIRECT, ... > > > > -- > This message was distributed to subscribers of the seandroid-list mailing > list. > If you no longer wish to subscribe, send mail to [email protected] > the words "unsubscribe seandroid-list" without quotes as the message. >
