what exact exceptions do you have ? without this information we can't answer. apart from that, our goal as always been to be able to convert all valid .class files into .dex files.
note that some obfuscation programs do things like injecting dynamic class-loading method lookups of bytecode programs stored in constant byte arrays. this is not supported at the moment by the VM (though the dex convertion tool will generate valid .dex files) On Thu, Jul 10, 2008 at 6:00 AM, tellme <[EMAIL PROTECTED]> wrote: > > The optimizations FAQ in ProGuard's doc: > > What kind of optimizations does ProGuard support? > Apart from removing unused classes, fields, and methods in the > shrinking step, ProGuard can also perform optimizations at the > bytecode level, inside methods. Thanks to techniques like control flow > analysis, data flow analysis, partial evaluation, and liveness > analysis, ProGuard can: > Evaluate constant expressions. > Remove unnecessary field accesses and method calls. > Remove unnecessary branches. > Remove unnecessary comparisons and instanceof tests. > Remove unused code blocks. > Merge identical code blocks. > Reduce variable allocation. > Remove write-only fields and unused method parameters. > Inline constant fields, method parameters, and return values. > Inline methods that are short or only called once. > Make methods private, static, and final when possible. > Make classes static and final when possible. > Replace interfaces that have single implementations. > Perform over 200 peephole optimizations, like replacing ...*2 > by ...<<1. > Optionally remove logging code. > The positive effects of these optimizations will depend on your code > and on the virtual machine on which the code is executed. Simple > virtual machines may benefit more than advanced virtual machines with > sophisticated JIT compilers. At the very least, your bytecode may > become a bit smaller. > Some notable optimizations that aren't supported yet: > > Moving constant expressions out of loops. > Optimizations that require escape analysis. > > > On 7月10日, 上午11时56分, tellme <[EMAIL PROTECTED]> wrote: > > A discussion from the ProGuard's forum: > > > > ================================================= > > > > We have a question on the ProGuard's "dontoptimize" option. > > According to the ProGuard's doc's description, > > "-dontoptimize > > Specifies not to optimize the input class files. > > By default, optimization is enabled; all methods are optimized at a > > bytecode level. " > > > > Our understanding is that by default when the optimization option is > > on, all methods are optimized utilizing some specific properties of > > conventional JVM. > > > > Our questions are, > > 1. What properties of the conventional JVM are exploited? > > 2. How to optimze the bytecode aligned with those properties? > > > > The reason that we ask those questions is that, when we obfuscate Java > > bytecode, then convert it into Google/Android dex file, exceptions are > > thrown, saying some convertion doesn't work properly. > > However, after we put on the "dontoptimze" option, the convertion > > works fine. > > > > Very curious what happens under the surface. > > > > RE: A question on the "dontoptimize" option. (New) > > By: Eric Lafortune (lafortuneProject Admin) - 2008-07-09 01:16 > > The optimizations are listed in the ProGuard FAQ, question #4. > > There are many different types of optimizations, but the output should > > always be valid bytecode. If the code works in a JVM, but not with > > Android, it's most likely a bug in the Android tool. If the code also > > fails in a JVM, you should provide some more details, so I can > > investigate. > > > > Eric. > > > > ==================================== > > What do you think about Eric's " If the code works in a JVM, but not > > with Android, it's most likely a bug in the Android tool"?? The > > android tool here should be dx tool. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
