StartseiteServicesAndroid-App-Entwicklung
Native Android-App-Entwicklung mit Kotlin und Jetpack Compose
Android-App-Entwicklung umfasst Konzeption, Entwicklung und Veröffentlichung von Apps für Android-Smartphones, Tablets, Foldables und Wear-OS-Uhren, verteilt über Google Play oder auf verwaltete Firmengeräte. Woltrio entwickelt native Android-Apps in Kotlin mit Jetpack Compose für Organisationen im Gesundheitswesen, Start-ups und Unternehmen. Dazu übernehmen wir die Arbeit rund um Google Play: den Abschnitt zur Datensicherheit, die Erklärung zu Gesundheits-Apps und das jährliche Update auf das geforderte Ziel-API-Level.
Was wir für Android entwickeln
Fünf Arten von Android-Apps mit jeweils eigenen Regeln für Richtlinien, Geräte und Daten. Gesundheit steht an erster Stelle, weil dort die strengsten gelten.
Gesundheits- und mHealth-Apps (Health Connect)
Gesundheits- und Fitness-Apps lesen und schreiben Daten unter Android über Health Connect. Ab Android 14 ist Health Connect Teil des Android-Frameworks, unter Android 13 und älter wird es über Google Play installiert. Wir fordern nur die Datentypen an, die die App braucht, halten die Manifest-Berechtigungen deckungsgleich mit dem in der Play Console angegebenen Zugriff und ergänzen den vorgeschriebenen Bildschirm mit der Datenschutzerklärung. Laut Google werden die Google-Fit-APIs bis Ende 2026 unterstützt, daher setzen neue Apps und Migrationen auf Health Connect. Jede App füllt außerdem die Erklärung zu Gesundheits-Apps aus, und Gesundheits-Apps ohne Medizinproduktstatus tragen den geforderten Hinweis.
Health Connect · Erklärung zu Gesundheits-Apps · Google-Fit-Migration · Berechtigungshinweis
Telemedizin- und Patienten-Apps
Patienten-Apps verbinden Terminbuchung, sichere Nachrichten, Videosprechstunden, Aufnahmeformulare und den Zugriff auf Befunde. Unter Android laufen Videoanrufe als Foreground Service, damit ein Termin weiterläuft, wenn Patienten die App wechseln, und wir erklären Kamera-, Mikrofon- und Bluetooth-Audio-Berechtigungen, bevor wir sie anfragen. Benachrichtigungen laufen über Firebase Cloud Messaging; seit Android 13 müssen Nutzer sie erlauben, daher fragen wir im passenden Moment. Nachrichteninhalte bleiben hinter der Anmeldung statt im Benachrichtigungstext. Verarbeitet die App PHI für einen Leistungserbringer, ist sie mit HIPAA-Schutzmaßnahmen konzipiert und über FHIR oder bestehende APIs an Ihr EHR angebunden.
Videosprechstunde · FCM-Benachrichtigungen · Sichere Nachrichten · FHIR- und EHR-APIs
Unternehmens- und Außendienst-Apps
Außendienst- und Mitarbeiter-Apps laufen auf firmeneigenen oder privaten Geräten, die über Android Enterprise verwaltet werden. Wir entwickeln sie für den Einsatz im Arbeitsprofil, unterstützen verwaltete Konfigurationen, damit die IT Serveradressen und Funktionsschalter aus der Geräteverwaltung setzen kann, und binden Single Sign-on über Ihren Identitätsanbieter an. Dedizierte Geräte wie gemeinsam genutzte Tablets oder Kioske laufen in einem gesperrten Modus. Offline-Arbeit ist hier besonders wichtig: Formulare, Checklisten und Fotos werden in einer Room-Datenbank auf dem Gerät gespeichert und per WorkManager synchronisiert, sobald wieder eine Verbindung besteht. Die Konfliktregeln legen wir vor dem ersten Bildschirm fest.
Android Enterprise · Arbeitsprofil · Verwaltete Konfigurationen · Offline-Sync
Consumer- und Abo-Apps
Consumer-Apps hängen von schnellem Onboarding, flüssigen Bildschirmen und einem Grund zur Rückkehr ab. Wir bauen Compose-Oberflächen nach Material Design, verkaufen digitale Abonnements über Google Play Billing und prüfen Käufe und App-Integrität mit der Play Integrity API auf Ihrem Server, statt dem Gerät zu vertrauen. Push-Kampagnen laufen über Firebase Cloud Messaging mit Benachrichtigungskanälen, die Nutzer selbst steuern. Vor dem Launch füllen wir den Abschnitt zur Datensicherheit anhand einer Liste aller SDKs in der App aus, denn auch Analyse- und Werbebibliotheken erheben Daten. Nach dem Release beobachten wir Absturz- und ANR-Raten in Android Vitals.
Play Billing · Play Integrity · Datensicherheit · Android Vitals
Wear-OS- und Geräte-Apps
Wear-OS-Apps und Begleit-Apps für Bluetooth-Geräte bringen Sensoren ins Produkt. Ab Wear OS 3 liefert Health Services Herzfrequenz-, Trainings- und passive Daten und konfiguriert die Sensoren akkuschonend; Compose for Wear OS übernimmt die kleinen runden Displays. Für Blutzuckermessgeräte, Blutdruckmanschetten, Waagen oder Industriesensoren entwickeln wir Bluetooth-Low-Energy-Verbindungen mit Kopplung, Wiederverbindung und Datenprüfung. Für Wear OS gilt bei Google Play eine eigene Regel zum Ziel-API-Level, und Apps, die für eine medizinische Funktion externe Hardware benötigen, müssen die kompatiblen Geräte in der Store-Beschreibung nennen.
Health Services · Compose for Wear OS · Bluetooth LE · Begleit-Apps
Was in einer nativen Android-App steckt
Sechs Bausteine, die wir in jedem Android-Projekt einplanen, unabhängig von der Art der App.
Kotlin und Jetpack Compose
Google empfiehlt Kotlin für neue Android-Apps und bezeichnet Jetpack Compose als empfohlenes Toolkit für native Oberflächen. Wir bauen Bildschirme in Compose mit einem gemeinsamen Designsystem und Vorschauen und halten die Geschäftslogik in testbaren Kotlin-Modulen getrennt von der Oberfläche.
Learn moreOffline-first-Daten und Synchronisierung
Die Room-Datenbank auf dem Gerät ist die maßgebliche Datenquelle, sodass Bildschirme auch ohne Netz laden. Änderungen werden zuerst lokal gespeichert und vorgemerkt; WorkManager synchronisiert sie, sobald eine Verbindung besteht, und wiederholt fehlgeschlagene Versuche. Konfliktregeln wie „letzte Änderung gewinnt“ oder Zusammenführung auf Feldebene legen wir pro Datentyp fest.
Learn moreHealth Connect und Gerätedaten
Apps lesen und schreiben Schritte, Herzfrequenz, Schlaf, Ernährung und weitere Datensätze über Health Connect, mit Berechtigungen pro Datentyp. Wir bilden diese Daten auf Ihr Backend oder auf FHIR-Ressourcen ab und binden Wearables über Health Services auf Wear OS oder Bluetooth Low Energy an.
Learn morePush-Benachrichtigungen und Nachrichten
Firebase Cloud Messaging stellt Benachrichtigungs- und Datennachrichten zu. Wir richten Benachrichtigungskanäle ein, fragen die mit Android 13 eingeführte Berechtigung im passenden Kontext ab und halten sensible Inhalte aus der Benachrichtigung heraus: Die App erhält nur ein Signal und lädt die Nachricht nach der Anmeldung.
App-Sicherheit und Play Integrity
Schlüssel und Tokens liegen im Android Keystore, der Netzwerkverkehr nutzt TLS, und die biometrische Anmeldung läuft über den systemeigenen BiometricPrompt. Ihr Server fordert Play-Integrity-Ergebnisse zu App, Gerät und Konto an und prüft sie, bevor er sensiblen Anfragen vertraut.
Learn moreGoogle-Play-Release und Richtlinien
Wir bereiten Store-Eintrag, Abschnitt zur Datensicherheit, Erklärung zu Gesundheits-Apps und Altersfreigabe vor, veröffentlichen über interne, geschlossene und offene Test-Tracks und rollen Produktionsversionen stufenweise aus. Jedes Jahr planen wir den Wechsel auf das neue Ziel-API-Level vor der Frist von Google.
Learn moreCross-Platform vs. nativ
Cross-Platform oder native Android-App?
Mit Cross-Platform-Frameworks wie Flutter und React Native liefert ein Team iOS und Android aus einer gemeinsamen Codebasis, und für viele Content-, Buchungs- und Commerce-Apps ist das die richtige Wahl. Natives Kotlin lohnt sich, wenn die App auf Android-spezifische Funktionen wie Health Connect, Wear OS, Android Enterprise oder viel Hintergrundarbeit angewiesen ist oder Android Ihre Hauptplattform ist.
iOS und Android gleichzeitig
Off-the-Shelf
Passt sehr gut. Eine Codebasis und ein Team decken beide Stores ab, was Kosten spart, wenn die Funktionen auf beiden Plattformen gleich sind.
Custom-Built with Woltrio
Zwei Codebasen, wenn Sie auch iOS brauchen. Ideal, wenn Android Priorität hat oder jede Plattform eigenes Verhalten braucht.
Neue Android-APIs und Health Connect
Off-the-Shelf
Über Plugins oder eigenen nativen Brückencode verfügbar. Neue APIs werden teils später unterstützt als in den nativen SDKs.
Custom-Built with Woltrio
Direkter Zugriff auf Health Connect, Health Services und neue Jetpack-Bibliotheken, sobald Google sie veröffentlicht.
Wear OS, Widgets und Hintergrundarbeit
Off-the-Shelf
Möglich, aber diese Teile brauchen meist native Kotlin-Module neben dem gemeinsamen Code.
Custom-Built with Woltrio
Mit den Werkzeugen der Plattform gebaut: Compose for Wear OS, Glance-Widgets, WorkManager und Foreground Services.
Bedienung unter Android
Off-the-Shelf
Gut. Frameworks können Material Design nachbilden, manche Systemverhalten erfordern aber Zusatzaufwand.
Custom-Built with Woltrio
Material-Komponenten, System-Zurückgesten, Bedienungshilfen und Layouts für große Displays verhalten sich so, wie Android-Nutzer es erwarten.
Budget und Markteinführung
Off-the-Shelf
Für zwei Plattformen meist günstiger, und Ihr Team pflegt nur ein Framework.
Custom-Built with Woltrio
Höher, wenn Sie beide Plattformen brauchen; vergleichbar bei einem reinen Android-Produkt oder einer verwalteten Geräteflotte.
Unsicher, was passt? Wir empfehlen den Ansatz, der zu Ihren Funktionen, Ihrem Budget und Ihrem Team passt, auch Cross-Platform, wenn das die bessere Antwort ist.
Von Anfang an eingebaut
Was jede Android-App braucht, ob sie Gesundheitsdaten verarbeitet oder nicht.
Anmeldung mit OAuth 2.0 und OpenID Connect, serverseitig durchgesetzte Rollen, verschlüsselter lokaler Speicher und Sitzungs-Timeouts. Woltrio betreibt ein nach ISO/IEC 27001:2022 zertifiziertes Informationssicherheits-Managementsystem, und Apps, die PHI verarbeiten, sind von Beginn an mit HIPAA-Schutzmaßnahmen konzipiert.
Wie wir Android-Projekte angehen
Unser Vorgehen bei Android-Projekten, vom ersten Gespräch bis zum jährlichen Plattform-Update.
Gesundheitsregeln ab dem ersten Tag
Wir erfassen PHI, Health-Connect-Daten und die Gesundheitsrichtlinien von Google Play, bevor das Design beginnt, und legen fest, was auf dem Gerät bleibt. Wir unterzeichnen mit Kunden aus dem Gesundheitswesen einen Business Associate Agreement (BAA), bevor PHI geteilt werden.
Ehrliche Plattformberatung
Wir empfehlen natives Kotlin nur, wenn Ihre Funktionen es erfordern. Wäre eine Cross-Platform-App die bessere Lösung, sagen wir das und können auch diese umsetzen. So richtet sich die Entscheidung nach Ihrem Produkt und Budget, nicht nach unserer Vorliebe.
Auf jährliche Änderungen ausgelegt
Android und die Richtlinien von Google Play ändern sich jedes Jahr. Wir testen über Displaygrößen und OS-Versionen hinweg, planen das Update auf das Ziel-API-Level vor jeder Frist und halten Datensicherheitsangaben und Gesundheitserklärungen bei jedem Release aktuell.
Von der Idee zu Google Play
- 01
Analyse und Plattformwahl
Wir definieren Nutzer, Funktionen, Datenflüsse und Geräte und entscheiden dann zwischen nativem Android und Cross-Platform. Für Gesundheits-Apps listen wir Datentypen, Health-Connect-Berechtigungen und die nötigen Play-Erklärungen auf.
- 02
UX und Prototyp
Wir gestalten Compose-Bildschirme mit Material-Komponenten, testen klickbare Prototypen mit echten Nutzern und prüfen Barrierefreiheit, Layouts für große Displays, dunkles Design und Berechtigungsabfragen, bevor die eigentliche Entwicklung beginnt.
- 03
Entwicklung in Sprints
Kotlin-Module, Offline-Datenschicht, APIs und Integrationen entstehen in zweiwöchigen Sprints. Am Ende jedes Sprints erhalten Sie einen Test-Build über einen Google-Play-Test-Track und können ihn auf Ihren eigenen Geräten prüfen.
- 04
Tests auf vielen Geräten
Wir testen auf einer Gerätematrix aus Smartphones, Tablets und Foldables, älteren und aktuellen Android-Versionen und mehreren Herstellern, mit automatisierten UI-Tests, TalkBack-Prüfungen sowie Offline- und Schwachnetz-Szenarien.
- 05
Release und Betreuung
Wir füllen die Angaben in der Play Console aus, rollen stufenweise aus, beobachten Android Vitals und halten die App mit dem jährlichen Ziel-API-Level und neuen Richtlinien aktuell.
Häufig
gestellte Fragen
Sie suchen Basisinfos? In unseren FAQs finden Sie präzise Antworten auf die wahrscheinlichsten Fragen.
Wann sollte ich eine native Android-App statt einer Cross-Platform-App entwickeln lassen?
Was verlangt Google Play von Gesundheits-Apps?
Sollte eine neue Gesundheits-App Health Connect oder die Google-Fit-APIs nutzen?
Gilt HIPAA für meine Android-App?
Was besagt die Google-Play-Vorgabe zum Ziel-API-Level?
Wie testen Sie auf so vielen Android-Geräten?
Können Sie auch die iOS-Version entwickeln?
Wie funktionieren Push-Benachrichtigungen, ohne Patientendaten preiszugeben?
Sources & Standards
- Target API level requirements for Google Play apps (developer.android.com)
- Angaben für den Abschnitt zur Datensicherheit bei Google Play (support.google.com)
- Formular zur Erklärung zu Gesundheits-Apps (support.google.com)
- Richtlinie zu Gesundheitsinhalten und -diensten (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)
Weiter entdecken
Verwandte Seiten.
Ready to Build Your Healthcare Software.
Let's discuss your project requirements and build something that delivers real clinical and business value.
