As a follow-up to the thread about the "provisioned" bit, I'd like to
look at the way some build-time-configurable aspects are exposed to
applications.
Right now, we're exposing android.os.Build ("Information about the
current build, extracted from system properties."). It contains a
dozen of fields (mostly strings) that contain information about the
source code that was used, the build combo, and who built it, where,
and when, i.e. what we often refer to as "the build".
Next to that, we also have android.util.Config ("Build configuration.
The constants in this class vary depending on [the] build."). It
contains a handful of booleans, which were meant to be set according
to the build configuration (e.g. DEBUG, PROFILE, LOGV). Given the way
we now check API differences for compatibility breaks, we can't
actually change those values without introducing what our api-checking
tool considers an API breakage.
I'd like to introduce a mechanism to allow the build-time side to pass
parameters that can be checked at run-time at the SDK API level, for
parameters like the "requires_provisioning" bit.
Requirements:
-Values must be read-only when seen from applications.
-Must not involve any API change when the parameters change.
-Must allow to document each possible value using the usual mechanism.
-Must not involve build-time-generated (or build-dependent) source
files written in the java programming language.
-Performance and footprint are both important.
-Must support at least booleans, integers (int and/or long?) and strings.
I'm thinking that Config is a more appropriate location than Build for
those parameters.
One approach is to do something similar to Build: grab each parameter
at init time (i.e. in a static final) from whichever location is
appropriate (SystemProperties or any other place).
Another approach is to not directly expose individual fields, but
instead to expose functions that take string keys and return the
values: e.g. boolean getBoolean(String key), int getInt(String key),
and expose static final constant strings for the keys.
The former feels like it'd be lighter-weight in terms of memory and
CPU. The latter feels a lot more automated (so that we could just
stick the values in a data file and parse that).
What's the preferred option?
Thanks,
JBQ
--
Jean-Baptiste M. "JBQ" Queru
Android Engineer, Google.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"android-framework" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-framework?hl=en
-~----------~----~----~----~------~----~------~--~---
