Android'de 2026'da ön plan servis türleri: özelliğinize gerçekten uyanı seçmek
Android'in ön plan servis türü kısıtlamalarına pratik bir rehber — dataSync, mediaPlayback, specialUse, shortService — ve öldürülmeden ya da reddedilmeden doğru olanı nasıl seçeceğiniz.
Bir ön plan servisi başlatmak eskiden tek satır ve bir bildirimdi. Artık değil. Güncel bir hedef SDK’daki her ön plan servisi, manifestoda bir tür bildirmek, eşleşen izni istemek ve birkaç durumda uygulama yayımlanmadan önce Google’a kendi varlığını haklı çıkarmak zorunda. Bunların hiçbiri kendi başına bürokrasi değil — her tür farklı bir yaşam süresi garantisi taşıyor ve yanlış türü seçmek, test sırasında sorunsuz çalışan bir özelliğin haftalar sonra gerçek bir cihazda sessizce öldürülmesinin yoludur. İşte Mintly’nin odak zamanlayıcısının vermek zorunda kaldığı kararı örnek alarak, gerçekte nasıl seçim yapılacağı.
Neden “sadece bir ön plan servisi başlat” artık işe yaramıyor
Eski model izin vericiydi: startForeground()’ı çağırın, bir bildirim gösterin ve bildirim görünür kaldığı sürece sistem sizi büyük ölçüde rahat bırakırdı. Bu, ön plan servislerini kötüye kullanım için bir mıknatısa dönüştürdü — hiçbir zaman senkronize olmayan bir “senkronizasyon” servisi, sadece süreci canlı tutan bir “dinleme” servisi. Platformun cevabı, her ön plan servisini bildirilen bir türe bağlamak oldu; her türün kendi izni ve ne kadar süre gözetimsiz çalışabileceğine dair kendi sözleşmesi var. “Güvenin bana, bu önemli” diyemezsiniz. Ne tür bir önem olduğunu söylersiniz, gerisini sistem uygular.
<service
android:name=".timer.FocusSessionService"
android:foregroundServiceType="specialUse"
android:exported="false">
<property
android:name="android.app.PROPERTY_SPECIAL_USE_FGS_SUBTYPE"
android:value="active-focus-timer" />
</service>
Tür bildirimini atlarsanız, servis güncel bir hedef SDK’da basitçe başlamaz — startForeground() uyarmaz, hata fırlatır.
Çoğu bağımsız özelliğe gerçekten uyan türler
Seçilmiş liste camera, microphone, location, phoneCall, mediaPlayback ve connectedDevice gibi durumları kapsıyor — her biri kulağa geldiği gibi sıkıca kapsamlandırılmış, her biri gerçek yeteneğe eşlenen bir izinle korunuyor (FOREGROUND_SERVICE_CAMERA, CAMERA izni gerektirir, ve böyle devam eder). Özelliğiniz gerçekten ses çalıyorsa ya da bir giyilebilir cihazdan akış yapıyorsa, tür açıktır ve izin muhtemelen zaten sahip olduğunuz bir izindir.
Daha derinlemesine anlamaya değer iki tür, tek bir sensöre eşlenmeyenler: dataSync ve specialUse.
dataSync, net bir bitiş çizgisi olan bir arka plan aktarımı içindir — bir yedeklemeyi yüklemek, uzak bir güncellemeyi çekmek. Dinlenme hâli değildir; Android 15 itibarıyla dataSync ve mediaProcessing servisleri, hareketli 24 saatlik bir pencerede yaklaşık altı saatlik toplam bir çalışma süresi bütçesi alır. Bunu aşarsanız sistem Service.onTimeout()’u çağırır, servisi zorla durdurmadan önce toparlanmanız için kısa bir süre tanır. Türün ne için var olduğuna göre bu makul bir takas — bitmesi gereken bir aktarım — ve süresiz olarak orada durması amaçlanan bir şey için kötü bir uyum.
specialUse: listede olmayan her şey için tür
25 dakikalık bir odak zamanlayıcısı ne bir veri senkronizasyonu, ne medya oynatma, ne de bir sensöre bağlı. Tam olarak specialUse’ın var olma amacı olan boşluk bu — gerçekten zamana bağlı ve kullanıcı tarafından başlatılan, ama isimlendirilmiş kategorilerden hiçbirine uymayan bir ön plan servisi. İşin can alıcı noktası, bunu sadece bildirip geçemezsiniz: manifest <property> etiketi, servisin ne yaptığını açıklayan bir alt tür dizesi gerektirir ve Google Play’in uygulama incelemesi o dizeyi okur. Aslında gizlenmiş bir veri senkronizasyonu ya da bir canlı-tutma numarası olan bir şey için specialUse bildirin, bu türden bir uyumsuzluk, lansmandan sonra değil, inceleme sırasında işaretlenir.
Mintly için alt tür active-focus-timer’dır ve Play Console’un ön plan servis bildirim formu da aynı şeyi sade İngilizce ile ifade eder: kullanıcının başlattığı ve aktif olarak izlediği, belirli bir zamanda biten çalışan bir seans. Bu, doğru olduğu için haklı çıkarması kolay bir durum. Servisin ne yaptığına dair dürüst, tek satırlık bir açıklama yazmak, inceleme titizliğinden kaçan bir tür bulmaya çalışmaktan daha iyi harcanmış zamandır.
shortService: seans için değil, patlama için inşa edildi
Bilinmesi gereken diğer tür shortService, bir ön plan servisinin bir şeyi bitirmek için sadece birkaç dakikaya ihtiyaç duyduğu durumlar içindir — büyük bir dışa aktarımı yazmak, tek seferlik bir temizlik çalıştırmak — kullanıcıların bir WorkManager genişletilmiş işinin soğuk başlangıcına tahammül edeceğinden daha kısa bir süre için. Yaklaşık üç dakikalık sert bir çalışma süresi sınırıyla gelir; sistem bunun ötesinde pazarlık yapmaz ve tür, kısa süreli işlerin ihtiyaç duyduğundan daha uzun bir süre kazanmak için dataSync veya specialUse’ı kötüye kullanmayı durdurmak için tam olarak var. Göreviniz öngörülebilir bir şekilde üç dakikanın altında bitiyorsa, bu kullanılacak dürüst türdür. Bazen uzun sürüyorsa, yanlış olan budur ve bunu üretimde öğrenirsiniz, testte değil.
Türü yanlış almak bir üretim hatasıdır, bir lint uyarısı değil
Bildirdiğiniz tür, emin değilseniz Android’in kibarca göz ardı ettiği bir meta veri değildir. Günde sekiz saat çalışan bir şey için dataSync bildirin, çalışma ortasında zaman aşımına uğrar — uygulamanızın ardından doğru bir şekilde algılayıp kurtarması gereken bir durum, yoksa kullanıcı sadece açıklama olmadan takılı kalmış bir özellik görür. Dürüst bir alt tür olmadan specialUse bildirin ve Play incelemesi güncellemeyi doğrudan reddedebilir; bu, doğru türü baştan seçmenin aldığı on dakikadan çok daha kötü bir lansman gecikmesidir.
Karar iki soruya indirgeniyor: bu servis camera ya da mediaPlayback gibi gerçek bir yeteneğe mi eşleniyor? Değilse, iş doğal olarak dakikalarla mı sınırlı (shortService), net bir sonu olan saatlerle mi (dataSync), yoksa açık uçlu ama kullanıcı tarafından başlatılan ve aktif olarak izlenen mi (specialUse, dürüstçe bildirilmiş)? Manifesto girdisini yazmadan önce bunlara cevap verin, çökme raporu ortaya çıktıktan sonra değil. Tür sistemi bir kez öğrenilince can sıkıcı, ondan sonra platform hakkında sadece bir gerçek — tıpkı Android 16’nın Live Updates özelliğinin, Mintly’nin zamanlayıcı servisinin üzerine, onun ön plan servis türünü baştan doğru almanın yerine geçmek yerine oturması gibi.
// İlgili okumalar
Günlükten dahası
Mintly'i inşa etmek: Android süreci öldürmek isterken bir odak zamanlayıcısını doğru tutmak
Çalışan bir Pomodoro zamanlayıcısının, tek seferlik bir hatırlatıcıdan daha zor bir güvenilirlik sorunu var. İşte Mintly'in ön plan servisi ve duvar saati bitiş zamanıyla Doze, süreç ölümü ve ekran kapalıyken oluşan kaymayı nasıl atlattığı.
Android In-App Review API: sıkıcı olmadan puan istemek
Google'ın In-App Review API'sine pratik bir rehber — gerçekte nasıl çalıştığı, ne zaman tetiklenmesi gerektiği ve alışılmış 'bizi puanlayın' popup'ının Play Store puanınızı sessizce nasıl zedelediği.
Android uygulama kısayolları ve Hızlı Ayarlar Karosu: uygulamayı açmadan su kaydetmek
Android'in dinamik ShortcutManager API'sine ve TileService'e pratik bir rehber — tek dokunuşlu bir eylemin uygulamayı tamamen atlamasını nasıl sağlarsınız, çoğu uygulamayı çuvallatan tuzaklarla birlikte.