Android - Submitting Support Tickets

This guide explains how to submit support tickets through q2developer.com for various stages of the mobile SDK development and release process.

When to Submit Tickets

Submit support tickets through q2developer.com in the following scenarios:

1. Merge Request Ready for Review - When you've created a merge request and need Q2 to review your code
2. SDK Deployment Request - When testing is complete and you're ready to deploy to production
3. General Support - For questions, issues, or assistance during development

Ticket Submission Process

Access the Ticket System

Navigate to q2developer.com and access the support ticket creation page:

• Create Support Ticket - General

Required Account

• You must have a q2developer.com account to submit tickets
• If you don't have an account, contact your Q2 representative to get access

Ticket Types

1. Merge Request Review Ticket

Submit this ticket when your merge request is ready for Q2 review.

When to Submit:

• After creating a merge request from your branch to master
• When all local testing is complete
• Before Q2 begins the code review

Required Information:

Field	Value
Summary	[Android] Review | module-name | MR#
Product	Mobile SDK
Description	Include the following details:

Description Details:

Merge Request Link: [URL to your GitLab merge request]

Summary of Changes:
- [Brief bullet point summary of what changed]
- [Any new features, bug fixes, or improvements]
- [Dependencies added or updated]

Testing Environment Preference:
[Specify: Sandbox / SDX / PTE]

Module Data Configuration Changes (if applicable):
[If you've modified the data {} JSON structure in settings.json, include the
updated structure here]
[Explain what changed: new fields, removed fields, changed types]
[Provide default values to use for testing]

Additional Notes:
[Any special considerations or testing instructions]

warning

Important: Module Data Configuration

Your DevApp's settings.json file contains a data {} section for your module that provides configuration at build time. This configuration is not automatically copied to test or production builds.

If you've made changes to your module's data {} structure, you must include:

• The complete updated data {} JSON
• Explanation of what changed
• Default/test values to use

Failing to include this information may cause your module to fail or behave incorrectly in the test build.

Example:

Summary: [Android] Review | acme-payments | MR#123

Description:
Merge Request Link: https://code.q2developer.com/Q2Antilles/acme-stack/android/acme-payments/-/merge_requests/5

Summary of Changes:
- Added support for biometric authentication in payment flow
- Fixed crash when device locale is not English
- Updated payment confirmation screen UI
- Updated OkHttp dependency to version 4.12.0

Testing Environment Preference: SDX

Module Data Configuration Changes:
The module data structure has been updated to support the new biometric authentication feature:

"data": {
  "apiEndpoint": "https://api.acme.com/payments/v2",
  "timeout": 30000,
  "enableBiometrics": true,
  "biometricConfig": {
    "allowFingerprint": true,
    "allowFaceRecognition": true,
    "promptMessage": "Authenticate to complete payment"
  },
  "maxRetryAttempts": 3
}

Changes:
- Added "enableBiometrics" flag (boolean) - set to true for testing
- Added "biometricConfig" object with authentication settings
- Added "maxRetryAttempts" field (integer) - set to 3 for testing
- Updated "apiEndpoint" to use v2 API

Please use these values for the test build configuration.

Additional Notes:
Please test with both fingerprint and face recognition if possible.
Biometric flow can be tested using the "Make Payment" feature in the app.

2. SDK Deployment Request Ticket

Submit this ticket when you're ready to deploy your module to production.

When to Submit:

• After successfully testing the test build provided by Q2
• When you're confident the module is ready for production use
• Before Q2 merges to the production branch

Required Information:

Field	Value
Summary	[Android] Deploy | module-name | version
Product	Mobile SDK
Description	Include the following details:

Description Details:

Module Name: [Your module repository name]
Version: [Semantic version number, e.g., 1.2.3]

Test Build Results:
[Confirm that testing was successful]
[List any issues found and resolved]

Production Environment:
[Specify target environment if applicable]

Release Notes:
[Brief description of what's in this release]
[Any breaking changes or migration notes]

Additional Information:
[Any special deployment considerations]

Example:

Summary: [Android] Deploy | acme-payments | 1.2.0

Description:
Module Name: acme-payments
Version: 1.2.0

Test Build Results:
✓ All functional tests passed successfully
✓ Biometric authentication tested on Android 12, 13, and 14
✓ Payment flows tested with test cards
✓ No crashes or unexpected behavior observed

Production Environment: Production

Release Notes:
- Added biometric authentication support for payment confirmation
- Improved error handling for network timeouts
- Updated payment UI for better accessibility
- Bug fix: Resolved crash on non-English locales

Additional Information:
This is a minor release with backward compatibility maintained.
No migration steps required for existing implementations.

3. General Support Ticket

Use this for questions, issues, or assistance during development.

Required Information:

Field	Value
Summary	Brief description of your question or issue
Product	Mobile SDK
Description	Detailed explanation of what you need

Example:

Summary: Question about R8 configuration for custom dependency

Description:
I'm adding a third-party library (XYZ SDK) to my module and receiving
R8 obfuscation warnings during the test build.

Module: acme-analytics
Library: XYZ SDK version 2.4.1

Error message:
[Include relevant error messages]

Question:
What consumer rules should I add to prevent this library from being
obfuscated incorrectly?

I've already tried:
- [List what you've attempted]

Best Practices

Be Specific and Complete

• Always include all requested information
• Provide clear, concise descriptions
• Include relevant links (merge requests, documentation, etc.)
• Add any error messages or logs when reporting issues
• Include module data {} configuration changes - If you've modified the data structure in settings.json, include the updated JSON and explanation in your ticket

Use Consistent Naming

• Use your module's repository name consistently
• Follow the summary format exactly for merge request and deployment tickets
• This helps Q2 route and prioritize your tickets efficiently

Timing

• Submit merge request tickets as soon as your MR is created
• Don't wait to submit deployment tickets - do it right after successful testing
• For questions, search existing documentation first

Communication

• Monitor your ticket for responses from Q2
• Respond promptly to any questions or requests for clarification
• Update the ticket if you make changes to your merge request

Ticket Lifecycle

1. Ticket Submitted

You create and submit the ticket with all required information.

2. Ticket Acknowledged

Q2 team acknowledges receipt and may ask clarifying questions.

3. In Progress

Q2 begins work (code review, build creation, deployment, etc.).

4. Resolution

• For merge requests: Code is approved and merged, or feedback is provided
• For deployment requests: Module is deployed to production
• For support questions: Answer or solution is provided

5. Ticket Closed

Issue is resolved and ticket is closed.

Environment Specifications

When requesting test builds, specify one of the following environments:

For Partners

• Sandbox: Your organization's dedicated sandbox environment
  • Format: https://stack.q2developer.com/sdk/{stack-name}/ardent/uux.aspx
• SDX (Sales Demo Experimental): Q2's demo environment for testing
  • Commonly used for partner testing
  • May require separate credentials

For Financial Institutions

• PTE (Pre-Production Test Environment): Your pre-production environment
  • Default option for FI test builds
• Sandbox: Your organization's sandbox instance
  • Alternative testing environment
• Production: Only for special cases, discuss with Q2 first

Troubleshooting

I don't have access to q2developer.com

Contact your Q2 representative or account manager to request access. Provide:

• Your name and email
• Organization name
• Role (developer, partner, FI, etc.)

My ticket hasn't received a response

• Check your email for responses (they're sent to your registered email)
• Verify you included all required information
• For urgent issues, follow up on the ticket after 2 business days

I need to update information in a submitted ticket

• Reply to the ticket with updated information
• Reference what changed (e.g., "Updated merge request with fixes")
• Don't create a duplicate ticket

Additional Resources

• Development Workflow - Complete workflow overview
• Local Development - Day-to-day development practices
• Code Review Process - What Q2 reviews and your responsibilities
• Android Publishing Overview - High-level publishing information
• Request Module Repository - How to request initial repository setup

FAQ

Do I need a new ticket for each merge request?

Yes, create a new ticket each time you submit a merge request for review. This helps Q2 track and prioritize reviews.

Can I use the same ticket for multiple issues?

It's better to create separate tickets for distinct issues or requests. This makes tracking and resolution easier.

What if I need to submit multiple merge requests for the same feature?

If Q2 requests changes and you update your branch, the original merge request updates automatically - use the same ticket. If you need to create a new MR, create a new ticket and reference the previous one.

How do I check the status of my ticket?

Log in to q2developer.com and navigate to your support tickets. You'll see the current status and any responses from the Q2 team.

What happens if I forget to include module data configuration changes?

If you don't include updated data {} configuration in your ticket, your module may fail or behave incorrectly in the test build because Q2 won't know to update the configuration. The settings.json from your DevApp is not automatically copied to test/production builds - Q2 manually configures module data based on what you provide in the ticket. Always include any configuration changes to prevent issues.