Change Log – Version 7.0.0 – Release Date February 4, 2013
The 7.0 release includes a variety of enhancements and fixes, including one enhancement that introduces backwards-incompatibilities in certain build scenarios. Please read this document carefully before upgrading, and refer to this summary, the user guide, or our support options if you encounter any issues.
Improved reporting of errors and warnings
This version of DashO introduces a consistent set of rules and behaviors for reporting build-time issues, which will make it easier to integrate DashO into an automated build process, and will improve the accuracy of the build results. Specifically:
- DashO builds can now be configured to halt as soon as any error is encountered, rather than trying to proceed with the rest of the build, via the HALTONFIRSTERROR option. (The default behavior is still to try to continue, to facilitate debugging.)
- The exit code of DashO and/or the <dasho> Ant task will indicate the number of errors (up to 255) encountered before the build halted or completed. Before, the exit code would always be 0 (meaning “success”), even after an error, unless the build was unable to complete. You can configure DashO to use the old exit-code behavior via a project-specific setting. (“Use exit behavior from DashO 6.x and earlier” UI checkbox or “PRE_7_0_EXIT_BEHAVIOR” project file setting).
- Error output will always be on STDERR; before this release errors were logged to STDOUT. Warnings will continue to be logged to STDOUT. (The UI will continue to show all output within the UI.)
- Some Errors and Warnings were converted to Fatal Errors (i.e. the build halts immediately). For example, if a map file for String Encryption was specified, but can’t be found at build time, the build will halt immediately and report an Error.
- Many Warnings have been converted to Errors. In general we are treating any condition in which the project file instructed DashO to take some action, but it was unable to take that specific action, as an Error. Most of these changes were in the instrumentation features, and cover cases where a required field was missing for a given message type. Some of these changes affect all parts of the build, such as when an input file is specified in the project but is missing from the filesystem.
The combination of these changes can result in builds that fail where they didn’t before, e.g. if a previously-reported Error wasn’t causing a non-zero exit code, or if a Warning was converted to an Error and now causes a non-zero exit code. In general, we suggest you investigate any errors reported by DashO 7.0 and see if they are truly issues with your build; if so, fixing them may be the best course of action. If you feel that they are not truly errors, or that they are not worth fixing right away, you can use the “Use exit behavior from DashO 6.x and earlier” checkbox or the PRE_7_0_EXIT_BEHAVIOR project file setting to get the old exit behavior. (Please also notify support if you believe the error is not truly an error.)
Other Enhancements
- It is now possible to provide custom implementations of the encryption/decryption methods for String Encryption. (Not recommended in most situations.)
- Added a BYPASSDASHO option to make it easier to “turn off” DashO processing (i.e. obfuscation and/or instrumentation) but still have DashO copy the inputs to the output location
- The input class list now automatically refreshes when adding or removing inputs.
- Made installer improvements and fixed a minor bug to provide full support for Windows 8 as a runtime platform for DashO.
- The Android project wizard now identifies Fragments as entry points, and does a better job identifying entry points on custom views.
- Build run from the UI will now run much faster (i.e. the same speed as builds run from the command line or Ant).
- Added a code sample to demonstrate instrumentation (for PreEmptive Analytics) of Android applications.
- Internal annotations can now be renamed.
Fixes
- The values of class or enum attributes used in Annotations are renamed to match the renamed class or enum.
- Interface methods which are not called directly on the interface but are called on implementing classes will not be removed.
- The LocalVariableTable and LocalVariableTypeTable debug attributes are now kept when requested (except for methods affected by control flow obfuscation).
- The obfuscate ant task now supports the following attributes and elements:
- The <methodcallremoval> element inside <obfuscate>
- The <attributes> element inside <removal>
- The path attribute on <report>
- The sendMessages, supportOffline, and fullData attributes on <instrumentation>
- Using private methods in Android for sources or actions from Runtime Intelligence will no longer generate Verify Errors on the Android device
- Fixed an exception when re-writing classes modified by Aspect4J.
- Android runtime intelligence no longer uses the current thread to determine the information needed for ApplicationStart. The android.os.StrictMode.ThreadPolicy can prevent retrieving host information if the application starts on the UI thread.
- Fixed an issue with obfuscation of projects located on network drives referenced by UNC paths.
- Fixed an issue launching DashO on Windows XP.
- Unchecking ‘Selects Class’ inside a renaming exclusion rule works properly again.
- The “ris.log.messages” system property is supported when testing Java applications.
- Unchecking ‘Rename-Members’ for an Android special class type properly turns off method renaming.
- Fixed character encoding in XML documents.
