Android - Development Workflow

This guide provides a comprehensive overview of the development and release workflow for Q2 Mobile SDK modules on Android. It walks through each step from initial development to production release, explaining what partners/FIs do and what Q2 handles in the process.

Workflow Overview

The following diagram illustrates the complete development and release workflow:

Detailed Workflow Steps

1. Local Development Phase

During this phase, you develop and test your module locally before submitting for Q2 review.

Key Activities:

1. Create a feature branch from master
2. Develop your module using the DevApp tool
3. Test locally - Verify all functionality works in DevApp
4. Test with obfuscation - Enable minify and test with R8/ProGuard (critical!)
5. Commit and push your changes

danger

Critical: ProGuard Testing Required

Before submitting your merge request, you must test your module with R8/ProGuard obfuscation enabled. Without proper testing and consumer rules, your module will crash in production builds.

See Consumer ProGuard Rules for complete testing instructions.

For complete local development guidance:

See Local Development for detailed step-by-step instructions on:

• Creating branches and development workflow
• Using DevApp for testing
• Creating and testing ProGuard consumer rules
• Handling third-party libraries
• Troubleshooting common issues
• Best practices for security, performance, and maintainability

2. Merge Request & Q2 Review

Once local development and testing are complete, you submit your code for Q2 review.

Key Activities:

1. Create Merge Request - Push your branch and create an MR from your branch to master
2. Submit Support Ticket - Notify Q2 through q2developer.com with:
   • Link to your merge request
   • Summary of changes
   • Testing environment preference (Sandbox/SDX/PTE)
   • Any module data {} configuration changes

warning

Module Data Configuration

Settings.json from DevApp is not automatically copied to test/production builds. Include any data {} changes in your ticket.

1. Q2 Reviews - Q2 reviews for security, safety, and stability issues (not code quality)
2. Feedback Loop - If issues are found, fix in your branch, push updates, notify Q2, repeat
3. Approval & Merge - Q2 merges to master when approved

For detailed guidance:

• Submitting Support Tickets - Ticket templates, required information, and examples
• Code Review Process - What Q2 reviews and what's your responsibility

3. Test Build Phase

After Q2 approves and merges to master, the CI pipeline automatically generates a test artifact and Q2 creates a test build for you.

What Happens (Automatic):

1. CI builds your module with test configurations
2. Test artifact generated and stored in package registry
3. Q2 creates test build pointing to Sandbox/SDX/PTE (based on your ticket)

Your Testing:

You receive the test build and thoroughly test your module's functionality.

important

Why This Testing Is Critical

Even though you tested locally, the test build uses:

• Production CI/CD pipeline - Same process as production
• R8/ProGuard obfuscation - May reveal issues not caught locally
• Production-like signing - Tests the full build process
• Full app integration - Your module with the complete Q2 Mobile Application
• Real backend environment - Sandbox/SDX/PTE instead of local DevApp

Issues not seen locally often surface here.

If Issues Found:

• Fix in your feature branch → Create new MR to master → Repeat review cycle

If Testing Successful:

• Proceed to production deployment request

4. Production Release

After successful test build validation, the partner or FI notifies Q2 that the module is ready for production. Q2 handles the release, then the FI submits a deployment request to include the module in their build.

Key Activities:

1. Partner/FI notifies Q2 that testing is complete and the module is ready for production
2. Q2 merges master to production branch and CI generates the production artifact (automatic)
3. Q2 creates release tag and notifies the partner/FI that the module is released
4. FI submits a deployment request specifying the module and its configuration data

note

Who Submits the Deployment Request?

Only the FI can submit a deployment request — partners cannot submit this directly. If you are a partner, coordinate with your FI to submit the request once Q2 has confirmed the module is released.

The deployment request must include the correct module data configuration. See Configuring settings.json for the module data fields required.

Result:

• Module is active in the FI's production Q2 Mobile Application

Branch Structure

The repository uses a protected branch structure:

• master branch: Protected branch used for certification builds

  • All development merges here first
  • Test artifacts are generated from this branch
  • Requires Q2 approval to merge

• production branch: Protected branch used for production builds

  • Only receives merges from master
  • Production artifacts are generated from this branch
  • Represents released, production-ready code

• Feature branches: Your development branches

  • Can use any naming convention
  • Created from and merged back to master
  • Flexible for your team's workflow

Summary

Phase	Who	What Happens
Development	Partner/FI	Create branch, develop in DevApp, test locally
Merge Request	Partner/FI	Create MR to master, submit support ticket
Code Review	Q2	Review code, provide feedback or approve
Test Build	Q2	Merge to master, CI generates test artifact, Q2 creates test build
Testing	Partner/FI	Test the build with obfuscation/signing/integration
Production Release	Q2	Merge to production, CI generates production artifact, create release tag, notify partner/FI
Deployment Request	FI	FI submits deployment request with module data; partner coordinates with FI if needed
Done	-	Module active in production

Additional Resources

Workflow Guides

• Local Development - Detailed guide for day-to-day development
• Submitting Support Tickets - Detailed ticket submission guide
• Consumer ProGuard Rules - Creating and testing obfuscation rules (required)
• Third-Party Libraries - Submitting private libraries for Q2 hosting

Other Resources

• Code Review Process - What Q2 reviews and your responsibilities
• Android Publishing Overview - High-level publishing information
• DevApp Setup - Setting up the Q2DevApp tool

FAQ

Can I merge directly to production?

No, all changes must go through master first. This ensures proper testing and review before production release.

What if I need to make changes after merging to master?

Create a new branch from master, make your changes, and submit a new merge request to master. Once approved, a new test build will be generated.

How long does the review process take?

Review times vary based on the complexity of changes and current queue. Most reviews are completed within a few business days.

Can I test with a different environment?

Yes, specify your preferred environment (Sandbox/SDX/PTE) in your support ticket when requesting the test build.