Repository navigation
[DMP 2026]: Telemetry for Android Registration Client #719
Description
Ticket Contents
Description
This feature focuses on implementing a telemetry system within the Flutter-based Android Registration Client to collect data on user behavior and application performance.
Currently, there is limited visibility into how users interact with the application and where performance issues may occur. By integrating telemetry, the system will enable data-driven decision-making, helping product and engineering teams identify usage patterns, detect bottlenecks, monitor crashes, and continuously improve the user experience.
The feature will ensure that telemetry data is collected securely, respects user privacy, and can be configured based on deployment needs.
Goals & Mid-Point Milestone
Goals
Overall Goals
- Integrate a telemetry library/service into the Flutter application
- Capture user interaction events (clicks, navigation, flows)
- Collect application performance metrics (startup time, response latency)
- Capture device metadata (model, OS version, app version)
- Log errors, exceptions, and crash reports
- Enable secure transmission of telemetry data to backend systems
- Ensure compliance with privacy regulations (user consent, opt-in/opt-out)
- Provide dashboards and reporting for analysis
- Ensure minimal performance overhead due to telemetry
Mid-Point Milestone
- Basic telemetry SDK integration in Flutter app
- Capture core user events (screen navigation, key actions)
- Capture basic performance metrics (app startup time)
- Implement error and crash logging
- Backend endpoint integration for telemetry ingestion
- Basic configuration toggle to enable/disable telemetry
Setup/Installation
No response
Expected Outcome
The final implementation will provide a robust and scalable telemetry framework embedded within the Flutter application:
- The system will automatically capture and log user interactions, enabling visibility into user journeys and feature usage
- Performance metrics such as app startup time, API response times, and screen load times will be tracked continuously
- Crash reports and error logs will be collected to help quickly identify and debug issues
- Telemetry data will be securely transmitted and stored in backend systems for further analysis
- Users will have control over telemetry collection through consent mechanisms and configuration settings
- Product and engineering teams will be able to access dashboards and reports to analyze trends, detect anomalies, and make informed decisions
- The telemetry system will be optimized to ensure no noticeable degradation in app performance or user experience
Acceptance Criteria
- AC1: A telemetry library/service is successfully integrated into the Flutter application
- AC2: The system captures user events such as button clicks and screen navigation
- AC3: Application performance metrics (e.g., startup time, response time) are collected
- AC4: Device information (device model, OS version, app version) is captured
- AC5: Error logs and crash reports are recorded and accessible
- AC6: Telemetry data is securely transmitted to a backend server for storage and analysis
- AC7: User consent is obtained before collecting telemetry data, in compliance with privacy regulations
- AC8: Users can enable or disable telemetry collection via configuration settings
- AC9: Dashboards and reports are available for visualizing telemetry data
- AC10: Telemetry implementation does not significantly impact application performance or user experience
Implementation Details
Architecture
- Client-side telemetry module integrated within the Flutter app
- Backend telemetry ingestion service for data collection and storage
- Analytics and visualization layer for dashboards and reporting
Client-Side (Flutter)
-
Integration with telemetry/analytics SDKs such as:
- Firebase Analytics / Crashlytics
- OpenTelemetry (if standardized approach is preferred)
-
Event tracking framework:
- Structured event logging (event name, timestamp, metadata)
-
Performance monitoring:
- App startup time tracking
- API latency measurement
-
Error tracking:
- Exception handling hooks
- Crash reporting integration
Backend
- Secure API endpoints for telemetry ingestion
- Data storage (e.g., Elasticsearch, BigQuery, or similar analytics store)
- Data processing pipelines for aggregation and analysis
Security & Privacy
- Data encryption in transit (HTTPS) and at rest
- User consent management (opt-in/opt-out mechanism)
- Anonymization or pseudonymization of sensitive data
- Compliance with regulations (e.g., GDPR)
Configurability
- Feature flags to enable/disable telemetry
- Configurable event tracking levels
- Environment-based configurations (dev, staging, production)
Performance Considerations
- Asynchronous event logging
- Batching and throttling of telemetry data
- Minimal resource usage (CPU, memory, network)
Mockups/Wireframes
No response
Product Name
Android Registration Client
Organisation Name
MOSIP
Domain
Open Source Project
Tech Skills Needed
Other
Mentor(s)
Organizational Mentor
Feature Support : @Varaniya
Tech Support: @SachinPremkumar
Category
Research
Metadata
Metadata
Assignees
Type
Fields
Priority
End Date
Complexity
Start Date
Original Estimate
Time Tracking
Resolved By
Story Points
Activity
aniket866 commentedon Apr 24, 2026
Siri-026 commentedon Apr 27, 2026
Edasgh commentedon Apr 28, 2026
Pragya279 commentedon Apr 29, 2026
mundele2004 commentedon May 3, 2026
DELTA-45-G commentedon May 3, 2026
mundele2004 commentedon May 3, 2026
DELTA-45-G commentedon May 19, 2026
yakshithkd23 commentedon Jun 1, 2026
Thank you for the update. We have reviewed the problem statement and repository, and our team is actively working on the implementation. Looking forward to your feedback on the submitted PR.
Regards,
Yakshith K D
Team TuluTech
feat: implement decoupled cloud-native telemetry ingestion backend
yakshithkd23 commentedon Jun 16, 2026
Hi @Pragya279 and @SachinPremkumar,
Our team (TuluTech) has completed the implementation of the backend telemetry ingestion architecture for the Android Registration Client telemetry pipeline.
We have successfully developed a production-ready, containerized service stack capable of securely and reliably receiving telemetry data from the Android Registration Client.
🏗️ Architecture Overview
We implemented a Cloud-Native Sidecar Pattern, which provides a scalable, resilient, and maintainable solution without requiring any modifications to the core
mosip/tusd-serversource code. This approach follows best practices for maintaining compatibility with upstream open-source projects.Data Flow
mosip/tusd-serverreceives and stores the uploaded files in a shared Docker volume.registration-client-telemetry.✅ Validation and Testing
The complete environment is orchestrated through a single
docker-compose.ymlfile.We validated the end-to-end workflow locally using Python scripts that simulate chunked telemetry uploads from the Registration Client. The testing confirmed successful ingestion, processing, and delivery of telemetry data into Kafka.
Repository: https://github.com/yakshithkd23/registration_client_tusd-server
Pull Request:
🚀 Next Steps
With the ingestion layer completed, our upcoming work will focus on:
1. Data Consumption
Develop a consumer service (Python/Spark-based) to continuously process telemetry events from Kafka.
2. Time-Series Storage
Integrate a time-series database such as InfluxDB to persist telemetry metrics efficiently.
3. Monitoring Dashboard
Configure Grafana dashboards connected to the database to visualize:
We look forward to your feedback and suggestions on the proposed architecture and implementation.
Regards,
Yakshith K D
Team TuluTech
6 remaining items
feat: implement decoupled cloud-native telemetry ingestion backend
feat: implement decoupled cloud-native telemetry ingestion backend
feat: implement decoupled cloud-native telemetry ingestion backend
feat(telemetry): phase 5 - Flutter UI event triggers (Auth/Onboarding)
yakshithkd23 commentedon Jul 23, 2026
@Pragya279 @SachinPremkumar updated architecture Design
mosip/tusd-server#14 (comment)
feat: implement decoupled cloud-native telemetry ingestion backend
yakshithkd23 commentedon Aug 4, 2026
@Pragya279 @SachinPremkumar
As planned, we structured the project into two folders:
local-devfor local testing anddeployfor production setup.We started our work on
local-devto build and test the architecture locally first.We have now completed Phase 1.0: Local Dev Implementation.
The end-to-end telemetry pipeline is fully verified and working as expected.
ref: mosip/tusd-server#14 (comment)
yakshithkd23 commentedon Aug 11, 2026
@Pragya279 @SachinPremkumar @Varaniya
AC9: Dashboards and reports are available for visualizing telemetry data.
AC9 implemented and verified ,please find sample of image and information in mosip/tusd-server#14
yakshithkd23 commentedon Aug 20, 2026
Had a brief discussion with Devops team @ckm007 @anushasunkada , and janardhanBS regarding the telemetry logging pipeline. To address the heavy resource overhead of the current ELK stack and align with MOSIP's shift toward a lightweight architecture, we are moving to Alloy + Loki.
Next Steps:
Research and finalize the Alloy + Loki integration.
Create a new PR to migrate the logging setup to the Loki stack.
Complete local verification and end-to-end testing.
yakshithkd23 commentedon Aug 22, 2026
We have opened PR [#16](mosip/tusd-server#16) to share the updated architecture proposal for migrating our telemetry logging pipeline from the ELK stack to Grafana Alloy + Loki + Prometheus.
The PR description details the complete architecture design, pipeline flow, and component roles. We have started working on the implementation and will be pushing incoming commits directly to this PR.
Please review the proposed architecture flow in [PR #16](mosip/tusd-server#16) and let us know if you have any questions or feedback!
nithesh259 commentedon Aug 26, 2026
@Pragya279
this is Nithesh, team member of TuluTech , my github @nithesh259 now you can add me as a assignee
nithesh259 commentedon Sep 11, 2026
@Pragya279 @SachinPremkumar @GOKULRAJ136
Hi
quick update on our progress:
We have started creating the design documentation for telemetry in id-repository/docs.
We've forked the repository and are preparing to open a Pull Request.
repo: https://github.com/nithesh259/id-repo-telemtry-doc
nithesh259 commentedon Sep 11, 2026
Hi @Pragya279 @GOKULRAJ136 @SachinPremkumar
We have opened [PR #1653 in id-repository](mosip/id-repository#1653) to add the telemetry design documentation (
telemetry-design.md). We have started updating the documentation there.Regards,
Team TuluTech