Skip to main content

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:

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, you request production deployment and Q2 handles the release.

Key Activities:

  1. Submit SDK Deployment Request - Notify Q2 through q2developer.com that testing is complete
  2. Q2 merges to production branch:
    • FIs: Q2 handles merge internally
    • Partners: Submit MR from master to production, Q2 approves
  3. CI generates production artifact (automatic)
  4. Q2 creates release tag and makes module available

Result:

  • Module is now available for production Q2 Mobile Applications
  • Listed in Q2 developer catalog (for partners)
  • Ready for inclusion in FI builds

For detailed instructions:

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

PhaseWhoWhat Happens
DevelopmentPartner/FICreate branch, develop in DevApp, test locally
Merge RequestPartner/FICreate MR to master, submit support ticket
Code ReviewQ2Review code, provide feedback or approve
Test BuildQ2Merge to master, CI generates test artifact, Q2 creates test build
TestingPartner/FITest the build with obfuscation/signing/integration
Deployment RequestPartner/FISubmit SDK Deployment Request
Production ReleaseQ2Merge to production, CI generates production artifact, create release tag
Done-Module available for production use

Additional Resources

Workflow Guides

Other Resources

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.