My experience with LVL and the precedence it sets

by Zsolt Vasvari » Thu, 29 Jul 2010 07:46:01 GMT

Sponsored Links
 I just tried integrating LVL into my app.  Some comments on this

I have my project set up so that compiler Errors/Warnings are almost
all set to Error level.  When I imported the LVL project, I got all
kinds of errors.  Mostly missing "this" qualifiers and $NON-NLS tags,
but some of the errors I saw quite interesting.  Apparently, whoever
wrote ServerManagedPolicy doesn't have a clear understanding of the
differences between a "long" primitive, a "Long" obejct and its string
representation.  There was also a superflous import of
java.lang.String (WTF?, that's first week Java).

Anyhow, I changed the project settings to ignore the errors.  That
worked fine until I added the library to my own project.  All the
errors came back.  It seems that library project uses the settings
from the main project and not the library project.  At this point, I
had no choice, but to fix up all the errors in LVL as I was not ready
to lower the warning levels in my app.

So, going forward, is it possible so that the library's warning
settings take precedence?  Since, I am guessing the answer is a no, is
it possible that Google makes sure that any code supposed to be
compiled by every developer does so with the warning levels set to the
strictest possible?  It is unreasonable expect that every developer
change their project for the LVL and any upcoming libraries.

By the way, is there a technical reason why LVL cannot be shipped as a
JAR?  Do you see the developers modifing the LVL code?


My experience with LVL and the precedence it sets

by Xavier Ducrohet » Thu, 29 Jul 2010 08:38:24 GMT


$NON-NLS is something specific to Eclipse that we do not use in Android.
Our convention for the android source code do not enforce the use of
this qualifier.

As for importing java.lang.String, those 2 files have been created
automatically by aidl (see the files in aidl/) and the tool doesn't
care about unneeded imports and automatically put import statements
for all the used classes.

The issue is that the library code is compiled by the main project so
the settings of the library projects are useless. This is not going to

Yes and no.

Yes because, at this time, the library is only code, with no
resources, so you could generate a jar file.

However we decided to provide it the way we do because:
- we wanted to give the source code (btw, we recommend that you copy
it somewhere else before you edit it and link to it)
- and we expect you to change it (to have your own implementations for
the Policy and Obfuscator), so providing a jar file was pointless
since you'd have to regenerate it anyway.
- We have the library mechanism. In the future it'll do Manifest
merging, so you'll even get more benefit from it.

Xavier Ducrohet
Android SDK Tech Lead
Google Inc.

Please do not send me questions directly. Thanks!


Sponsored Links

My experience with LVL and the precedence it sets

by Zsolt Vasvari » Thu, 29 Jul 2010 09:02:53 GMT

 Thanks for your answer, Xavier.

Ok, fair comment about the java.lang.String import.  That said, since
you are recommending to use Eclipse as the development environment, I
think it would be benefitial for everybody if a few minutes taken
before release to make sure it compiles with any possible settings the
user may have in their Eclipse project.  If that means cleaning up the
generated code, I believe that should be undertaken.  Otherwise you
will end up with aggrevated users.

Do you honestly expect the user having to modify their project warning
levels to be able to successfully integrate LVL?  Perhaphs the answer
is yes, but then it should be documented and spelt out how warning
levels need to be set for the project.


My experience with LVL and the precedence it sets

by Mark Carter » Thu, 29 Jul 2010 15:06:50 GMT

 I believe I'm using the default eclipse compiler warning settings and
I got a bunch of "unused import/instance variable" warnings in my
workspace when adding the LVL project. Furthermore, all the warnings
were doubled up - once for the library project at the top level and
once for the library project as a child node of my own project.

Since changing the project warning settings was not an option, I
solved this by adding @SuppressWarnings annotation at the class level
of a couple of the LVL classes. But this is far from ideal as it
requires modifying the code (which I will later want to update as new
versions are released).

Another problem was that when I changed the LVL code (saving the
changes), my main project required a "Clean" before it picked up the
changes. It would be nice if library project changes triggered clean
to all downstream projects (I think this is how things normally work).
This problem might have been caused by me editing files in the top
level LVL project rather than the child LVL node. Again (mentioned
last month in another thread), this is a problem where the same class
can appear twice in the workspace (once for the top level, once for
the child level).

The easiest solution to this would be to NOT make the LVL child node
browsable. So forcing the dev to do everything through the top level
project. Also trigger the Cleans accordingly.

One final point about the LVL code.... I wanted to subclass
ServerManagerPolicy but had to make a bunch of instance fields
protected to do so. Would be great if they were already protected.

Also, ResponseData is package private. This prevents devs from
implementing their own Policy in their own package. Since I wanted to
make only minimal changes the the LVL project, I just included my
Policy class in a "" package within my
main project instead. Still, would prefer to use my own package


My experience with LVL and the precedence it sets

by andrew android » Sat, 31 Jul 2010 02:23:03 GMT

  just started using the LVL also.  I had problems adding a reference
to the LVL project (I kept getting manifest errors immediately upon
adding the reference) so I just added it directly. Then, I tried to
buile the sample code into my project but I find it all very
"clunky". I think it is absurd to not take the time to build methods
and properties that automatically can set obfuscation properties,
obtain device Id, make a call to do the validation and such. Having
source code is mice but they really should have made this quicker to
implement with the option to customize and do more with it or to not
and take a simpler approach. I was so looking forward to using this
but am sorely disappointed. There is a competing android market with
a much better licensing implementation, by the way.

On Jul 29, 2:06am, Mark Carter <> wrote:


My experience with LVL and the precedence it sets

by Krischik Martin » Sun, 01 Aug 2010 13:04:56 GMT


Heretic question: Import is optional so why import at all?

Note that the usual argument pro import apply to humans but are of no
concern to a code generator.



Other Threads

1. Contacts Listener

Hi Guys,

I'm new in Android development, but I need to write a listener for
contacts app. The draft logic is: when user changes, adds or deletes a
contact I should get an event-notification.
How can I do this?

Thanks in advance.

2. Another Local Service issue

any suggestion?


3. Top 10 Anti Virus Kaspersky Internet Security Free Download

4. R: R: Android on Nokia E90

5. PC Restarts

6. Can I save a Serializable object to SQLite datastorage.

7. ant build fail