In this particular example, it's not a simple case of copying the primary_text_light.xml to the app's resource structure because that file references "private" built-in resources.
How best to handle that!? On 27 January 2011 10:55, Bob Kerns <[email protected]> wrote: > Just to be very clear about it -- given the current reality, I suggest > viewing all firmware-defined resources as, well, infirm. > > I'm just saying this is something which OUGHT to have been done > better, and could still be, by the platform team -- including the > tricky task of getting the OEMs on board to not screw it up. > > This is a long way from happening, and I would predict it NEVER > happens. If *I* were in charge, that would be a different matter... > > I'm not claiming it's easy, either. > > On Jan 26, 11:53 am, Mark Murphy <[email protected]> wrote: > > I would recommend that developers depend as little as possible on > > explicitly using firmware-defined resources. If you need them, copy > > their values into your project. Or, at least have a value that you use > > as a fallback in case a firmware-defined resource is not available. > > There have been too many cases of OEMs changing (or, in your case, > > apparently removing) these resources in ways that cause problems for > > apps. > > > > While I appreciate the argument that using system-defined resources > > makes it easier to blend into the platform, IMHO... > > > > stability > internal consistency > platform fidelity > > > > and the system resources are unreliable and, if changed, may be > > inconsistent with non-system-resources in the rest of your app. > > > > > > > > > > > > > > > > > > > > On Wed, Jan 26, 2011 at 10:26 AM, Mark Carter <[email protected]> > wrote: > > > Analytics for one of my apps tells me that on rare occasions this > > > exception is thrown from the Activity.setContentView() method: > > > > > java.io.FileNotFoundException: res/color/primary_text_light.xml > > > > > It happened on a Motorola Milestone which appears to be using official > > > firmware: SHOLS_U2_01.03.1.1257641482 (which is SDK 2.0, I think) > > > > > The resource in question refers to a built-in Android resource which > > > has been there since API level 1. > > > > > Clearly this is not a programming error but something else. > > > > > Any ideas how this can happen? > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Android Developers" group. > > > To post to this group, send email to > [email protected] > > > To unsubscribe from this group, send email to > > > [email protected]<android-developers%[email protected]> > > > For more options, visit this group at > > >http://groups.google.com/group/android-developers?hl=en > > > > -- > > Mark Murphy (a Commons Guy)http://commonsware.com| > http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > > > Android Training in London:http://bit.ly/smand1andhttp://bit.ly/smand2 > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- You received this message because you are subscribed to the Google Groups "Android Developers" 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-developers?hl=en
