Shared publicly  - 
21
24
Bartosz Gadzała's profile photoCloud Tu's profile photomatthias sweertvaegher's profile photoSimon Vos's profile photo
40 comments
 
Wow. I love the lint improvements in r17, but I think the bigger news is the x86 support for Windows/Mac and the new additions to the Support Library (particularly NavUtils - something I was just working on in my app).
 
+Ian Lake the x86 native emulator is fracking sweet. Just tried it out, and finally there's an emulator with usable performance. Can't wait until Intel releases support for 3.x+!

Great work, +Xavier Ducrohet and teammates!
 
Wow! The x86 emulator is reallllllly fast (tried the only x86 system image, API 10). A bit weird that the notification and menu icons look blurred, but it's not a big deal. (Maybe hdpi icons are not included.)
 
I absolutely agree, the x86 emulator is awesome. More system images would be really nice (also a backport to 2.1 or 2.2 would be great). Finally testing on an emulator is enjoyable. Great job!
 
+Xavier Ducrohet I've always included libraries in my projects with Eclipse User Libraries, that way there was no need to manually copy the .jar file for each needed library into the "libs" folder. Is there any strong reason you (or anyone else for that matter) would recommend to use the "libs" folder instead of User Libraries?
 
+Ricardo Amaral user libraries will work as long as they are exported. The advantage of libs is that it's common to ant which is useful if you want to have a builder server to automated builds.
Now, adding a jar to the libs folder has the same effect (ie adding it to the classpath) whether your building with Ant and/or Eclipse.
 
+Xavier Ducrohet Yes, I was just wondering if there was a good reason to use the "libs" folder instead (because everyone seems to go that route instead of User Libraries). I guess another one could be if I shared my project with someone, or open-sourced it, everyone could easily compile having to fix the library dependencies.

One other thing if you don't mind... Maybe this already happened before but I didn't notice. I'm using a third-party library on my project, for which I have the source, not just the final .jar file. I include it in my project as Library Project. This third-party library includes the Support Library and I was, until now, including it myself in my project. If they are the same revision, I assume I can remove the one from my project and let it use the one from the library, everything will work fine, right?

But what if I need the new revision and this third-party library is not updated for a while. Should I include the new revision in my project? Is there going to be any conflict?
 
+Ricardo Amaral with the new mechanism there will be a conflict as it'll detect the two jar files are different.
We are planning to add a better dependency system to be able to detect which jar is which version of the same library to have the system be able to pick the latest one.
 
+Xavier Ducrohet Sorry to bother you again but my project is not working properly with the new tools/sdk.

I get exceptions saying it can't find classes from AdMob's library. The AdMob .jar file was included as a User Library (as I've always had it) and it doesn't work. I moved it to the "libs" folder and it started working.

Maybe something you guys overlooked on the User Library's end or maybe I'm missing something?
 
+Xavier Ducrohet What do you mean? I didn't change anything (besides the tools update) and everything was working fine before.
 
in the link I gave you earlier, in the Eclipse changes section, there's a part that starts with important:
read it.
 
+Xavier Ducrohet Sorry, I might have missed that as I didn't see any reference to "user libraries" but I get it now. Thanks.
 
+Xavier Ducrohet I'm having another issue with the new ADT, now in the Lint department. For some reason I don't get the location/file/line where the errors are and as such there's no quick assist in Eclipse. I ran Lint through the command-line and the HTML output correctly shows the location and highlights the problematic code. Any idea what could be causing this issue on Eclipse?

EDIT: I believe I found the problem but I don't know how to fix it while maintaining my Eclipse workspace structure. The thing is, I have my workspace structure like this:

-| Workspace
---| Applications
------| App 1
------| App 2
---| Components
------| Lib 1

And for some reason Lint can't handle this. If I place App 1, App 2 and Lib 1 in the root Workspace folder, Lint works correctly.

Any ideas?
 
This sounds like http://b.android.com/27527 -- I'm going to upload a snapshot of ADT 19 where the bug is fixed; can you try it and let me know whether it's the same bug?
 
+Tor Norbye Just installed it. Now it seems to be working properly. Although I have a feeling that when I ran Lint in the command line, more errors/warnings were reported. Maybe I'm wrong (most likely) and the different kind of report (webpage vs eclipse) is making me believe that. I'll have to double check but right now I can't do it. Two questions though:

1) Is this version stable enough to use or should I revert back?

2) When I press "Check <my_project_name>" the Android library projects added to my project also get checked. Any way to disable this behavior? Right now I "solve" this by clearing the Lint markers for those library projects.
 
1) Yes, I think it's probably more stable than ADT 18; it contains mostly bug fixes, though it hasn't been tested much, so it's possible that some of those fixes introduced new problems. ADT 18 was deliberately kept small to avoid introducing risk. (There is one exception to this: the layout editor is undergoing a bunch of changes now, so let me know if you see weirdness there though the goal is for it to be a big improvement.)

2) Sorry, there isn't a way to do that. I guess there should be?
 
+Tor Norbye 1) I don't use the layout editor that much. But if I eventually use it and see any problems, I'll report them. 2) Well, I would appreciate such option. I'm not the owner/maintainer of these libraries and their problems kinda get in the way. 3) Thanks by the way :)
 
+Tor Norbye About the layout editor, just noticed something. Don't know how relevant this is...

One of the libraries I'm using is an ActionBar (it's not Sherlock) and the widget is placed in the XML code with just 2 attributes, id and style. The stylealready defines a layout_width/layout_height attribute but in the visual editor I still get some output in the bottom:

"actionbar" does not set the required layout_width attribute:
(1) Set to "wrap_content"
(2) Set to "match_parent"
"actionbar" does not set the required layout_height attribute:
(1) Set to "wrap_content"
(2) Set to "match_parent"
You must supply a layout_width attribute.
You must supply a layout_height attribute.
 
As of ADT 17 or so, there's a new BuildConfig class (generated alongside the R class) which defines a DEBUG flag. If you surround your Log calls with "if (BuildConfig.DEBUG)" then they will be stripped during release builds (because BuildConfig.DEBUG is a static final boolean, so the java compiler will completely remove the if and its body at compilation time).

If you want to remove logging calls at release time without adding the if check around the log calls, it might be possible using Proguard; I think there are some blog entries on it (though I haven't tested it myself).
 
Thanks +Tor Norbye , I saw the mention of the new BuildConfig class (I've been using my own static final boolean DEBUG constants in my projects for this same purpose) and it's nice that this is now included, but doesn't help too much when it's the libraries I'm using that are generating the log calls (like AdWhirl).

I'll take a look at Proguard (probably about time I learn to use it anyway). Nice proguard changes by the way. I've largely ignored it up until now but I'm guessing it's actually pretty useful
 
+Tony Chan when you export an app in release mode, the libraries do get recompiled in release mode too.
 
+Xavier Ducrohet , thanks I probably should haven clarified better. These libraries aren't ones that I've made, they're SDK's/.jar's that I use in my App made by others (like AdWhirl or AdMob). So I can't easily add the "if (BuildConfig.DEBUG)" check around their Log calls. I'm thinking the only solution is using Proguard as Tor suggested. Just need to find some instructions now...
 
+Xavier Ducrohet Yeah, AdWhirl is riddled with it. Definitely useful when debugging, but kind of an eyesore when checking release versions. Plus it might be leaking some info.

+Tor Norbye, thanks I'll try adding those attributes to my proguard file.
 
+Xavier Ducrohet +Tor Norbye , wanted to let you guys know that ProGuard does work for stripping out Log calls. Just tried it and adding:

-assumenosideeffects class android.util.Log {
public static * d(...); }

to the proguard-project.txt file does work to remove Debug level Log calls. You do, however, need to enable optimizing so I followed instructions and copied everything in proguard-android.txt over to proguard-project.txt and changed project.properties to point only to the proguard-project file (while also uncommenting the optimization lines).

Hopefully there will be no conflicts with the dex optimizations you guys have mentioned. And I'd have to remember to copy over changes from future SDK Tools releases.

Some notes: - Stripping out Log calls seems to sometimes throw off line numbers in stack traces. So that might be a little annoying when trying to pinpoint problems.
- Apparently if you have concatenations of Strings in the Log calls, those objects will be left behind because ProGuard isn't yet smart enough to realize they can be removed.

Other than that it seems to work pretty well, even removing Log calls from 3rd party libraries. You guys might want to consider adding it to future ProGuard config files as commented optional lines.
 
Make sure you get r8 of that library, since r7 had a couple of issues
 
Regarding ProGuard, yeah, I wonder if we shouldn't provide two alternate versions (in master), such that you don't have to duplicate the definitions into your project which is what we're trying to get away from.
 
yeah, i was just considering making a duplicate copy (with optimization enabled) in the tools/proguard folder so all my projects could reference it. But of course I would still have to look out for changes to the original when SDK Tools updates come out.
 
+Tony Chan Now that you mention about GridLayout, I wonder what is the reason that it's not open source?
Add a comment...