Skip to main content

Android - Considerations and Unsupported Features

This document outlines practices and features that are not supported, permitted, or recommended when integrating with the Q2 Mobile Android SDK. Adhering to these guidelines is crucial for ensuring compatibility, stability, and optimal performance of your application within the Q2 Mobile Banking and Mobile App ecosystem.

Failure to follow these guidelines may result in:

  • Unexpected application behavior or crashes.
  • Reduced performance.
  • Inability to leverage future SDK updates.
  • Rejection of your application from the Q2 Mobile Banking and Mobile App ecosystem.

1. Data Binding (Android Data Binding Library)​

The use of the Android Data Binding Library is explicitly NOT supported with the Q2 Mobile Android SDK.

Our SDK's architecture and internal implementations are not compatible with the way the Data Binding Library processes and generates code. Attempting to use data binding in modules or activities that integrate directly with our SDK components can lead to:

  • Runtime crashes (e.g., ClassCastException, NoClassDefFoundError).
  • Incorrect UI rendering.
  • Memory leaks.
  • Unpredictable behavior.

Recommendation: Please use traditional findViewById() or View Binding (if applicable and within your project's scope, ensuring it doesn't interfere with SDK views) for UI element manipulation when interacting with any part of your application that utilizes the Q2 Mobile SDK.

2. Direct Manipulation of SDK Internal Views/Layouts​

Do NOT attempt to directly access or modify the internal views, layouts, or hierarchies of any components provided by the Q2 Mobile SDK.

Our SDK's UI components are designed to be self-contained and manage their own internal state and rendering. Directly manipulating these elements can:

  • Break the intended functionality and user experience.
  • Lead to visual glitches or rendering issues.
  • Cause unexpected crashes.
  • Prevent future SDK updates from being applied correctly.

Recommendation: Interact with SDK components only through the public APIs and methods provided in our documentation.

3. Reflective Access to Private SDK Members​

Do NOT use Java Reflection to access or modify private classes, methods, or fields within the Q2 Mobile SDK.

Our SDK's internal implementation details are subject to change without notice in future updates. Relying on reflective access creates a brittle integration that will likely break with subsequent SDK versions, leading to:

  • NoSuchMethodException or NoSuchFieldException at runtime.
  • Inconsistent behavior.
  • Security vulnerabilities.

Recommendation: Only use the public APIs and interfaces exposed by the SDK. We are committed to providing a stable and well-documented public API for all supported functionalities.

4. Modifying SDK Resources (e.g., Drawables, Strings, Layouts)​

Do NOT directly modify or override the resource files (drawables, strings, layouts, etc.) embedded within the Q2 Mobile SDK AAR.

Overriding SDK resources at the project level can lead to:

  • Conflicts with future SDK updates.
  • Inconsistent UI across different app versions.
  • Unexpected visual defects.

Recommendation: If customization of certain visual aspects is desired, please contact us first to discuss what is acceptable.

5. Non-Standard Android Lifecycle Management​

Do NOT implement non-standard or unconventional Android Activity/Fragment lifecycle management that deviates significantly from Android best practices, especially for Activities/Fragments hosting SDK components.

Our SDK relies on standard Android lifecycle callbacks (e.g., onCreate(), onStart(), onResume(), onPause(), onStop(), onDestroy()) to manage its internal state, network connections, and resources. Deviating from these can cause:

  • Memory leaks.
  • Background processes not being properly stopped or resumed.
  • Incorrect data persistence.
  • Crashes related to invalid states.

Recommendation: Ensure your Activities and Fragments that interact with the SDK follow the standard Android lifecycle paradigms.

6. Tampering with Network Requests Initiated by the SDK​

Do NOT attempt to intercept, modify, or block network requests initiated internally by the Q2 Mobile SDK without explicit documentation or support.

The SDK communicates with backend services essential for its functionality and security. Interfering with these requests can:

  • Prevent the SDK from functioning correctly.
  • Compromise data integrity or security.
  • Lead to unexpected errors or timeouts.

Recommendation: If your application requires network-related considerations (e.g., proxy configurations, custom SSL pinining for your application's network calls), ensure they do not inadvertently affect the SDK's internal network communication. Consult our documentation for any supported network configuration options related to the SDK.

7. Using Obsolete Android API Levels or Dependencies​

Do NOT integrate the SDK with applications targeting significantly older or obsolete Android API levels that are no longer supported by Google.

While we strive for broad compatibility, integrating with severely outdated Android versions can lead to:

  • Security vulnerabilities.
  • Performance issues.
  • Compatibility problems with modern Android features.
  • Inability to use the latest features and bug fixes of the SDK.

Recommendation: Always aim to target a modern and actively supported Android API level. Refer to the "System Requirements" section of our documentation for the minimum supported Android API level and recommended target SDK version. Ensure all your project dependencies are up-to-date and compatible with the SDK's requirements.

8. Enabling ProGuard/R8 Obfuscation on SDK Classes Without Configuration​

Do NOT apply ProGuard or R8 obfuscation and shrinking to the Q2 Mobile SDK's classes without including the necessary keep rules provided by us.

Obfuscating the SDK's internal classes can lead to:

  • ClassNotFoundException or NoSuchMethodException at runtime.
  • Broken functionality.
  • Difficult-to-diagnose crashes.

Recommendation: Always include the provided ProGuard/R8 rules in your proguard-rules.pro file when building a release version of your application. These rules ensure that the SDK's essential classes and methods are preserved. Refer to the "ProGuard/R8 Configuration" section of our documentation.

9. Dependency Version Management​

Always utilize the dependency versions specified in the provided Version Catalog for all Q2 Mobile SDK-related modules and components.

Our Version Catalog ensures compatibility, stability, and optimal performance across your application and our ecosystem. It is meticulously tested to prevent conflicts and ensure a smooth integration experience.

For any dependencies you require that are not included in our Version Catalog, it is your responsibility to:

  • Select the latest stable and secure versions.
  • Prioritize actively maintained libraries and avoid those that are deprecated or no longer supported.
  • Thoroughly test any newly introduced dependencies to ensure they do not introduce conflicts or instability.
  • We reserve the right to reject application modules that incorporate significantly outdated or deprecated third-party dependencies, as they can pose security risks, introduce instability, and hinder our ability to provide ongoing support and updates within the Q2 Mobile Banking and Mobile App ecosystem.

By adhering to these guidelines, you can ensure a smooth and stable integration of the Q2 Mobile Android SDK into your mobile banking applications. If you have any doubts or encounter situations not covered by this document, please reach out to our support team for clarification.