HomeServicesAndroid App Development
Native Android app development in Kotlin and Jetpack Compose
Android app development is the design, build and release of apps for Android phones, tablets, foldables and Wear OS watches, published on Google Play or deployed to managed company devices. Woltrio builds native Android apps in Kotlin with Jetpack Compose for healthcare organizations, startups and enterprises. We also handle the Google Play work that comes with them: the Data safety section, the Health apps declaration and the yearly target API level update.
What we build on Android
Five kinds of Android apps, each with its own policy, device and data rules. Healthcare comes first because it carries the strictest ones.
Healthcare & mHealth apps (Health Connect)
Health and fitness apps on Android read and write data through Health Connect, which is part of the Android framework from Android 14 and installed from Google Play on Android 13 and lower. We request only the data types the app needs, keep manifest permissions in line with the Health Connect access declared in Play Console, and add the required privacy policy rationale screen. Google has said the Google Fit APIs are supported until the end of 2026, so new builds and migrations target Health Connect. Every app also completes Play's Health apps declaration, and health apps that are not medical devices carry the required disclaimer.
Health Connect · Health apps declaration · Google Fit migration · Permission rationale
Telemedicine & patient apps
Patient apps combine scheduling, secure messaging, video visits, intake forms and access to results. On Android we run video calls as a foreground service so a visit continues when the patient switches apps, and we explain camera, microphone and Bluetooth audio permissions before asking. Notifications go through Firebase Cloud Messaging; since Android 13 users must grant notification permission, so we ask at a moment that makes sense. Message content stays behind sign-in instead of in the notification text. Where the app handles PHI for a provider, it is designed with HIPAA safeguards and connects to your EHR over FHIR or existing APIs.
Video visits · FCM notifications · Secure messaging · FHIR and EHR APIs
Enterprise & field-worker apps
Field and staff apps run on company-owned or personal devices managed through Android Enterprise. We build them to work inside a work profile, accept managed configurations so IT can set server addresses and feature switches from the device management console, and support single sign-on with your identity provider. Dedicated devices such as shared tablets or kiosks run in a locked-down mode. Offline work matters most here: forms, checklists and photos save to an on-device Room database and sync through WorkManager when a connection returns, with conflict rules agreed before the first screen is built.
Android Enterprise · Work profile · Managed configurations · Offline sync
Consumer & subscription apps
Consumer apps depend on fast onboarding, quick screens and a reason to come back. We build Compose interfaces that follow Material Design, sell digital subscriptions through Google Play Billing, and check purchases and app integrity on your server with the Play Integrity API instead of trusting the device. Push campaigns go through Firebase Cloud Messaging with notification channels users control. Before launch we complete the Data safety section from an inventory of every SDK in the app, because analytics and advertising libraries count as data collection too, and after release we watch crash and ANR rates in Android vitals.
Play Billing · Play Integrity · Data safety · Android vitals
Wear OS & connected-device apps
Wear OS apps and companion apps for Bluetooth devices bring sensors into the product. On Wear OS 3 and higher, Health Services gives apps heart rate, exercise and passive data while it configures the sensors for battery life, and Compose for Wear OS handles small round screens. For glucose meters, blood pressure cuffs, scales or industrial sensors we build Bluetooth Low Energy connections with pairing, reconnection and data validation. Wear OS has its own target API level rule on Google Play, and apps that rely on external hardware for a medical function must list the compatible devices in their store description.
Health Services · Compose for Wear OS · Bluetooth LE · Companion apps
What goes into a native Android app
Six building blocks we plan into every Android project, whatever the app type.
Kotlin and Jetpack Compose UI
Google recommends Kotlin for new Android apps and calls Jetpack Compose its recommended toolkit for native UI. We build screens in Compose with a shared design system and previews, and keep business logic in testable Kotlin modules separate from the UI.
Learn moreOffline-first data and sync
The on-device Room database is the source of truth, so screens load without a network. Changes are saved locally first and queued, and WorkManager syncs them when a connection returns, retrying with backoff. Conflict rules, such as last write wins or field-level merges, are agreed per data type.
Learn moreHealth Connect and device data
Apps read and write steps, heart rate, sleep, nutrition and other records through Health Connect, with permissions per data type. We map those records to your backend or to FHIR resources, and connect wearables through Health Services on Wear OS or Bluetooth Low Energy.
Learn morePush notifications and messaging
Firebase Cloud Messaging delivers notification and data messages. We set up notification channels, request the Android 13 notification permission in context, and keep sensitive content out of the notification itself by sending a signal the app uses to fetch the message after sign-in.
App security and Play Integrity
Keys and tokens live in the Android Keystore, network traffic uses TLS, and biometric sign-in uses the system BiometricPrompt. Your server requests and checks Play Integrity verdicts on the app, the device and the account before it trusts sensitive requests.
Learn moreGoogle Play release and policy
We prepare the store listing, Data safety section, Health apps declaration and content rating, ship through internal, closed and open testing tracks, and roll out production releases in stages. Each year we plan the move to the new target API level before Google's deadline.
Learn moreCross-platform vs. native
Cross-platform or native Android?
Cross-platform frameworks such as Flutter and React Native let one team ship iOS and Android from a shared codebase, and for many content, booking and commerce apps that is the right call. Native Kotlin makes sense when the app relies on Android-specific features such as Health Connect, Wear OS, Android Enterprise or heavy background work, or when Android is your main platform.
iOS and Android at the same time
Off-the-Shelf
Strong fit. One codebase and one team cover both stores, which lowers cost when features are the same on each platform.
Custom-Built with Woltrio
Two codebases if you also need iOS. Best when Android is the priority or each platform needs its own behavior.
New Android APIs and Health Connect
Off-the-Shelf
Available through plugins or your own native bridge code. Support for new APIs can arrive later than in the native SDKs.
Custom-Built with Woltrio
Direct access to Health Connect, Health Services and new Jetpack libraries as soon as Google releases them.
Wear OS, widgets and background work
Off-the-Shelf
Possible, but these parts usually need native Kotlin modules next to the shared code.
Custom-Built with Woltrio
Built with the platform tools: Compose for Wear OS, Glance widgets, WorkManager and foreground services.
Look and feel on Android
Off-the-Shelf
Good. Frameworks can match Material Design, though some system behaviors take extra work.
Custom-Built with Woltrio
Material components, system back gestures, accessibility services and large-screen layouts behave the way Android users expect.
Budget and time to market
Off-the-Shelf
Usually lower for two platforms, and your team maintains one framework.
Custom-Built with Woltrio
Higher if you need both platforms; comparable for an Android-only product or a managed-device fleet.
Not sure which fits? We recommend the approach that suits your features, budget and team, including cross-platform when that is the better answer.
Built in from the first release
The parts every Android app needs, whether it handles health data or not.
Sign-in with OAuth 2.0 and OpenID Connect, roles enforced on the server, encrypted local storage and session timeouts. Woltrio runs an ISO/IEC 27001:2022 certified information security management system, and apps that handle PHI are designed with HIPAA safeguards.
How we work on Android
Our approach to Android projects, from the first call to the yearly platform update.
Healthcare rules from day one
We map PHI, Health Connect data and Google Play health policy requirements before design starts and decide what stays on the device. We sign a Business Associate Agreement (BAA) with healthcare clients before PHI is shared.
Honest platform advice
We recommend native Kotlin only when your features need it. If a cross-platform app would serve you better, we say so and can build that instead, so the decision rests on your product and budget, not on our preference.
Planned for yearly change
Android and Google Play policies change every year. We test across screen sizes and OS versions, plan the target API level update before each deadline, and keep the Data safety section and health declarations in step with every release.
From idea to Google Play
- 01
Discovery and platform choice
We define users, features, data flows and devices, then decide between native Android and cross-platform. For health apps we list the data types, Health Connect permissions and Play declarations the app will need.
- 02
UX and prototype
We design Compose screens with Material components, test clickable prototypes with real users, and check accessibility, large-screen layouts, dark theme and permission prompts before any development starts.
- 03
Build in sprints
Kotlin modules, the offline data layer, APIs and integrations are built in two-week sprints. At the end of each sprint you get a test build through a Google Play testing track.
- 04
Testing across devices
We test on a device matrix of phones, tablets and foldables, older and current Android versions and several manufacturers, with automated UI tests, TalkBack checks and offline and poor-network scenarios.
- 05
Release and upkeep
We complete the Play Console declarations, roll out in stages, watch Android vitals, and keep the app current with each year's target API level and policy changes.
Frequently
Asked Questions
Seeking basic information? Our FAQ section is a ready reckoner with precise answers to the most probable queries.
When should I build a native Android app instead of a cross-platform one?
What does Google Play require from health apps?
Should a new health app use Health Connect or the Google Fit APIs?
Does HIPAA apply to my Android app?
What is the Google Play target API level requirement?
How do you test across so many Android devices?
Can you build the iOS version too?
How do push notifications work without exposing patient data?
Sources & Standards
- Target API level requirements for Google Play apps (developer.android.com)
- Provide information for Google Play's Data safety section (support.google.com)
- Health apps declaration form (support.google.com)
- Health Content and Services policy (support.google.com)
- Health Connect developer guide (developer.android.com)
- Play Integrity API overview (developer.android.com)
- Android Enterprise developer overview (developer.android.com)
- Health Breach Notification Rule (ftc.gov)
Keep exploring
Related pages.
Ready to Build Your Healthcare Software.
Let's discuss your project requirements and build something that delivers real clinical and business value.
