Binding

When binding issues occur, e.g. when the app does not start properly, you need to adapt the rules list to first disable, and then gradually re-enable all bindings.

Using the untouchable or unbind operation will ensure that a matching class, method, or field will not be affected when values are removed during the binding operation. Optionally, the bind operation asks the Shielding Tool to include the specific value in the binding process (which would most likely bind the value regardless).

After shielding, the performance of the application can be impacted at startup. In this case, exclusion options can be defined to reduce the impact of shielding on the application.

The security provided by App Shielding is reduced by excluding classes from the shielding process. The number of bindings must be high enough to ensure security requirements (more than 2,000 push/pull bindings).

Since certain parts of the app code need to run for App Shielding to be launched, the shielding process will automatically trace and mark the relevant parts as untouchable: they cannot be modified in any way.

By default, the <clinit> class initializers, all variables, and method calls called from these are marked as untouchable. In some cases, however, tracing is not possible because the method call flow cannot be determined. Issues may occur especially with code reflection or provider classes in the Android manifest.

For these cases, a generic way to exclude classes and methods in a declarative manner is available so that the shielding process will not modify them in any way by marking them as untouchable.

Adjust the rules list

In the rules list, you need to specify how App Shielding will modify your app in the context of binding. The rules list is located on the Configuration Page of the OneSpan Customer Portal or the OneSpan Mobile Portal.

To modify the rules list

1. In a web browser, go to the OneSpan Customer Portal or OneSpan Mobile Portal and sign in.

2. Select the configuration for which you need to adjust the rules list.

3. Under Settings, add, edit, or remove exclusion rules as needed.

For more information about options and commands to adjust the rules list, see Configuration of Shielding Tool rules.

Additional considerations

• If the application terminates unexpectedly during startup, it may be useful to attempt to run the application without any form of binding first.

  untouchable *;

  If the application can be started, try to identify the class, method, or field that is causing the problem.

• In the event of general binding problems, you will get an exception and stack trace in the log. This message may vary significantly from case to case, depending on the cause, but always includes ClassNotFoundException.

  D/dalvikvm( 6367): Added shared lib 
  /data/data/com.example.mytestapp/files/libshield.png 0 ← x4273ffb0

  In this case, App Shielding is loaded as a library by the runtime, and the process ID is 6367.

  Now, you need to locate messages related to the same process ID, for example:

  W/dalvikvm( 6367): Exception Ljava/lang/NullPointerException; thrown while
  initializing ← Lcom/example/mytestapp/BadClass;
  I/dalvikvm( 6367): Rejecting re-init on previously-failed class
  Lcom/example/mytestapp/ ← BadClass; v=0x0

  From this message, it is clear that Dalvik attempted to initialize the class BadClass, but failed due to a NullPointerException.

  untouchable class com.example.mytestapp.BadClass;