Removal
Removal is the process by which PreEmptive Protection™ DashO™ removes unused code from your application, and encompasses several distinct features:
- Removing unused classes and members
- Removing attributes generated by the compiler
- Removing specific classes explicitly
Note: In Android Mode, DashO expects removal to be handled by R8 and DashO's removal is unavailable. Ensure that you enable R8 when using Android Mode.
Removing Unused Classes and Members
DashO's Removal analyzes your code to find unused classes, methods, and fields and removes them.
On the Removal - Options page, you can choose to remove all unused classes, remove only non-public
unused classes, or to not remove unused classes at all.
Similarly, you can choose to remove all unused members, remove only non-public
unused members, or not to remove unused members at all.
DashO will follow Entry Points to determine which classes and members are used and will treat unencountered classes and members as unused.
Removing all unused classes, methods, and fields is usually appropriate for applications. Removing unused non-public classes and members may be more appropriate for libraries with public APIs, although you can accomplish this goal through the use of Library Entry Points instead.
Exclusions
You can exclude classes and members from removal on the Removal - Exclude page of the DashO GUI.
Reflection
If a class or member is only accessed via reflection, then DashO cannot necessarily determine that it was used. Checking "Determine Reflected Classes" on the Input - Options page will cause DashO to attempt to find simple reflection based access to classes during renaming and removal analysis. It is generally more reliable to add classes and members accessed only via reflection as Entry Points, or to exclude them from removal.
Note: DashO cannot detect reflection-based access of methods or fields.
See Dynamic Class Loading for more details on detecting reflection.
Removing Attributes
DashO can remove debug information and other unnecessary attributes from your code. Removing unnecessary classes, methods, fields, debug information, etc. can both reduce the size of your application and help protect it; some debug attributes and other compiler generated attributes provide information that could give attackers additional insight into your application. You can configure which attributes DashO will remove on the Removal - Options page of the DashO GUI.
Debug Information
DashO can remove the following Debug Information:
Friendly Name (Used in GUI) | Attribute Name (used in project file) | Description |
---|---|---|
Source File | SourceFile |
The name of the file containing the source code for a given class. |
Source Directory | SourceDir |
Contains information about the directory containing the Source File. (Uncommon) |
Source Debug Extension | SourceDebugExtension |
Contains extended debug information; considered tool-specific. |
Line Number Table | LineNumberTable |
Describes a relationship between bytecode instructions and line numbers in the original source file. |
Local Variables | LocalVariableTable |
Describes the names and types of local variables during the execution of a method. |
Local Variable Types | LocalVariableTypeTable |
Describes the type parameters of local variables with generic types. |
Most of this information is used primarily by debuggers, but the most useful to retain are the Line Number Table
and the Source File
.
If you would like to generate stack traces with meaningful line numbers, then these two should be retained.
Variable names in the LocalVariableTable
attribute and the LocalVariableTypeTable
attribute are not renamed.
Leaving these attributes in a production release reduce the effectiveness of protection.
Control Flow will remove most of this information regardless of this configuration.
Additional Attributes
The Java compiler generates additional metadata for classes and their members and stores that information in attributes in the class files. Some of this information is required by the compiler when you compile against a library, or by applications using reflection. You can use these settings to selectively remove information that your application does not require at runtime to reduce the size of your class files. Some of this information may also provide insight into your software to an attacker, so removing it may enhance protection.
Friendly Name (Used in GUI) | Attribute Name (used in project file) | Description |
---|---|---|
Exceptions | Exceptions |
Indicates which checked exceptions a method may throw. |
Signature | Signature |
Describes the signature for a class, method, field, etc. that takes type parameters or uses a parameterized type. |
Deprecated | Deprecated |
Indicates that the class, interface, method, or field has been superseded. |
Synthetic | Synthetic |
Indicates that a class member does not appear in source code. |
Enclosing Method | EnclosingMethod |
Indicates the enclosing method for an anonymous class. |
Inner Classes | InnerClasses |
Indicates relationships between inner and outer classes. |
Visible Annotations | RuntimeVisibleAnnotations |
Holds the annotations on a class, method, or field that are visible with reflection (e.g. @Deprecated , @FunctionalInterface , @SafeVarargs ). |
Invisible Annotations | RuntimeInvisibleAnnotations |
Holds the annotations on a class, method, or field that are not visible with reflection. |
Visible Parameter Annotations | RuntimeVisibleParameterAnnotations |
Holds the annotations on the parameters to a method that are visible with reflection. |
Invisible Parameter Annotations | RuntimeInvisibleParameterAnnotations |
Holds the annotations on the parameters to a method that are not visible with reflection. |
Annotation Default | AnnotationDefault |
Default values for annotation elements. |
Method Parameters | MethodParameters |
Holds the names of the method's parameters. |
"Unknown Attributes" (Unknown
in the project file) covers all other attribute types.
Note: Type Annotations will always be removed. This behavior is hard coded and cannot be disabled.
Removing Classes
If your inputs contain classes that you do not want to appear in the resulting output, such as unit tests or samples, you can configure DashO to remove those classes altogether. You can configure classes to be removed on the Removal - Classes page of the DashO GUI.
Note: Use this feature carefully. If any input's classes reference the removed classes, the application may fail at runtime because it will not be able to find the class that was removed.