I'm glad we can finally talk about this.
http://android-developers.blogspot.com/2010/09/more-countries-more-sellers-more-buyers.html
Cheers,
Dan
-
Dan Galpin
Developer Advocate
Google, Inc.
-
If you actually want answers to your questions, it's far better to
post them here, because the collective
Dan,
Thank you for providing some context. I suppose everyone would agree
that this was a missing element. I don't know the number of developers
I can speak for here, but let's say it's a good number... we really
like to maximize the productivity on our projects and minimize the
time we spend on ov
Not to beat a tired horse here, but I thought it might make sense to
explain the genesis of this post.
When we released the License Validator Library, we added the strong
suggestion that developers apply Proguard or some other obfuscator to
their builds when they make use of it. However, we didn't
It's not what developers are too lazy to do. It's what customers are
willing to pay for.
On Sep 27, 9:18 am, Xavier Ducrohet wrote:
> Honestly, if a developer is too lazy to learn how to use proguard then
> he/she shouldn't use it. There are very few things in development when
> you can press a
This is not a trend.
People should use proguard. Many people don't know how, so we made a
blog post to help them. Using LVL really benefit from proguard, so we
feel it was important enough to do it before we had full proguard
support in the tools.
But even with proguard support in the tools you wi
You are refuting a straw man argument. If the documentation is so good
at the Proguard site, then Google's documentation, in particular in
Dan's blog, should have referred to it. It also should have been
written to complement the Proguard documentation, not as it to replace
it. But neither happened
ProGuard has great documentation. Click on the Manual link on the left
at their site:
http://proguard.sourceforge.net/
They even have an example configuration file for Android projects in
the Examples section. It was there a long time before this recent
change by Google to add ProGuard support to
Google people should stop telling people to "go read the source" or
"go read the config file", when others ask for what Google should have
documented.
On Sep 25, 7:15 am, Xavier Ducrohet wrote:
> People should read the blog post Dan posted and read the files that
> comes with it.
>
> one of those
Not sure if anyone has seen it, but this tutorial that I picked up
awhile back has some pretty helpful hits on using Proguard with
Android:
http://www.androidengineer.com/2010/07/optimizing-obfuscating-and-shrinking.html
On Sep 25, 9:45 am, JP wrote:
> Integration in Eclipse - a step in the righ
On Sep 25, 10:08 am, Craigo wrote:
> Java & Eclipse Vs Objective C & Xcode. You decide.
Well yeah for the stuff that's done on the side. Another decision
would to head to the beach because it's such a nice day.
I am referring to professional work though where one would rather not
want to scar
"Regrettably, Android multiplier is considerably greater than iOS's".
Java & Eclipse Vs Objective C & Xcode. You decide.
Sorry, I just couldn't let that comment slide by.
On Sep 25, 11:45 am, JP wrote:
> Integration in Eclipse - a step in the right direction if serious
> about promoting Progu
Integration in Eclipse - a step in the right direction if serious
about promoting Proguard.
It's wait and see for me now. I am too busy with other things to
wanting to figure this one out.
Xavier and crew, two aspects that I'll ask you to keep in mind:
1. There's plenty of developers who need to k
On Sat, Sep 25, 2010 at 5:45 AM, Lance Nanek wrote:
> The most powerful solution would be to just have a file field in the
> project properties for a ProGuard config file to use. I guess since
> people are complaining they can't use Ant, maybe they would complain
> they can't edit config files on
People should read the blog post Dan posted and read the files that
comes with it.
one of those files is the Ant additional rules, the other one is a
proguard config file.
In this file, there are rules to not obfuscate the activity, service,
broadcastreceiver, etc... classes.
For the native metho
Neat idea. An annotation wouldn't work for things in JAR libraries,
however. Back when I tested ProGuard to see if it helped my frame
rates, I had to turn obfuscation off for some classes in JARs I use.
Not sure why, maybe the library used reflection or something. It
wasn't even a weird library, j
That is excellent information. Thank you for posting it.
But there is one thing that surprises me as it is written, so I must
ask for clarification: when you say, "there is no way we can figure it
out programmatically[sic], do you mean that such is the case even when
Proguard is integrated with AD
Thank you so much Xavier!
On Sep 24, 6:00 am, Xavier Ducrohet wrote:
> We are working on direct support in ADT/Ant. We just decided to
> release a quick blog post on how to manually add this to Ant since
> it's somewhat easy to do (unlike ADT).
>
> However, proguard does need to know about which
The options were listed in preference.
I typically use 1 or 2 or sometimes a combo of both.
Option 3 is for when I am feeling very lazy and don't expect many
instance of projects using the same build config, so no payback on
doing 1 or 2.
On Sep 24, 11:56 am, Indicator Veritatis wrote:
> I agre
If I was adding Proguard for the first time then sure I have to solve
the problem.
For that one first time for all my prohjects.
If I had already been using Proguard as part of my release process,
why would it suddenly mess up my release?
Part of a Maven build is to lock down everything using vers
I think for most of us it is just the idea of going from a familiar, known
setup to something new with potential pitfalls that could potentially cause
delay in releasing apps initially. I personally look forward to trying the
build with Ant as I like to customize things, however, it seems that
eve
BTW, I would be interested in hearing the problem people have
switching between Ant and ADT.
We are trying to make sure that one can use both at the same time. I
think it makes sense to use ADT during development but use Ant for
automated builds for instance.
I do realize Ant is much more customi
We are working on direct support in ADT/Ant. We just decided to
release a quick blog post on how to manually add this to Ant since
it's somewhat easy to do (unlike ADT).
However, proguard does need to know about which class to not obfuscate
and there is no way we can figure it out programmatically
Hi,
I'd love to be in a position of being concerned about piracy, LVL,
Progard & obfuscated stack traces.
But alas I'm still one of the many dev's situated in a region
(Australia) were I can buy apps from the Android Market but not
publish a paid app.
This is a big ongoing disincentive and leave
Google has too long a history of stonewalling and foot dragging. You
NEED that kind of 'motivation' -- unless you finally learn to take
responsibility for committing to fix your bugs without such unpleasant
prodding.
When, for example, are you going to fix AAC+ support in StageFright?
When will yo
Xav already posted on this, as someone else pointed out in this thread. (I
am not responsible for tools, so I can't speak to this anyway.)
On Thu, Sep 23, 2010 at 10:39 PM, Stephen Lebed wrote:
> Hi Dianne,
>
> I was one of the people eagerly awaiting to read how to add Proguard
> to my workflo
Hi Dianne,
I was one of the people eagerly awaiting to read how to add Proguard
to my workflow. I'm still learning java and getting used to working
in eclipse. After reading the blog entry, all I could think was,
Wow! This is getting crazy. I was really hoping for some integrated
solution with
On Thu, Sep 23, 2010 at 6:50 PM, Indicator Veritatis wrote:
> But rather than run for the hills, we should pepper Google with
> uncomplimentary speculations concerning their motives for this "turd
> layering" until they 'fess up and give us a release date for a version
> of ADT that will allow us
On Thu, Sep 23, 2010 at 9:00 PM, Justin Giles wrote:
> Xavier stated in another thread that in the next release there will be
> built-in support for proguard in Eclipse. I can't find a link right now,
> but the last discussion on it was earlier today or yesterday.
> Justin
http://groups.google.c
Xavier stated in another thread that in the next release there will be
built-in support for proguard in Eclipse. I can't find a link right now,
but the last discussion on it was earlier today or yesterday.
Justin
On Thu, Sep 23, 2010 at 8:50 PM, Indicator Veritatis wrote:
> It is not just yo
I agree that from the description in his post, it is not really clear
that it gets him "off the hook" at all. But perhaps he was assuming
the reader knows something about maven.
But I am more concerned about his step 3, which sounds like a recipe
for trouble: copying the build. Now how do you main
It is not just you. I was pretty disappointed when I read that post,
too. I did get a kick out of seeing what a menacing appearance Dan has
with his new beard and moustache, though;)
I am amazed that Google seems to think it is acceptable to force the
user to maintain two different build systems -
On Sep 22, 11:53 pm, William Ferguson
wrote:
> But hey, I place higher value than some on those 3 : simple, clear and
> maintainable.
Nice framework, but I don't see how you're "off the hook". Imagine
you're under time pressure to get a release out and you realize
Proguard messes up your releas
On Sep 23, 12:11 am, joebowbeer wrote:
> At face value, the blog entry is responding to those on this list who
> have been asking for help adding Proguard to their build process.
Maybe. With no reference to such requests, the way the post reads, I
get the impression is supposed to become mainst
At face value, the blog entry is responding to those on this list who
have been asking for help adding Proguard to their build process.
Whether Proguard is worth the effort and expense (e.g, maintaining
symbol maps for decoding stack dumps) is another matter. Proguard can
significantly compact and
Personally I dislike the release overhead, but since I only ever need
to wear the cost once for any particular type of build I don't see it
as that onerous over all.
I configure my projects using maven and drop the necessary tools as
plugins into the relevant phase of the build life-cycle.
>From th
35 matches
Mail list logo
