Aşırı pilin hızlı tükenmesinin Android kullanıcıları için akla ilk gelen sorunlardan biri olduğunun farkında olan Google, geliştiricilerin daha az güç tüketen uygulamalar geliştirmesine yardımcı olmak için önemli adımlar atmaktadır. Google Play Store, 1 Mart 2026'da pilin hızlı tükenmesini iyileştirmek için uyanık kalma kilidi teknik kalite işlemlerini kullanıma sunmaya başladı. Bu işlem, önümüzdeki haftalarda etkilenen uygulamalarda kademeli olarak kullanıma sunulacaktır. Android vitals'da "Aşırı Kısmi Uyanık Kalma Kilidi" eşiğini sürekli olarak aşan uygulamaların mağaza girişlerinde uyarılar gösterilmesi ve öneriler gibi keşif yüzeylerinden hariç tutulma gibi mağaza varlıklarında somut etkiler görülebilir.

Uygulamanız kötü davranış eşiğini aşarsa kullanıcılar mağaza girişinizde bir uyarı görebilir. 

Bu girişimle birlikte pil verimliliği, kilitlenme ve ANR gibi kararlılık metriklerinin yanı sıra temel bir Android vitals metriği haline geldi. "Kötü davranış eşiği", son 28 gün içinde ekran kapalıyken % 5'ten fazla kullanıcı oturumunda ortalama en az iki saat boyunca muaf olmayan bir kısmi uyanık kalma kilidi tutma olarak tanımlanır. Sistem tarafından tutulan ve daha fazla optimize edilemeyen net kullanıcı avantajları (ör. ses çalma, konum erişimi veya kullanıcı tarafından başlatılan veri aktarımı) sunan bir uyanık kalma kilidi muaf tutulur. Aşırı sayıda uyanık kalma kilidinin tam tanımını Android vitals dokümanlarımızda bulabilirsiniz.

Android ekosisteminde pil ömrünü iyileştirmeye yönelik devam eden girişimimizin bir parçası olarak binlerce uygulamayı ve kısmi uyandırma kilitlerini nasıl kullandıklarını analiz ettik. Uyandırma kilitleri bazen gerekli olsa da daha verimli çözümler varken uygulamaların bunları verimsiz veya gereksiz bir şekilde kullandığını sık sık görüyoruz. Bu blogda, aşırı uyandırma kilidinin en sık görüldüğü senaryolar ve uyandırma kilitlerini optimize etme önerilerimiz ele alınacaktır.  Arka plan davranışlarını optimize etmek için bu önerilerden yararlanan WHOOP gibi iş ortaklarının bu özellik sayesinde ölçülebilir başarı elde ettiğini gördük.

Ön plan hizmeti kullanma ve kısmi uyandırma kilitleri

Geliştiricilerin, arka planda yürütme sırasında iki kavram arasındaki farkı anlamakta zorlandığını sıklıkla görüyoruz: ön plan hizmeti ve kısmi uyandırma kilitleri.

Ön plan hizmeti, sisteme bir uygulamanın kullanıcı tarafından algılanabilen bir işlem gerçekleştirdiğini ve belleği geri kazanmak için sonlandırılmaması gerektiğini bildiren bir yaşam döngüsü API'sidir. Ancak ekran kapandığında CPU'nun uyku moduna geçmesini otomatik olarak engellemez. Buna karşılık, kısmi uyanık kalma kilidi, ekran kapalıyken bile CPU'nun çalışmaya devam etmesini sağlamak için özel olarak tasarlanmış bir mekanizmadır.

Ön plan hizmeti, kullanıcı işleminin devam etmesi için genellikle gerekli olsa da kısmi uyanık kalma kilidinin manuel olarak alınması yalnızca CPU etkinliği süresince ön plan hizmetiyle birlikte gereklidir. Ayrıca, cihazı uyanık tutan bir API kullanıyorsanız uyanık tutma kilidi kullanmanız gerekmez. 

Gereksiz durumlarda uyanık kalma kilidi edinmemek için hangi aracı kullanmanız gerektiğini iyi anlamak üzere Cihazın uyanık kalmasını sağlamak için doğru API'yi seçme bölümündeki akış şemasına bakın.

Uyanık kalma kilidi alan üçüncü taraf kitaplıkları

Bir uygulamanın, kendi adına hareket eden üçüncü taraf bir SDK veya sistem API'si tarafından tutulan aşırı uyandırma kilitleri nedeniyle işaretlendiğini keşfetmesi yaygın bir durumdur. Bu uyanık kalma kilitlerini belirlemek ve çözmek için aşağıdaki adımları uygulamanızı öneririz:

• Android vitals'ı kontrol edin: Soruna neden olan uyanık kalma kilidinin tam adını aşırı sayıda kısmi uyanık kalma kilidi kontrol panelinde bulun. Bu adın bilinen bir sistem API'si veya Jetpack kitaplığı tarafından oluşturulup oluşturulmadığını görmek için Diğer API'ler tarafından oluşturulan uyanık tutma kilitlerini tanımlama kılavuzuyla çapraz referans yapın. Bu durumda, API kullanımınızı optimize etmeniz gerekebilir ve önerilen kılavuzdan yararlanabilirsiniz.
• Sistem izi yakalama: Uyandırma kilidi kolayca tanımlanamıyorsa sistem izi kullanarak uyandırma kilidi sorununu yerel olarak yeniden oluşturun ve Perfetto kullanıcı arayüzü ile inceleyin. Bunu nasıl yapacağınız hakkında daha fazla bilgiyi Diğer aşırı uyandırma kilidi türlerinde hata ayıklama başlıklı blog yayınımızın ilgili bölümünde bulabilirsiniz.
• Alternatifleri Değerlendirin: Pil ömrüne saygı gösterecek şekilde yapılandırılamayan verimsiz bir üçüncü taraf kitaplığı soruna neden oluyorsa sorunu SDK'nın sahipleriyle paylaşmayı, alternatif bir SDK bulmayı veya işlevselliği şirket içinde oluşturmayı düşünebilirsiniz.

Sık karşılaşılan uyanık kalma kilidi senaryoları

Aşağıda, incelediğimiz bazı özel kullanım alanlarının dökümü ve uyanık kalma kilidi uygulamanızı optimize etmek için önerilen yol yer almaktadır.

Kullanıcı tarafından başlatılan yükleme veya indirme

Kullanım alanı örnekleri: 

• Kullanıcının çevrimdışı erişim için büyük bir dosyanın indirilmesini tetiklediği video akışı uygulamaları.
• Kullanıcının son fotoğraflarını yüklemeyi bir bildirim istemi aracılığıyla tetiklediği medya yedekleme uygulamaları.

Uyanık kalma kilitlerini azaltma: 

• Manuel uyanık kalma kilidi edinmeyin. Bunun yerine User-Initiated Data Transfer (UIDT) API'yi kullanın. Bu, kullanıcı tarafından başlatılan ve uzun süren veri aktarımı görevleri için belirlenen yoldur ve aşırı uyanık kalma kilidi hesaplamalarından muaftır.

Tek Seferlik veya Periyodik Arka Plan Senkronizasyonları

Kullanım alanı örnekleri: 

• Bir uygulama, çevrimdışı erişim için veri getirmek üzere düzenli olarak arka plan senkronizasyonu gerçekleştirir. 
• Adım sayısını düzenli olarak getiren pedometre uygulamaları

Uyanık kalma kilitlerini azaltma: 

• Manuel uyanık kalma kilidi edinmeyin. Bir defalık veya düzenli çalışma için yapılandırılmış WorkManager'ı kullanın. WorkManager, görevleri gruplandırarak sistem sağlığına saygı duyar ve genellikle arka plan güncellemeleri için yeterli olan minimum periyodik aralığa (15 dakika) sahiptir. 
• WorkManager veya JobScheduler tarafından oluşturulan ve yüksek uyanık kalma kilidi kullanımına sahip uyanık kalma kilitleri tespit ederseniz bunun nedeni, çalışanınızı belirli senaryolarda tamamlanmayacak şekilde yanlış yapılandırmış olmanız olabilir. Özellikle STOP_REASON_TIMEOUT ile ilgili çok sayıda hata görüyorsanız çalışanın durdurulma nedenlerini analiz etmeyi düşünebilirsiniz. 

  workManager.getWorkInfoByIdFlow(syncWorker.id)
  .collect { workInfo ->
      if (workInfo != null) {
        val stopReason = workInfo.stopReason
        logStopReason(syncWorker.id, stopReason)
      }
  }

• Çalışan durdurma nedenlerini kaydetmenin yanı sıra çalışanlarınızda hata ayıklama ile ilgili dokümanlarımıza da göz atın. Ayrıca, uyandırma kilitlerinin ne zaman alındığını ve serbest bırakıldığını anlamak için sistem izlerini  toplamayı ve analiz etmeyi de düşünebilirsiniz.
• Son olarak, WHOOP ile yaptığımız başarı öyküsüne göz atın. Bu öyküde, WHOOP'un çalışanlarının yapılandırmasıyla ilgili bir sorunu nasıl keşfettiği ve uyandırma kilidi etkisini önemli ölçüde nasıl azalttığı anlatılıyor.

Bluetooth İletişimi

Kullanım alanı örnekleri: 

• Yardımcı cihaz uygulaması, kullanıcıdan Bluetooth harici cihazını eşlemesini ister.
• Yardımcı cihaz uygulaması, harici bir cihazdaki donanım etkinliklerini ve bildirimde kullanıcı tarafından görülebilen değişiklikleri dinler.
• Yardımcı cihaz uygulamasının kullanıcısı, mobil cihaz ile Bluetooth cihaz arasında dosya aktarımı başlatır.
• Tamamlayıcı cihaz uygulaması, Bluetooth üzerinden harici bir cihazda ara sıra donanım yazılımı güncellemeleri yapar.

Uyanık kalma kilitlerini azaltma: 

• Bluetooth eşleştirmesi sırasında manuel uyanık kalma kilidi almamak için Bluetooth cihazları eşleştirmek üzere ikincil cihaz eşleştirmesini kullanın. 
• Arka planda Bluetooth iletişimi nasıl yapılacağını öğrenmek için  Arka planda iletişim kurma rehberine bakın. 
• Gecikmeli iletişimin kullanıcılar üzerinde etkisi yoksa genellikle WorkManager kullanmak yeterlidir. Manuel uyandırma kilidinin gerekli olduğu düşünülüyorsa uyandırma kilidini yalnızca Bluetooth etkinliği süresince veya etkinlik verilerinin işlenmesi süresince tutun.

Konum İzleme

Kullanım alanı örnekleri: 

• Koşu rotaları çizme gibi, konum verilerini daha sonra yüklemek üzere önbelleğe alan fitness uygulamaları
• Teslimatın ilerleme durumunu bildirim veya widget kullanıcı arayüzünde güncellemek için konum verilerini yüksek sıklıkta çeken yemek teslimatı uygulamaları.

Uyanık kalma kilitlerini azaltma: 

• Konum kullanımını optimize etme ile ilgili rehberimize göz atın. Pil verimliliğini sağlamak için zaman aşımlarını uygulayabilir, konum isteği gruplandırmasından yararlanabilir veya pasif konum güncellemelerini kullanabilirsiniz.
• FusedLocationProvider veya LocationManager API'lerini kullanarak konum güncellemeleri istenirken sistem, konum etkinliği geri çağırması sırasında cihazı otomatik olarak uyandırır. Bu kısa ve sistem tarafından yönetilen uyanık kalma kilidi, aşırı sayıda kısmi uyanık kalma kilidi hesaplamalarından muaftır.
• Konum verilerini önbelleğe almak için ayrı ve sürekli bir uyanık kalma kilidi edinmekten kaçının. Bu işlem gereksizdir. Bunun yerine, konum etkinliklerini bellekte veya yerel depolama alanında kalıcı hale getirin ve bunları belirli aralıklarla işlemek için WorkManager'dan yararlanın.

  override fun onCreate(savedInstanceState: Bundle?) {
    locationCallback = object : LocationCallback() {
        override fun onLocationResult(locationResult: LocationResult?) {
            locationResult ?: return
            // System wakes up CPU for short duration
            for (location in locationResult.locations){
                // Store data in memory to process at another time
            }
        }
    }
}

Yüksek Frekanslı Sensör İzleme

Kullanım alanı örnekleri: 

• Adımları veya kat edilen mesafeyi pasif olarak toplayan adım sayacı uygulamaları. 
• Kaza algılama veya düşme algılama gibi özellikler sunmak için cihaz sensörlerini gerçek zamanlı olarak hızlı değişiklikler açısından izleyen güvenlik uygulamaları.

Uyanık kalma kilitlerini azaltma: 

• SensorManager kullanılıyorsa kullanımı, yalnızca kullanıcı bir kullanıcı arayüzü etkileşimi aracılığıyla açıkça erişim izni verdiğinde ve belirli aralıklarla olacak şekilde azaltın. Yüksek frekanslı sensör izleme, CPU uyandırma ve işleme sayısı nedeniyle pili çok fazla tüketebilir.
• Adım sayısını veya kat edilen mesafeyi takip ediyorsanız SensorManager'ı kullanmak yerine Recording API'den yararlanın ya da verileri pil açısından verimli bir şekilde yakalamak için geçmiş ve toplanmış cihaz adım sayılarına erişmek üzere Health Connect'i kullanmayı düşünün.
• SensorManager ile bir sensör kaydediyorsanız CPU kesintilerinin sıklığını en aza indirmek için sensör gruplamadan yararlanmak üzere 30 saniye veya daha uzun bir maxReportLatencyUs değeri belirtin. Cihaz daha sonra kullanıcı etkileşimi, konum alma veya planlanmış bir iş gibi başka bir tetikleyici tarafından uyandırıldığında sistem, arabelleğe alınan sensör verilerini hemen gönderir.

  val accelerometer = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)

sensorManager.registerListener(this,
                 accelerometer,
                 samplingPeriodUs, // How often to sample data
                 maxReportLatencyUs // Key for sensor batching 
              )

• Uygulamanız hem konum hem de sensör verileri gerektiriyorsa etkinlik alma ve işleme işlemlerini senkronize edin. Sensör okumalarını, sistemin konum güncellemeleri için tuttuğu kısa uyanık kalma kilidine ekleyerek CPU'nun uyanık kalması için uyanık kalma kilidine ihtiyacınız olmasını önlersiniz. Bu birleştirilmiş verilerin yüklenmesini ve işlenmesini sağlamak için bir çalışan veya kısa süreli bir uyanık kalma kilidi kullanın.

Uzaktan Mesajlaşma

Kullanım alanı örnekleri: 

• Yerel ağ kullanılarak bağlanan harici bir cihazda meydana gelen olayları izlemesi gereken video veya ses izleme yardımcı uygulamaları.
• Masaüstü sürümüyle ağ soketi bağlantısı kuran mesajlaşma uygulamaları.

Uyanık kalma kilitlerini azaltma: 

• Ağ etkinlikleri sunucu tarafında işlenebiliyorsa istemcide bilgi almak için FCM'yi kullanın. FCM verilerinin ek olarak işlenmesi gerekiyorsa hızlandırılmış bir çalışan planlamayı seçebilirsiniz. 
• Etkinliklerin bir yuva bağlantısı üzerinden istemci taraflı olarak işlenmesi gerekiyorsa etkinlik kesintilerini dinlemek için uyanık kalma kilidi gerekmez. Veri paketleri kablosuz veya hücresel radyoya ulaştığında radyo donanımı, çekirdek uyandırma kilidi şeklinde bir donanım kesintisi tetikler.Ardından, verileri işlemek için bir çalışan planlamayı veya uyanık kalma kilidi edinmeyi seçebilirsiniz.
• Örneğin, bir ağ yuvasındaki veri paketlerini dinlemek için ktor-network kullanıyorsanız yalnızca paketler istemciye teslim edildiğinde ve işlenmesi gerektiğinde uyanık kalma kilidi edinmelisiniz.

  val readChannel = socket.openReadChannel()
while (!readChannel.isClosedForRead) {
    // CPU can safely sleep here while waiting for the next packet
    val packet = readChannel.readRemaining(1024) 
    if (!packet.isEmpty) {
         // Data Arrived: The system woke the CPU and we should keep it awake via manual wake lock (urgent) or scheduling a worker (non-urgent)
         performWorkWithWakeLock { 
              val data = packet.readBytes()
              // Additional logic to process data packets
         }
    }
}

Özet

Geliştiriciler, arka plan senkronizasyonu, konum izleme, sensör izleme ve ağ iletişimi gibi yaygın kullanım alanları için önerilen bu çözümleri uygulayarak gereksiz uyandırma kilidi kullanımını azaltmaya çalışabilir. Öğrenmeye devam etmek için diğer teknik blog yayınımızı okuyun veya uyanık kalma kilitlerini keşfetme ve hatalarını ayıklama hakkında teknik videomuzu izleyin: Android vitals uyanık kalma kilidi metriğini kullanarak uygulamanızın pil kullanımını optimize etme. Ayrıca, güncellenmiş wakelock dokümanlarımıza da göz atın. Teknik kaynaklarımızı geliştirmeye devam edebilmemiz için lütfen belge geri bildirim anketimizde rehberliğimizle ilgili ek geri bildirimlerinizi paylaşın.