Yes, sorry, built-time-configurable was the wrong title for the thread. Should have been integration-time-configurable.
JBQ On Wed, Jan 21, 2009 at 5:40 AM, Al Sutton <[email protected]> wrote: > > So we'd end up with a mix of buid-time-configuration properties (which > is the title of this thread) and branding options in one place. > > I can see a distinct difference between the two which is why I would > suggest they are handled by two different solutions. That way there is > no possibility for a brander to think they can alter configuration > properties, or a developer to introduce build time properties which > clash which properties added at branding time. > > Al. > > Jean-Baptiste Queru wrote: >> I can think of many reasons why we'd want to avoid dynamic source-code >> generation, but I'll let Dave and Joe comment on the specific details. >> >> I'm pretty sure however that we want to give ourselves the explicit >> possibility of dealing with values that can't be determined at build >> time. It's very common for OEMs to use the same build for multiple >> carriers, and to just change a few configuration parameters to adapt a >> few aspects for the individual carriers. >> >> JBQ >> >> On Wed, Jan 21, 2009 at 5:11 AM, Al Sutton <[email protected]> wrote: >> >>> It sounds like I've missed something, but why exclude build time >>> generation? I punted the idea because these are values which are >>> determined once the build starts (i.e. when the target has been >>> specified) and don't alter once the build has completed, so build time >>> sounds the right place to generate the file containing them. >>> >>> An further problem with a dictionary style API (beyond the checking one) >>> is a performance penalty. Using a get("android.build.property.XXXX") >>> would typically involve converting "android.build.property.xxxx" into >>> some value which is then used in a lookup (e.g. an index into an array, >>> or a hash into a table). This type of solution can't be optimised by >>> compilers or JITs because it's impossible to predict all the possible >>> parameter values and corresponding return values without actually >>> running all possible use cases for all uses of the method (and I don't >>> know of a single compiler which will try to do that). >>> >>> There is also the question of is dynamic expansion a desirable goal? >>> Dave Bort has already said that system properties are becoming a bit of >>> a dumping ground, would allowing dynamic expansion simply move the >>> dumping ground onto a new site and avoid the underlying problem of >>> people not considering alternatives but just adding their own variable >>> in just because that's the way it's been done elsewhere? >>> >>> In the end the use of final statics against a dynamically expandable API >>> may just be a few clock cycles, but I come from a background of coding >>> for 68000 embedded systems and Psions in the 90's and J2ME earlier this >>> decade, so I'm an every clock cycle counts type of guy :). >>> >>> Al. >>> >>> Jean-Baptiste Queru wrote: >>> >>>> Like I wrote in the original requirements, auto-generating java files >>>> as part of the build process is explicitly something that we don't >>>> want to do. That's why Joe's initial suggestion (and his current >>>> recommendation) is to use an API based on functions, not members, such >>>> that the list of values can be expanded dynamically without having to >>>> change the API. >>>> >>>> JBQ >>>> >>>> On Wed, Jan 21, 2009 at 12:48 AM, Al Sutton <[email protected]> wrote: >>>> >>>> >>>>> Looks good to me, it's an improvement over the existing code because >>>>> dereferencing a static final variable will give any compiler or JIT a >>>>> very strong hint that it's safe to substitute the value directly into >>>>> the places where it's used at compile time as opposed to generating code >>>>> which goes through the process of setting up and executing a method call >>>>> each time the value is needed. >>>>> >>>>> On the implementation detail, how does generating the Config.java file >>>>> as part of the build process sound? As I see it the properties are most >>>>> likely going to be dependant on the build target so rather than having >>>>> multiple Config.java's for dev, non-Google build, and Google Build, why >>>>> not patch the build system to generate the correct values? >>>>> >>>>> Al. >>>>> >>>>> Jean-Baptiste Queru wrote: >>>>> >>>>> >>>>>> I've uploaded a proposed implementation with the following changes: >>>>>> http://review.source.android.com/8415 >>>>>> http://review.source.android.com/8256 >>>>>> http://review.source.android.com/8416 >>>>>> http://review.source.android.com/8257 >>>>>> >>>>>> Please don't pay too much attention to the fact that the parameter is >>>>>> backed by a system property, that's an implementation detail at this >>>>>> point. I'm mostly interested in knowing whether this approach is >>>>>> sustainable in the future. >>>>>> >>>>>> Thanks, >>>>>> JBQ >>>>>> >>>>>> On Fri, Jan 16, 2009 at 4:30 PM, Jean-Baptiste Queru <[email protected]> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Agreed. The explicitly goal here is to avoid the use of an additional >>>>>>> system property (well, undo it, or at least hide it behind an API that >>>>>>> we'll be able to re-implement some other way). >>>>>>> >>>>>>> JBQ >>>>>>> >>>>>>> On Fri, Jan 16, 2009 at 4:18 PM, Brian Swetland <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> As a side-note I'd like to try to reduce usage of the underlying system >>>>>>>> properties -- they're becoming a dumping ground for all kinds of random >>>>>>>> stuff, and they were not really intended as an open-ended registry of >>>>>>>> every possible thing we might think to dump in there.... >>>>>>>> >>>>>>>> [Dave Bort <[email protected]>] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> The major benefit of using static final fields that I see is that it >>>>>>>>> becomes very obvious who is using a given flag (e.g., "provisioned"), >>>>>>>>> we can track the existence of that flag using our existing API >>>>>>>>> checking tools, and the build breaks if a flag is removed but there >>>>>>>>> are users of it. >>>>>>>>> >>>>>>>>> A dictionary-style interface, on the other hand, provides no >>>>>>>>> possibility for static checking; there's no way to tell whether or not >>>>>>>>> anyone is using a particular flag. This is the main reason we're >>>>>>>>> trying to kill the uses of the SystemProperties API. >>>>>>>>> >>>>>>>>> --dbort >>>>>>>>> >>>>>>>>> On Fri, Jan 16, 2009 at 3:58 PM, Jean-Baptiste Queru >>>>>>>>> <[email protected]> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> -- >>>>>>> Jean-Baptiste M. "JBQ" Queru >>>>>>> Android Engineer, Google. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> -- >>>>> ====== >>>>> Funky Android Limited is registered in England & Wales with the >>>>> company number 6741909. The registered head office is Kemp House, >>>>> 152-160 City Road, London, EC1V 2NX, UK. >>>>> >>>>> The views expressed in this email are those of the author and not >>>>> necessarily those of Funky Android Limited, it's associates, or it's >>>>> subsidiaries. >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> >> > > > -- > ====== > Funky Android Limited is registered in England & Wales with the > company number 6741909. The registered head office is Kemp House, > 152-160 City Road, London, EC1V 2NX, UK. > > The views expressed in this email are those of the author and not > necessarily those of Funky Android Limited, it's associates, or it's > subsidiaries. > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
