Hi Brian, Looks like I actually did write some quick migration info here: http://tools.android.com/recent/buildchangesinrevision14 but I think most people overlooked the document (it's not just a migration document, that particular info is kind of buried in there), even though it was linked from the release notes. Also note that this documents was published 3 weeks before the release, and we released a preview of ADT 14 too.
I do agree that we need to better warn developers of changes. Reaching them all I think is a tough issue though. We do publish a lot of info about upcoming changes on our site, we tweet about it, we post on g+ about it, but I'm not sure how much more we can do. As a rules though, a developer who is about to release an app really shouldn't make any update to his development environment. Maybe we'll post a warning about this on the release notes. Regarding your specific issue, I'm not sure what you mean by your wrapper? Are those variables java constants? Those constants should be in the jar file generated and this should impact the compilation of your app. On Sat, Oct 22, 2011 at 10:23 AM, Brian Conrad <[email protected]> wrote: > Xavier finally commented on the issues page involving this. Apparently they > planned a migration article but didn't get to it by the release. It has > bitten developers in different ways. One thing I had notice about my build > using a library was that with the release prior to 14 I was getting two > R.java files, one for the wrapper and one for the library. I was concerned > about problems that might cause but observed that both were the same. > However in one mention about changes on the developer section ID collisions > were a concern and one reason for the change. > > http://code.google.com/p/android/issues/detail?id=20398 > > And then there are the different ways that developers use libraries. In my > case I was referencing some other source code but not really using it as a > "library" in the sense of using the jar file. This was one of two ways that > was previously mentioned in articles on using a library. This allowed for > my wrapper to set some variables then that would cause my "library" to build > a specific version for that release. With this method no jar was created > for the library but the code just merged. I still think this is a > reasonable method of development but the "merge" system no longer works. > > With the new method a jar is created. But that means I have to put the > definition file in the library code and change it every time I want a > slightly different version of the library (usually only effecting a couple > of functions). They also said they did the jar thing to speed up builds > though I wouldn't have noticed on my multi-core 64-bit machine that merged > code took any more time. > > What I think the team learned from this was you can't make such radical > changes without forewarning developers. Some who needed to issue an update > for their app were burned by this. > > - Brian > > > -- > You received this message because you are subscribed to the Google Groups > "Android Discuss" 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-discuss?hl=en. > > -- Xavier Ducrohet Android SDK Tech Lead Google Inc. http://developer.android.com | http://tools.android.com Please do not send me questions directly. Thanks! -- You received this message because you are subscribed to the Google Groups "Android Discuss" 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-discuss?hl=en.
