Çin Yazılımlarına Yakından Bakış: HyperOS Kısıtlamaları Nasıl Aşılır?

Hızlı Okuma Haritası

HyperOS Kısıtlamalarını ADB ile Aşmak: Kısa Teknik Çerçeve

HyperOS 3; arka plan süreçleri, güç yönetimi ve görsel efektler üzerinde agresif kısıtlamalar uygulayabiliyor. Bu ayarlar pil ömrü ve kararlılık için anlamlı olsa da bazı cihazlarda RAM yönetimi, bildirim sürekliliği, çoklu görev ve arayüz akıcılığını olumsuz etkileyebiliyor.¹

Android Hata Ayıklama Köprüsü (ADB), standart ayarlar ekranında görünmeyen sistem ayarlarına erişmek için kullanılan resmi hata ayıklama aracıdır.³ Bu yazıda HyperOS üzerinde sık kullanılan ADB ve AppOps müdahalelerini, ne işe yaradıklarını, hangi riskleri taşıdıklarını ve nasıl geri alınabileceklerini pratik bir sırayla topluyorum.

ADB Ortamının Hazırlanması

ADB komutlarının sistem üzerinde yürütülebilmesi için öncelikle cihaz ile komut istemcisi arasında güvenli bir köprünün kurulması gerekmektedir. Bu süreç, geleneksel olarak bir kişisel bilgisayar (PC) gerektirse de, günümüz Android ekosisteminde kablosuz hata ayıklama (Wireless Debugging) protokollerinin gelişmesiyle birlikte doğrudan mobil cihaz üzerinden de gerçekleştirilebilmektedir.²

Geleneksel PC kurulumunda, cihazın Geliştirici Seçenekleri (Developer Options) aktif hale getirilmelidir. Bu işlem, Ayarlar > Telefon Hakkında (About phone) menüsü altındaki işletim sistemi sürümüne (OS version) yedi kez dokunularak gerçekleştirilir.² Ardından “USB Hata Ayıklama” (USB Debugging) ve gerekirse “USB üzerinden yükle” (Install via USB) seçenekleri aktif edilir.⁴ Bilgisayar tarafında ise platformlara göre şu bağımlılıklar kurulur:

• Windows Sistemler: Google’ın resmi Android SDK Platform Tools paketi indirilerek C:\platform-tools dizinine çıkarılır. Komut istemi bu dizinde çalıştırılarak cihazın yetkilendirmesi sağlanır.²

1
adb devices

• Mac Sistemler: Homebrew paket yöneticisi kullanılarak terminal üzerinden kurulum sağlanır.²

1
brew install android-platform-tools

• Linux Sistemler: Dağıtımın kendi paket yöneticisi üzerinden bağımlılıklar çözülür.²

1
sudo apt install adb

PC gereksinimini ortadan kaldıran modern ve popüler yöntemlerden biri, yerel ADB veya ADB benzeri istemciler kullanmaktır. Bu bağlamda topluluk tarafından sık tercih edilen araçlar arasında Shizuku, LADB, aShell ve bazı senaryolarda Brevent yer alır.¹

Shizuku, Android 11 ve üzeri cihazlarda kablosuz hata ayıklama özelliği üzerinden PC gerektirmeden başlatılabilir. Root’suz kullanımda Shizuku, cihaza root yetkisi kazandırmaz; bunun yerine ADB kullanıcısının sahip olduğu, standart bir uygulamanın erişemeyeceği bazı sistem yetkileriyle çalışan bir servis sunar. Uygulamalar bu servisle Binder IPC üzerinden iletişim kurarak belirli sistem API’lerine daha kontrollü biçimde erişebilir.⁷

LADB ve aShell ise cihaz üzerinde doğrudan ADB shell komutları çalıştırmaya odaklanan araçlardır. Bu nedenle manuel komut çalıştırma senaryolarında, Shizuku’dan ziyade LADB veya aShell daha doğrudan bir çözüm sunar. Brevent ise temel olarak arka plan uygulama davranışlarını yönetmek için geliştirilmiştir. Bazı komut çalıştırma özellikleri bulunsa da ana işlevi bir ADB terminali olmak değildir.⁵

Kısacası Shizuku, uygulamalar ile ADB yetkisiyle çalışan bir sistem servisi arasında köprü kurarak izin yöneticisi benzeri bir rol üstlenir. LADB ve aShell manuel ADB komutları çalıştırmak için daha uygundur. Brevent ise daha çok arka plan süreçlerini kontrol etmeye odaklanan ayrı bir araçtır.

Görsel İyileştirmeler, UI Mimarisinin Manipülasyonu ve Gelişmiş Dokuların (Advanced Textures) Etkinleştirilmesi

Xiaomi, cihaz portföyünü donanım kapasitelerine göre oldukça keskin çizgilerle sınıflandırmaktadır. Giriş (Entry-level) ve orta segment (Mid-range) cihazlarda, grafik işleme biriminin (GPU) yükünü hafifletmek, arayüz çizimlerinde (render) kare düşmelerini engellemek ve batarya ömrünü optimize etmek amacıyla HyperOS üzerinde bazı görsel özellikler yazılımsal olarak devre dışı bırakılmaktadır.⁸ Kontrol merkezindeki saydamlık yerine kullanılan mat gri arka plan (blur eksikliği), klasör açılışlarındaki eksik animasyonlar, kilit ekranındaki derinlik efektlerinin yokluğu ve basit uygulama geçiş animasyonları bu kısıtlamaların en belirgin örnekleridir.⁸ Ancak, sistemin yapılandırma dosyalarındaki persist.sys (kalıcı sistem özellikleri) değişkenleri ADB üzerinden manipüle edilerek, işletim sisteminin cihazı üst düzey bir amiral gemisi (flagship) olarak algılaması ve ilgili görsel algoritmaları zorla aktif etmesi sağlanabilmektedir.⁵

Kontrol Merkezi Bulanıklığı (Control Center Blur) ve Gelişmiş Görsel Sürüm (Advanced Visual Release)

HyperOS 3, arayüzde estetik bir derinlik ve modern bir hissiyat yaratmak amacıyla “Glassy Blur” (Camsı Bulanıklık) ve “Advanced Textures” (Gelişmiş Dokular) adı verilen gelişmiş işleme tekniklerini kullanır.⁵ Bu özellikler, sistem düzeyinde bir hizmet çağrısı (service call) yapılarak tetiklenebilmektedir. Bu çağrılar, Android’in SurfaceFlinger ve WindowManager bileşenlerine doğrudan emir vererek grafik oluşturma hattını (graphics rendering pipeline) modifiye eder.

Cihazın CPU ve GPU hesaplama seviyelerini (computility) sanal olarak en üst düzeye çıkarmak ve gelişmiş görselleri zorla etkinleştirmek için Shizuku/Brevent veya PC terminali üzerinden aşağıdaki komut dizileri sırasıyla enjekte edilir:

• CPU ve GPU Donanım Seviyesi Algısının Yükseltilmesi: Bu komutlar, işletim sistemine cihazın 6. seviye bir işleme kapasitesine sahip olduğunu bildirir.⁵

1
service call miui.mqsas.IMQSNative 21 i32 1 s16 "setprop" i32 1 s16 "persist.sys.computility.cpulevel 6" s16 "/storage/emulated/0/log.txt" i32 600
2
service call miui.mqsas.IMQSNative 21 i32 1 s16 "setprop" i32 1 s16 "persist.sys.computility.gpulevel 6" s16 "/storage/emulated/0/log.txt" i32 600

• Arka Plan Bulanıklığının Evrensel Olarak Etkinleştirilmesi: Sadece kontrol merkezini değil, ses çubuklarını ve klasör arka planlarını da kapsayacak şekilde bulanıklığı aktif eder.⁵

1
service call miui.mqsas.IMQSNative 21 i32 1 s16 "setprop" i32 1 s16 "persist.sys.background_blur_supported true" s16 "/storage/emulated/0/log.txt" i32 600

• Gelişmiş Dokuların ve Görsel Sürümlerin Devreye Alınması: HyperOS sürümleri arasında farklılıklar mevcuttur.⁵

1
# HyperOS 2
2
service call miui.mqsas.IMQSNative 21 i32 1 s16 "setprop" i32 1 s16 "persist.sys.advanced_visual_release 3" s16 "/storage/emulated/0/log.txt" i32 600
3

4
# HyperOS 3 Glassy Blur
5
service call miui.mqsas.IMQSNative 21 i32 1 s16 "setprop" i32 1 s16 "persist.sys.advanced_visual_release 4" s16 "/storage/emulated/0/log.txt" i32 600

Bu işlemlerin mimari arka planı miui.mqsas.IMQSNative servisine dayanır. Bu servis, Xiaomi’nin sistem analitiği, hata yakalama ve durum denetleyicisi olan MQSAS (MIUI Quality and Stability Analytics Service) çerçevesinin bir parçasıdır. Bu servise yapılan 21 numaralı (i32 1) çağrılar, Android’in alt seviye setprop komutunu çalıştırarak, yeniden başlatma sonrasında bile geçerliliğini koruyan persist (kalıcı) özelliklerini sisteme yazar.⁵ Bu modifikasyonlar sonucunda kontrol merkezinde pürüzsüz bir şeffaflık, Dinamik Ada (Dynamic Island) benzeri bildirim alanlarında estetik bulanıklık efektleri ve tüm UI boyunca kesintisiz animasyonlar açığa çıkar.⁵ Ek olarak, daha pürüzsüz köşe çizimleri ve arayüz gölgeleri için şu komutlar da kullanılabilmektedir:

1
persist.sys.support_view_smoothcorner true
2
persist.sys.mi_shadow_supported true

Donanımsal Darboğazlar, Performans Sorunları ve İkincil Etkilerin Giderilmesi

Görsel zenginliğin zorla etkinleştirilmesi her donanımda kusursuz sonuçlar vermez. Özellikle düşük RAM kapasitesine sahip (örneğin 4 GB veya 6 GB) ve giriş seviyesi MediaTek/Snapdragon işlemciler barındıran cihazlarda, GPU’nun arayüz çizimine yetişememesi UI (kullanıcı arayüzü) kasmalarına, cihazın genel olarak yavaşlamasına (lag) veya alt kısımdan çıkan bildirim pencerelerinin (toast notifications) devasa boyutlarda orantısız bir şekilde ekranda belirmesi gibi ilginç görsel hatalara (glitch) neden olabilmektedir.⁸

Bu tür yan etkilerin ortaya çıkması, sistemin fiziksel donanım kapasitesini aşan bir işleme talebine maruz kaldığını gösterir. Sistem belleği (RAM) sınırına dayandığında, animasyonlardaki bulanıklık efektleri akıcılığı yok eder. Bu durumu yönetmek için görsel kalite ile performans arasında kademeli bir denge kurmak veya ayarları tamamen varsayılana (default) döndürmek gerekir. Bu esneklik, komutlardaki seviyelerin (level) ayarlanmasıyla mümkündür:

• Denge Modu (Gecikmeyi azaltmak için seviye 2 veya 3): Ekranda aşırı kasılma yaşanıyorsa, ancak yine de mat gri arka plan yerine statik bir bulanıklık isteniyorsa, donanım seviyesi 6’dan daha düşük değerlere çekilir. persist.sys.computility.cpulevel 2 (veya 3), persist.sys.computility.gpulevel 2 (veya 3), ve persist.sys.advanced_visual_release 1 özellikleri atanarak daha stabil ve donanımı yormayan bir bulanıklık elde edilebilir.⁵
• Varsayılana Dönüş (Görsel hataları düzeltmek için seviye 0): Eğer ekrandaki “toast notification” boyut hataları devam ederse, klasör açılış animasyonları kaybolursa veya sistem tamamen orijinal (fabrika çıkış) grafik ayarlarına döndürülmek istenirse; cpulevel 0, gpulevel 0, ve advanced_visual_release 0 komutları çalıştırılır ve cihaz yeniden başlatılır.¹²

Sistem Belleği (RAM) Yönetimi ve Agresif Arka Plan Kısıtlamalarının Dizginlenmesi

Xiaomi cihazlarının yazılım mimarisindeki en büyük ve en tarihi eleştiri kaynaklarından biri, saldırgan bellek yönetimi (RAM Management) ve uygulamaların arka planda çalışmasını engelleyen güç tasarruf algoritmalarıdır. HyperOS 3, selefi MIUI 14’e kıyasla sistem belleğini çok daha agresif bir şekilde boşaltarak pil ömrünü maksimize etmeye programlanmıştır.¹ Bu durum, özellikle arka planda müzik çalan uygulamaların, GPS takibi yapan navigasyon araçlarının veya anlık bildirim gerektiren mesajlaşma servislerinin sık sık sistem tarafından acımasızca kapatılmasına (kill) yol açar. Sistemin bu işleyişten sorumlu olan ana bileşeni, çekirdek düzeyinde yetkilendirilmiş com.miui.powerkeeper (PowerKeeper) paketidir.¹

PowerKeeper Modülünün Kısıtlanması (AppOps Kullanımı)

Standart Android işletim sisteminde bellek yönetimi “Low Memory Killer” (LMK) algoritması tarafından pürüzsüz bir şekilde yapılırken, Xiaomi bu sürece PowerKeeper ile katı kurallar koyarak müdahale eder. Kullanıcıların RAM sorununu çözmek için genel eğilimi, sorun yaratan modülleri sistemden tamamen silmektir (ADB üzerinden pm uninstall). Ancak PowerKeeper’ın sistemden tamamen silinmesi, batarya optimizasyonunun kontrolsüz kalmasına, bazı cihazlarda kararlılık sorunlarına yol açabileceği gibi, OTA sistem güncellemeleri sonrasında cihazın öngörülemeyen davranışlar sergilemesine veya bootloop risklerine de zemin hazırlayabilir.¹

Bu sorunu root (kök) erişimi gerektirmeden, cihazı riske atmadan ve sistem bütünlüğünü bozmadan çözmenin en zarif yolu, Android’in gizli izin yönetim çerçevesi olan AppOps (Application Operations) mekanizmasını kullanmaktır.¹ AppOps, standart kullanıcı izinlerinden (Kamera, Konum, Mikrofon vb.) tamamen bağımsız olarak sistem servislerinin ve uygulamaların arka plan ayrıcalıklarını atomik düzeyde düzenler. PowerKeeper’ın RAM’i temizleme yetkilerini kökünden budamak için terminal üzerinden şu üç kritik komut çalıştırılır:

1
adb shell appops set com.miui.powerkeeper WRITE_SETTINGS deny
2
adb shell appops set com.miui.powerkeeper GET_USAGE_STATS deny
3
adb shell appops set com.miui.powerkeeper RUN_IN_BACKGROUND deny

Bu komut setinin temel işleyiş mekanizması oldukça akıllıcadır; PowerKeeper’ın arka planda aktif olan uygulamaların kaynak tüketim verilerini ve kullanım istatistiklerini (USAGE_STATS) görmesi tamamen engellenir.¹ Sistemin hangi uygulamanın ne kadar güç harcadığını göremeyen PowerKeeper, bu uygulamaları durdurmak için gerekli olan sistem konfigürasyonunu değiştirme (WRITE_SETTINGS) yetkisinden de mahrum bırakılır. Son adımda ise doğrudan arka planda çalışma yetkisi (RUN_IN_BACKGROUND) reddedilerek servis dondurulur.¹ Kısacası modül sistemden silinmez, ancak “kör” ve “felçli” bırakılır.¹ Bu sayede RAM yönetimi MIUI’nin/HyperOS’un yapay ve agresif kısıtlamalarından kurtularak saf Android’in (AOSP) kendi yerel, daha dengeli LMK algoritmasına bırakılır. Kullanıcı testleri, bu işlemin cihazın bootloop’a düşme riskini kesinlikle barındırmadığını ve bellek yönetiminde devasa bir iyileşme sağladığını teyit etmektedir.¹ (Not: İsteyen kullanıcılar bu işlemi App Manager veya Brevent içerisindeki arayüzden manuel olarak “Disable” ederek de gerçekleştirebilirler ¹).

Hayalet Süreçler (Phantom Processes) ve Çoklu Görev Kapasitesinin Genişletilmesi

Android 12 ile birlikte (ve HyperOS’un temelini oluşturan güncel Android çekirdeklerinde), sistemin kararlılığını sağlamak ve batarya sömürüsünü önlemek için arka plan işlemlerini sınırlandıran yeni bir yapı getirilmiştir. Bu yapı Activity Manager (Etkinlik Yöneticisi) tarafından sıkı bir şekilde denetlenir ve “phantom processes” (hayalet süreçler) limiti sistem genelinde genellikle 32 ile sınırlandırılır.⁷ Hayalet süreçler, uygulamaların kendi iç işleyişlerini sağlamak için yarattıkları yan süreçlerdir (child processes).

Bu 32’lik limit, standart bir kullanıcı için sorun teşkil etmese de ağır çoklu görevler (multitasking) yürüten, terminal emülatörleri (Termux) kullanan veya Nintendo/PlayStation emülatörleri gibi yoğun kaynak gerektiren, çok iş parçacıklı (multi-threaded) uygulamalar çalıştıran kullanıcılar için bir kâbusa dönüşebilir.¹ Sistem, limit aşıldığında aktif uygulamanın yan süreçlerini sürekli olarak öldürdüğü için performansta çökmeler ve anlık kapanmalar yaşanır. Yeni HyperOS 3 “Sentinel” (Nöbetçi) bellek yöneticisinin emülatörleri zorla kapatması tam olarak bu mekanizmadan kaynaklanmaktadır.¹

ADB üzerinden device_config aracı kullanılarak sistemin derinliklerindeki bu kısıtlayıcı sınır manuel olarak artırılabilir.

Limiti artırma:⁷

1
adb shell device_config put activity_manager max_phantom_processes 512

Mevcut durumu kontrol etme: Eğer çıktı null dönerse, sistem varsayılan 32 limitini kullanıyor demektir.⁷

1
adb shell device_config get activity_manager max_phantom_processes

Varsayılana döndürme:⁷

1
adb shell device_config delete activity_manager max_phantom_processes

Bu ayarlama, özellikle HyperOS 3 üzerinde oyun oynayan ve aynı anda kayıt alan/yayın yapan kullanıcılar için performans stabilitesi sağlayan en hayati ADB müdahalelerinden biridir. Gelişmiş donanımların sınırlarını belirleyen bu yazılımsal tavan, tamamen ortadan kaldırılmış olur.

Batarya Tüketimi (Idle Discharge) Problemleri ve Wakelock Optimizasyonları

Gelişmiş donanımlara sahip akıllı telefonlarda ekran kullanım süresi (SOT - Screen On Time) kadar kritik olan bir diğer metrik, cihaz ekranı kapalı ve bekleme modundayken harcanan enerji miktarıdır. HyperOS 3 güncellemelerinin ardından birçok cihazda (özellikle MediaTek Dimensity işlemcili amiral gemilerinde) ekran kapalı durumdayken bataryanın hızla tükenmesi (severe idle discharge) sorunu rapor edilmiştir.² Detaylı sistem analizleri, bu devasa deşarjın temelinde ağ servislerinin gereksiz arka plan işlemleri ve “wakelock” adı verilen uyku engelleme algoritmalarının yattığını göstermektedir. Wakelock, işletim sisteminin veya belirli uygulamaların, ekran kapalı olsa dahi CPU’yu “Doze” (Derin Uyku) modundan çıkararak uyanık tutmasını ve yüksek saat hızlarında (clock speed) çalışmaya zorlayarak bataryayı sömürmesini sağlayan çekirdek (kernel) çağrılarıdır.²

Sorunun bilimsel bir teşhisi için ADB terminali kullanılarak detaylı batarya döküm istatistikleri bilgisayara aktarılır.²

1
adb shell dumpsys batterystats > battery_stats.txt

Bu döküm metni incelendiğinde (Screen off discharge, Idle mode full time, Top wakelocks gibi metrikler) yüksek deşarja sebep olan dört ana unsur tespit edilmiştir:

• VoLTE tabanlı telekomünikasyon (telephony-radio) uyanıklık kilitleri,
• Uyku (Doze) modunu delen ve sürekli veri akışı arayan Facebook arka plan servisleri,
• Google Play Services döngüleri,
• MediaTek işlemcilerin agresif ağ izleme döngülerinden kaynaklı HyperOS 3’e özgü WiFi Multicast wakelock’ları.²

VoLTE Radyo Döngülerinin (Wakelock) Engellenmesi

Birçok HyperOS 3 kullanıcısının batterystats analizinde, telekomünikasyon radyosu uyanıklık sürelerinin (telephony-radio wakelock) 24 saatlik döngüde 1,5 saati aşarak bataryanın %30’undan fazlasını tek başına sömürdüğü görülmektedir.² Eğer kullanıcının bulunduğu bölgede veya telekom operatöründe 3G/2G altyapısı hala aktif bir geri dönüş (fallback) senaryosu olarak çalışıyorsa ve yüksek kaliteli 4G ses aramasına (VoLTE) mutlak bir gereksinim duyulmuyorsa, VoLTE kapatılarak bekleme modundaki telefoni batarya tüketimi olağanüstü derecede (yaklaşık %98 oranında) düşürülebilmektedir.²

Bölgeye ve yazılıma (Global ROM veya EU ROM) bağlı olarak VoLTE denetimi arayüzde gizlenmiş olabilir. Bu kısıtlamayı aşmak için cihazın arama ekranına (dialer) *#*#86583#*#* (Avrupa/EU cihazları) veya ##86583## (bazı Global cihazlar) kodu girilir.² Ekranda “VoLTE Carrier check was disabled” uyarısı belirdikten sonra Ayarlar -> SIM Kartlar ve Mobil Ağlar menüsü altında beliren “Aramalar için 4G kullan” veya doğrudan “VoLTE” seçeneği kapatılır.²

Doze Modu Beyaz Listesinin (Whitelist) Düzenlenmesi ve GMS Kısıtlamaları

Android işletim sistemi, telefon hareketsiz kaldığında güç tüketimini en aza indiren “Doze” (Derin Uyku) moduna sahiptir. Ancak Xiaomi, kendi iş ortaklıkları ve ekosistem hedefleri doğrultusunda, yazılıma gömülü bazı arka plan hizmetlerini varsayılan olarak bu derin uykuyu delebilecek beyaz listeye (whitelist) eklemiştir. Cihazda Facebook uygulaması hiçbir zaman kullanılmasa veya silinmiş olsa dahi, gömülü gelen (stub) Facebook servis ve yöneticileri com.facebook.services ve com.facebook.appmanager sürekli olarak Doze modunu delerek arka planda internete bağlanmaya çalışır ve işlemciyi uyandırır.²

Bu kronik batarya düşmanlarının uyku modundan muafiyetlerini kaldırmak için ADB üzerinden cihazın bekleme (idle) servisine müdahale edilir ve paketler beyaz listeden zorla çıkarılır:

1
adb shell dumpsys deviceidle whitelist -com.facebook.services
2
adb shell dumpsys deviceidle whitelist -com.facebook.appmanager

Ek olarak, Android ekosisteminin can damarı olan ancak aynı zamanda en büyük kaynak tüketicilerinden biri olan Google Play Services (GMS) ve Google Services Framework (GSF), arka planda sürekli konum, senkronizasyon, reklam kimliği ve push bildirim kontrolü yapar. Bu servislerin tamamen kapatılması cihazı kullanılmaz hale getirecektir. Ancak bu servislerin bekleme (standby) havuzunda “nadir” (rare) öncelik durumuna çekilmesi, güç tasarrufunda devasa kazanımlar sunar:

1
adb shell am set-standby-bucket com.google.android.gms rare
2
adb shell am set-standby-bucket com.google.android.gsf rare

Bu am set-standby-bucket komutları, servislerin hayati fonksiyonlarını engellemeden cihaz uyku modundayken Google servislerinin işlemciyi dürtme sıklıklarını dramatik ölçüde seyrekleştirir.² Arka planda aktif olarak neyin çalıştığını ve ne kadar bellek sömürdüğünü gerçek zamanlı görmek isteyen kullanıcılar en üstteki 30 RAM tüketicisini listeleyebilirler.⁷

1
adb shell dumpsys meminfo | head -n 30

Sistem Uygulamalarının Arındırılması (Debloat), Telemetri Engelleme ve İşletim Sistemi Kararlılığı (Stability)

Markaların cihaz maliyetlerini sübvanse etmek, kullanıcı alışkanlıklarını analiz ederek gelir modellerini (örneğin reklam ağları) genişletmek için sisteme entegre ettiği ve normal yollarla silinemeyen uygulamalara “bloatware” (şişkin/gereksiz yazılım) denir.³ HyperOS 3, genel Android çerçevesini kullanmasına karşın; içerisinde çekirdeğe kadar nüfuz etmiş telemetri servisleri (veri toplama araçları), dinamik reklam gösterim modülleri (MSA), kullanıcı veri takibi paketleri ve gereksiz üretici uygulamaları (Mi Video, Mi Browser, App Vault) barındırır.¹

GUI Araçları ve Komut Satırı ile Paket Yönetimi (Package Manager - pm)

Geleneksel inanca göre kök (root) erişimi olmadan sistem uygulamalarının silinemeyeceği düşünülse de, Android’in yapısı gereği ADB üzerinden Paket Yöneticisi (pm) kullanılarak bu servisler aktif kullanıcı profilinden (genellikle user 0) tamamen izole edilebilir veya dondurulabilir.⁴ Günümüzde bu işlemleri komut satırına kod yazmadan, mobil üzerinden görsel bir arayüzle (GUI) yapmayı sağlayan açık kaynaklı araçlar büyük popülerlik kazanmıştır. Bunların başında UAD (Universal Android Debloater), Shizuku destekli Canta uygulaması ve doğrudan HyperOS’un karmaşık mimarisine özel olarak geliştirilen, bootloop risklerini analiz edip 200’den fazla servisi tek tıkla temizleyen “hyperos-debloater” (ovsky) gibi script/yazılım çözümleri gelmektedir.⁶ Canta gibi uygulamalar, Shizuku yetkilerini kullanarak Android 16 önizleme sürümlerinde dahi (HyperOS 3.1) sorunsuz çalışmaktadır.⁹

Manuel terminal işlemleri tercih edildiğinde, sistemi arındırmak için ADB üzerinde iki temel mekanizma mevcuttur:

• Kullanıcı Bazlı Devre Dışı Bırakma (Disable): Uygulamayı sistemde dondurur. Cihazın belleğinden fiziksel olarak silinmez ancak çalıştırılamaz hale gelir.⁴

1
adb shell pm disable-user --user 0 package-name

• Kullanıcı Alanından Tamamen Kaldırma (Uninstall): Uygulamayı geçerli birincil kullanıcı profilinden kökten kaldırır. Kritik nokta -k argümanıdır; uygulamanın önbellek ve yapılandırma dizinlerini sistemde korur.¹

1
adb shell pm uninstall -k --user 0 package-name

• Geri Yükleme: Kullanıcının fikrini değiştirmesi veya sistemin bu uygulamaya bağımlı olduğunun anlaşılması durumunda uygulama veri kaybı olmadan geri yüklenebilir.¹

1
adb shell pm install-existing --user 0 package-name

Debloat Stratejileri: Güvenli, Dengeli ve Agresif Profiller

Sistemden uygulamaların rastgele ve bilinçsizce kaldırılması, cihazın sonsuz açılış döngüsüne (bootloop) girmesine veya çekirdek fonksiyonların çökmesine neden olabilir. Bu sebeple geliştirici toplulukları paketleri risk seviyelerine göre “Güvenli” (Safe), “Dengeli” (Balanced) ve “Agresif” (Aggressive) olmak üzere üç profile ayırmışlardır.⁴ Güvenli profil sadece ortak bloatware’i (reklam servisleri, Amazon uygulamaları) kaldırırken, Agresif profil sistem özelliklerini sağlayan Xiaomi altyapısını da budar.

Aşağıdaki sade tablo, paket isimlerini ezberlemek yerine karar verirken bakılacak risk gruplarını özetler:

Paket bazında daha güncel ve topluluk tarafından sınıflandırılmış güvenli liste için Universal Android Debloater Next Generation reposundaki Universal Debloat List referans alınabilir. UAD-ng, root gerektirmeden ADB ile gereksiz sistem uygulamalarını kaldırmaya odaklanan çapraz platform bir araçtır ve paket listesini GitHub üzerinden güncel tutar.²⁸

Öte yandan, telemetri ve sistem hizmetleri paketlerinin (MSA, Daemon, Analytics vb.) güvenli bir şekilde dezenfekte edilmesi doğrudan batarya ömrünü artırır, cihazın arka plan RAM sızıntılarını (memory leaks) önler ve sunucularla sürekli iletişim kuran arka plan işlemlerini keserek kullanıcının ağ verisi ile mahremiyetini garanti altına alır.¹ Hata sonucu kaldırılan ve kritik işlevleri bozan uygulamaların (örneğin sistem güncellemeleri için com.miui.cloudservice ve com.xiaomi.xmsf) restore edilmesi için pm install-existing komutu bir emniyet sübabı işlevi görür.⁴

Panel Hızı Limitlemesini Kaldırma ve Görsel Performans Ayarları

Mobil cihaz panellerinde yüksek yenileme hızları (120Hz, 144Hz) her ne kadar pürüzsüz bir kaydırma (scrolling) ve genel sistem akıcılığı deneyimi sunsa da, üreticilerin panele entegre ettiği dinamik değişken yenileme (Dynamic Refresh Rate) veya LTPO algoritmaları, batarya tasarrufu adına bu hızları sürekli manipüle eder.²³ HyperOS, belirli uygulamalarda (örneğin YouTube video arayüzü, TikTok, Netflix veya kare hızı optimize edilmemiş oyunlarda) ekranın yenileme hızını acımasızca 60Hz veya 90Hz değerine düşürebilmektedir.²³

Ekran Yenileme Hızını Maksimum Seviyede Sabitleme (Force 120Hz)

HyperOS arayüzündeki standart “Ekran ve Parlaklık” ayarlarında yenileme hızını “Özel” (Custom) modunda 120Hz olarak seçmek bile, yazılımın kendi içindeki istisna listelerini (whitelist/blacklist) ve pil tasarrufu kısıtlamalarını tamamen atlatmak için çoğu zaman yeterli olmamaktadır.²³ İşletim sistemindeki ekran paneli kontrolcülerini (display controllers) evrensel olarak ezip geçmek ve tüm uygulamalarda, menülerde ve arayüz içi geçişlerde istisnasız maksimum kare hızı elde etmek (Force 120Hz) için, Android işletim sisteminin settings put system veritabanı altyapısı kullanılır.

Terminal, Brevent veya SetEdit (Ayarlar Veritabanı Düzenleyicisi - Settings Database Editor) uygulaması üzerinden şu çekirdek komutlar sisteme enjekte edilir:

1
# Minimum yenileme hızı eşiğini kaldırma
2
adb shell settings put system min_refresh_rate 0
3

4
# Maksimum yenileme hızını 120Hz'e kilitleme
5
adb shell settings put system peak_refresh_rate 120

HyperOS’un bazı güncel varyantlarında veya farklı UI katmanlarında panel kilidini açmak için 0.1 değeri de denenmektedir.²⁶

Ayrıca cihaz üzerinden doğrudan çalışan SetEdit uygulaması kullanılarak sistem kayıt defterindeki “user_refresh_rate” parametresi aranır. Bu parametrenin değeri manuel olarak “1” (zorlanmış 120Hz modu) ile değiştirilip kaydedildiğinde, işletim sisteminin kendi arayüzü ile panel donanımı arasındaki enerji tasarrufu diyaloğu (handshake) kesilir.²⁴ YouTube veya TikTok gibi platformlara girildiğinde dahi ekran 120Hz seviyesinde kilitli kalır.²⁵ Bu tür agresif bir müdahale, pil tüketim eğrisini doğal olarak hızlandırsa da, her senaryoda amiral gemisi pürüzsüzlüğü elde etmeyi garanti eder.²⁴

MIUI Optimizasyonunun Çerçevesi ve Etkileri

Pek çok ileri düzey sistem modifikasyonunun, üçüncü parti gelişmiş uygulama paketleyicilerinin (örneğin reklam engelleyici YouTube istemcileri olan Vanced/ReVanced veya sistem genelini değiştiren gelişmiş UI temalarının) cihaza düzgün kurulabilmesi ve çalışabilmesi için, sistem çekirdeğine entegre edilmiş olan “MIUI Optimizasyonu” servisinin bir engele dönüşmesi söz konusudur.²⁹

Geliştirici seçeneklerinin derinliklerinde yer alan bu düğmeyi devre dışı bırakmak, sistemin saf Android Açık Kaynak Projesi (AOSP) davranışlarına büyük ölçüde dönmesini ve Xiaomi’nin APK paketleyici (Package Installer) bütünlük denetimlerinin zayıflamasını sağlar. MIUI Optimizasyonu kapandığında arka plan bellek yönetimindeki agresiflik kısmen düşse de; arayüzdeki pencere animasyonlarında (window transition) düzensizlikler, bildirim ikonlarında veya kare çerçevelerinde bozulmalar, metin kutularında hizalama sorunları görülebileceği göz önünde bulundurulmalıdır. Çoğu modern senaryoda, UAD veya Canta üzerinden bloatware arındırması ve AppOps ile PowerKeeper’ın kısıtlanması kombinasyonu, MIUI optimizasyonunu tamamen kapatmaktan çok daha stabil ve estetik bir sonuç yaratmaktadır.

Sonuç

HyperOS 3, Xiaomi cihazlarda güç tüketimini kontrol altında tutmak ve sistem kararlılığını korumak için oldukça agresif arka plan politikaları kullanır. Ancak bu yaklaşım, özellikle uygun fiyatlı (uygun fiyatlı olma nedeninden biri bloatware ve telemetri) ama güçlü donanıma sahip cihazlarda performansın tam olarak ortaya çıkmasını engelleyebilir. Bloatware, telemetri servisleri ve arka planda çalışan gereksiz süreçler de kullanıcı deneyimini olumsuz etkileyen önemli faktörlerdir.

Bu raporda ele alınan ADB, Shell ve AppOps tabanlı optimizasyonlar; cihazın donanım potansiyelini daha verimli kullanmayı, arka plan süreçlerini kontrol altına almayı ve gereksiz servislerin etkisini azaltmayı amaçlar. Özellikle PowerKeeper gibi sistem bileşenlerini tamamen kaldırmak yerine AppOps ile yetkilerini sınırlamak, bootloop veya sistem kararsızlığı riskini azaltan daha güvenli bir yöntemdir.

Benzer şekilde hayalet süreç limitlerinin artırılması, gereksiz paketlerin user 0 üzerinden devre dışı bırakılması ve bazı görsel/performans ayarlarının düzenlenmesi cihazı daha akıcı hale getirebilir. Fakat bu işlemler yapılırken performans ile kararlılık arasındaki denge mutlaka korunmalıdır. Joyose gibi ısıl denetimle ilişkili servislerin veya OTA güncellemeleri için gerekli paketlerin bilinçsizce kaldırılması, uzun vadede cihazın stabilitesini bozabilir.

Sonuç olarak HyperOS 3 üzerinde root erişimi olmadan da kullanıcı deneyimini iyileştirmek mümkündür. Shizuku tabanlı araçlar, Canta, UAD ve benzeri açık kaynak çözümler sayesinde bu işlemler artık yalnızca komut satırı bilen kullanıcılara değil, daha geniş bir kitleye de ulaşabilir hale gelmiştir. Yine de her optimizasyonun bilinçli uygulanması ve cihazın güvenliği ile kararlılığının ön planda tutulması gerekir.

Kaynaklar

Metindeki üst simge numaraları aşağıdaki kaynak sırasına karşılık gelir. Linkler doğrudan ilgili Reddit, GitHub, Xiaomi veya topluluk sayfalarına gider.

• Solve Xiaomi’s RAM management problem without rooting, without a custom ROM, without uninstalling PowerKeeper, and without any negative consequences or inconveniences. : r/HyperOS - Reddit
• [GUIDE] Fixed Severe Idle Discharge After HyperOS 3 Update …
• hyperos-debloat · GitHub Topics
• matthieu-pierson/debloat-hyperos-adb: ADB commands to aggressively de-bloat HyperOS Android Phones without root. - GitHub
• Enable Advanced Textures + Blur on any Xiaomi device! (NO ROOT …
• [DEV] I built an open-source, single-click, no-root debloater for HyperOS and MIUI that safely removes 200+ bloatware services. : r/PocoPhones - Reddit
• Fix Hyper OS Performance issues and aggressive RAM … - Reddit
• ENABLE BLUR, ANIMATIONS AND ADVANCED TEXTURE ON ANY XIAOMI DEVICE!!! : r/HyperOS - Reddit
• Debloat HyperOS 3 - Reddit
• i applied the new method on how to achieve the blur in my rn 13 pro 4g but it kinda lags. How can i fix the lag? : r/HyperOS - Reddit
• advance setting! : r/HyperOS - Reddit
• Advanced textures without root, tested on Hyper OS 2.0. : r/HyperOS - Reddit
• Enable Premium HyperOS 3.1 Features in your All Xiaomi, Redmi, Poco Phones - YouTube
• Control centre blur : r/HyperOS - Reddit
• AG removed from system whitelist on HyperOS · Issue #6073 · AdguardTeam/AdguardForAndroid - GitHub
• debloat-hyperos-adb/debloat_balanced.txt at main - GitHub
• I disabled the most controversial system packages and here’s what happened : r/HyperOS
• Can confirm that removing MSA and MIUI Daemon doesn’t cause any problems. - Reddit
• [DEV] I built an open-source, single-click, no-root debloater for HyperOS and MIUI that safely removes 200+ bloatware services. - Reddit
• MIUI 13/14 bloatware apps, updated at 20240816 - GitHub Gist
• Newest Questions - Page 290 - Android Enthusiasts Stack Exchange
• gaming performance, joyose power draw, throttling, jitter, frame drops, FPS stability. Xiaomi should rework their throttling for more stability. : r/PocoPhones - Reddit
• Redmi Note 14 Pro: How to Force 120Hz Refresh Rate - YouTube
• Xiaomi - Force Enable 120Hz All The Time / Enable 90Hz Mode - YouTube
• Enable 120Hz Everywhere All The Time! - Xiaomi, Redmi & Poco - YouTube
• Found how to force all apps on 120hz/fps with adb !!! : r/Galaxy_S20 - Reddit
• Force 120hz using adb resets for no reason - OnePlus Community
• Universal-Debloater-Alliance/universal-android-debloater-next-generation - GitHub
• Xiaomi Community | Xiaomi