Saya menggunakan Service
Class pada OS Android O.
Saya berencana untuk menggunakan Service
di latar belakang.
The dokumentasi Android menyatakan bahwa
Jika aplikasi Anda menargetkan API level 26 atau lebih tinggi, sistem memberlakukan batasan untuk menggunakan atau membuat layanan latar belakang kecuali jika aplikasi itu sendiri ada di latar depan. Jika suatu aplikasi perlu membuat layanan latar depan, aplikasi tersebut harus memanggil
startForegroundService()
.
Jika Anda menggunakan startForegroundService()
, Service
melempar kesalahan berikut.
Context.startForegroundService() did not then call
Service.startForeground()
Ada apa dengan ini?
android
service
operating-system
foreground
android-8.0-oreo
Orang baik
sumber
sumber
Jawaban:
Dari Google docs di Android 8.0 perubahan perilaku :
Solusi: Panggilan
startForeground()
dionCreate()
untukService
yang Anda gunakanContext.startForegroundService()
Lihat juga: Batas Eksekusi Latar Belakang untuk Android 8.0 (Oreo)
sumber
onStartCommand
metode ini, tetapi saya masih mendapatkan kesalahan ini. Aku meneleponstartForegroundService(intent)
di sayaMainActivity
. Mungkin layanan dimulai terlalu lambat. Saya pikir batas lima detik seharusnya tidak ada sebelum mereka dapat menjanjikan layanan dimulai segera.onStartCommand()
alih-alihonCreate
, karena jika Anda menutup layanan dan memulainya lagi, itu mungkin masukonStartCommand()
tanpa menelepononCreate
...Saya menelepon
ContextCompat.startForegroundService(this, intent)
untuk memulai layanan ituDalam pelayanan
onCreate
sumber
onCreate
dalam 5 detik. Jadi mereka harus mendesain ulang sebelum memaksa kita mengikuti aturan.StopService
setelah meneleponstartForegroundService
.Mengapa masalah ini terjadi adalah karena kerangka kerja Android tidak dapat menjamin layanan Anda memulai dalam waktu 5 detik tetapi di sisi lain kerangka kerja memang memiliki batasan ketat pada pemberitahuan latar depan harus dipecat dalam waktu 5 detik, tanpa memeriksa apakah kerangka kerja telah mencoba untuk memulai layanan .
Ini jelas merupakan masalah kerangka kerja, tetapi tidak semua pengembang yang menghadapi masalah ini melakukan yang terbaik:
startForeground
pemberitahuan harus ada di keduanyaonCreate
danonStartCommand
, karena jika layanan Anda sudah dibuat dan entah bagaimana aktivitas Anda mencoba untuk memulainya lagi,onCreate
tidak akan dipanggil.ID notifikasi tidak boleh 0 jika tidak, crash yang sama akan terjadi walaupun itu bukan alasan yang sama.
stopSelf
tidak boleh dipanggil sebelumnyastartForeground
.Dengan semua hal di atas 3 masalah ini dapat dikurangi sedikit tetapi masih bukan perbaikan, perbaikan nyata atau katakanlah solusinya adalah menurunkan versi target sdk Anda menjadi 25.
Dan perhatikan bahwa kemungkinan besar Android P akan tetap membawa masalah ini karena Google menolak untuk bahkan memahami apa yang sedang terjadi dan tidak percaya ini adalah kesalahan mereka, baca # 36 dan # 56 untuk informasi lebih lanjut
sumber
startForeground
. Mengubahnya menjadi 1 memperbaiki masalah bagi saya (mudah-mudahan)Saya tahu, sudah terlalu banyak jawaban yang telah dipublikasikan, namun kenyataannya adalah - startForegroundService tidak dapat diperbaiki pada tingkat aplikasi dan Anda harus berhenti menggunakannya. Rekomendasi Google untuk menggunakan API Service # startForeground () dalam waktu 5 detik setelah Konteks # startForegroundService () dipanggil bukan sesuatu yang selalu bisa dilakukan oleh suatu aplikasi.
Android menjalankan banyak proses secara bersamaan dan tidak ada jaminan bahwa Looper akan memanggil layanan target Anda yang seharusnya memanggil startForeground () dalam waktu 5 detik. Jika layanan target Anda tidak menerima panggilan dalam 5 detik, Anda kurang beruntung dan pengguna Anda akan mengalami situasi PPA. Di jejak tumpukan Anda, Anda akan melihat sesuatu seperti ini:
Seperti yang saya mengerti, Looper telah menganalisis antrian di sini, menemukan "pelaku" dan hanya membunuhnya. Sistem itu bahagia dan sehat sekarang, sementara pengembang dan pengguna tidak, tetapi karena Google membatasi tanggung jawab mereka pada sistem, mengapa mereka harus peduli pada dua yang terakhir? Rupanya tidak. Bisakah mereka membuatnya lebih baik? Tentu saja, misalnya mereka dapat melayani dialog "Aplikasi sedang sibuk", meminta pengguna untuk membuat keputusan tentang menunggu atau membunuh aplikasi, tetapi mengapa repot, itu bukan tanggung jawab mereka. Yang utama adalah sistemnya sehat sekarang.
Dari pengamatan saya, ini terjadi relatif jarang, dalam kasus saya sekitar 1 crash dalam sebulan untuk pengguna 1K. Mereproduksi itu tidak mungkin, dan bahkan jika direproduksi, tidak ada yang dapat Anda lakukan untuk memperbaikinya secara permanen.
Ada saran yang bagus di utas ini untuk menggunakan "bind" bukannya "start" dan kemudian ketika layanan siap, proses onServiceConnected, tapi sekali lagi, itu berarti tidak menggunakan panggilan startForegroundService sama sekali.
Saya pikir, tindakan yang benar dan jujur dari pihak Google adalah untuk memberi tahu semua orang bahwa startForegourndServcie memiliki kekurangan dan tidak boleh digunakan.
Pertanyaannya tetap: apa yang harus digunakan? Untungnya bagi kami, ada JobScheduler dan JobService sekarang, yang merupakan alternatif yang lebih baik untuk layanan latar depan. Itu pilihan yang lebih baik, karena itu:
Ini berarti bahwa Anda tidak perlu lagi peduli menangani wakelocks dan itulah mengapa itu tidak berbeda dengan layanan latar depan. Dari sudut pandang implementasi, JobScheduler bukan layanan Anda, ini adalah sistem, mungkin akan menangani antrian dengan benar, dan Google tidak akan pernah menghentikan anaknya sendiri :)
Samsung telah beralih dari startForegroundService ke JobScheduler dan JobService di Samsung Accessory Protocol (SAP) mereka. Ini sangat membantu ketika perangkat seperti jam tangan pintar perlu berbicara dengan host seperti ponsel, di mana pekerjaan itu perlu berinteraksi dengan pengguna melalui utas utama aplikasi. Karena pekerjaan diposting oleh penjadwal ke utas utama, itu menjadi mungkin. Namun Anda harus ingat bahwa pekerjaan sedang berjalan di utas utama dan melepas semua tugas berat ke utas lain dan tugas asinkron.
Satu-satunya perangkap beralih ke JobScheduler / JobService adalah Anda harus memperbaiki kode lama, dan itu tidak menyenangkan. Saya telah menghabiskan dua hari terakhir melakukan hal itu untuk menggunakan implementasi SAP Samsung yang baru. Saya akan menonton laporan kerusakan saya dan memberi tahu Anda jika melihat lagi macet. Secara teoritis itu seharusnya tidak terjadi, tetapi selalu ada detail yang mungkin tidak kita sadari.
UPDATE Tidak ada lagi crash yang dilaporkan oleh Play Store. Ini berarti bahwa JobScheduler / JobService tidak memiliki masalah seperti itu dan beralih ke model ini adalah pendekatan yang tepat untuk menghilangkan masalah startForegroundService sekali dan selamanya. Saya harap, Google / Android membacanya dan pada akhirnya akan memberikan komentar / saran / memberikan panduan resmi untuk semua orang.
PEMBARUAN 2
Untuk mereka yang menggunakan SAP dan bertanya bagaimana SAP V2 menggunakan penjelasan JobService ada di bawah ini.
Dalam kode khusus Anda, Anda perlu menginisialisasi SAP (ini Kotlin):
Sekarang Anda perlu mendekompilasi kode Samsung untuk melihat apa yang terjadi di dalamnya. Dalam SAAgentV2 lihat implementasi requestAgent dan baris berikut:
Buka kelas SAAdapter sekarang dan temukan fungsiServiceConnectionRequested yang menjadwalkan pekerjaan menggunakan panggilan berikut:
SAJobService hanyalah sebuah implementasi dari Android'd JobService dan ini adalah salah satu yang melakukan penjadwalan pekerjaan:
Seperti yang Anda lihat, baris terakhir di sini menggunakan Android'd JobScheduler untuk mendapatkan layanan sistem ini dan untuk menjadwalkan pekerjaan.
Dalam panggilan requestAgent kami telah melewati mAgentCallback, yang merupakan fungsi panggilan balik yang akan menerima kontrol ketika peristiwa penting terjadi. Ini adalah bagaimana callback didefinisikan di aplikasi saya:
MessageJobs di sini adalah kelas yang telah saya terapkan untuk memproses semua permintaan yang datang dari smartwatch Samsung. Ini bukan kode lengkap, hanya kerangka:
Seperti yang Anda lihat, MessageJobs membutuhkan kelas MessageSocket juga yang perlu Anda implementasikan dan yang memproses semua pesan yang berasal dari perangkat Anda.
Intinya, ini tidak sesederhana itu dan itu membutuhkan beberapa penggalian untuk internal dan pengkodean, tetapi bekerja, dan yang paling penting - tidak crash.
sumber
JobIntentService
langsung berjalan seperti diIntentService
bawah Oreo, tetapi menjadwalkan Pekerjaan di atas dan di atas Oreo, jadiJobIntentService
jangan langsung mulai. Info lebih lanjutJob...
butuh waktu untuk memulai dan ini adalah versi lanjutan dariAlarmManager
.Aplikasi Anda akan macet jika Anda menelepon
Context.startForegroundService(...)
dan kemudian meneleponContext.stopService(...)
sebelumnyaService.startForeground(...)
dipanggil.Saya punya repro yang jelas di sini ForegroundServiceAPI26
Saya telah membuka bug tentang hal ini di: Pelacak masalah Google
Beberapa bug pada ini telah dibuka dan ditutup tidak akan diperbaiki.
Semoga langkah saya dengan repro yang jelas akan membuat cut.
Informasi disediakan oleh tim google
Pelacak masalah Google, Komentar 36
Ini bukan bug kerangka kerja; disengaja. Jika aplikasi memulai instance layanan
startForegroundService()
, itu harus mentransisikan instance layanan itu ke status latar depan dan menampilkan pemberitahuan. Jika instance layanan dihentikan sebelumstartForeground()
dipanggil, janji itu tidak terpenuhi: ini adalah bug dalam aplikasi.Re # 31 , menerbitkan Layanan yang aplikasi lain dapat memulai secara langsung pada dasarnya tidak aman. Anda dapat mengurangi itu sedikit dengan memperlakukan semua tindakan awal layanan tersebut sebagai persyaratan
startForeground()
, meskipun jelas itu mungkin bukan yang Anda pikirkan.Pelacak masalah Google, Komentar 56
Ada beberapa skenario berbeda yang mengarah pada hasil yang sama di sini.
Masalah semantik langsung, bahwa itu hanyalah kesalahan untuk memulai sesuatu
startForegroundService()
tetapi mengabaikan untuk benar-benar mengalihkannya ke latar depanstartForeground()
, hanya itu: masalah semantik. Itu diperlakukan sebagai bug aplikasi, sengaja. Menghentikan layanan sebelum beralih ke latar depan adalah kesalahan aplikasi. Itulah inti dari OP, dan itulah sebabnya masalah ini telah ditandai "berfungsi sebagaimana dimaksud."Namun, ada juga pertanyaan tentang deteksi palsu dari masalah ini. Bahwa ini adalah diperlakukan sebagai masalah asli, meskipun makhluk itu dilacak secara terpisah dari masalah bug tracker tertentu. Kami tidak tuli terhadap keluhan.
sumber
Saya telah meneliti ini selama beberapa hari dan mendapatkan solusinya. Sekarang di Android O Anda dapat mengatur batasan latar belakang seperti di bawah ini
Layanan yang memanggil kelas layanan
dan kelas layanan harus seperti
sumber
Saya memiliki widget yang melakukan pembaruan yang relatif sering ketika perangkat terjaga dan saya melihat ribuan crash hanya dalam beberapa hari.
Pemicu masalah
Saya bahkan memperhatikan masalah ini bahkan pada Pixel 3 XL saya ketika saya tidak akan berpikir perangkat memiliki banyak beban sama sekali. Dan setiap dan semua jalur kode ditutupi
startForeground()
. Tetapi kemudian saya menyadari bahwa dalam banyak kasus layanan saya menyelesaikan pekerjaan dengan sangat cepat. Saya percaya pemicu untuk aplikasi saya adalah layanan selesai sebelum sistem benar-benar menunjukkan pemberitahuan.Solusi / solusi
Saya bisa menyingkirkan semua crash. Apa yang saya lakukan adalah menghapus panggilan
stopSelf()
. (Saya sedang berpikir untuk menunda berhenti sampai saya cukup yakin notifikasi ditampilkan, tetapi saya tidak ingin pengguna melihat notifikasi jika tidak diperlukan.) Ketika layanan telah menganggur selama satu menit atau sistem menghancurkannya secara normal tanpa membuang pengecualian.sumber
Hanya kepala ketika aku menghabiskan terlalu banyak waktu untuk ini. Saya terus mendapatkan pengecualian ini meskipun saya menelepon
startForeground(..)
sebagai yang pertama masukonCreate(..)
. Pada akhirnya saya menemukan bahwa masalah itu disebabkan oleh penggunaanNOTIFICATION_ID = 0
. Menggunakan nilai lain sepertinya memperbaiki ini.sumber
Saya punya solusi untuk masalah ini. Saya telah memverifikasi perbaikan ini di aplikasi saya sendiri (300K + DAU), yang dapat mengurangi setidaknya 95% dari jenis kerusakan ini, tetapi masih tidak dapat 100% menghindari masalah ini.
Masalah ini terjadi bahkan ketika Anda memastikan untuk memanggil startForeground () tepat setelah layanan dimulai saat Google didokumentasikan. Mungkin karena proses pembuatan dan inisialisasi layanan sudah menghabiskan biaya lebih dari 5 detik dalam banyak skenario, maka kapan pun dan di mana Anda memanggil metode startForeground (), kerusakan ini tidak dapat dihindari.
Solusi saya adalah memastikan bahwa startForeground () akan dieksekusi dalam 5 detik setelah metode startForegroundService (), tidak peduli berapa lama layanan Anda harus dibuat dan diinisialisasi. Inilah solusi terperinci.
Jangan gunakan startForegroundService di tempat pertama, gunakan bindService () dengan flag auto_create. Ini akan menunggu inisialisasi layanan. Ini kodenya, layanan sampel saya adalah MusicService:
Maka di sini adalah implementasi MusicBinder:
Bagian terpenting, implementasi MusicService, metode forceForeground () akan memastikan bahwa metode startForeground () dipanggil tepat setelah startForegroundService ():
Jika Anda ingin menjalankan potongan kode langkah 1 dalam niat yang tertunda, seperti jika Anda ingin memulai layanan latar depan dalam sebuah widget (klik pada tombol widget) tanpa membuka aplikasi Anda, Anda dapat membungkus potongan kode di penerima siaran , dan nyalakan acara siaran alih-alih memulai perintah layanan.
Itu semuanya. Semoga ini bisa membantu. Semoga berhasil.
sumber
Kesalahan ini juga terjadi pada Android 8+ ketika Service.startForeground (int id, Notification notification) dipanggil saat id diatur ke 0.
sumber
Karena semua orang yang berkunjung ke sini menderita hal yang sama, saya ingin membagikan solusi yang tidak pernah dicoba oleh orang lain sebelumnya (dalam pertanyaan ini). Saya dapat meyakinkan Anda bahwa itu berfungsi, bahkan pada breakpoint yang berhenti yang mengkonfirmasi metode ini.
Masalahnya adalah menelepon
Service.startForeground(id, notification)
dari layanan itu sendiri, bukan? Sayangnya, Kerangka Android tidak menjamin untuk memanggilService.startForeground(id, notification)
dalamService.onCreate()
5 detik, tetapi tetap melempar pengecualian, jadi saya datang dengan cara ini.Context.startForegroundService()
Context.startForegroundService()
dari koneksi layanan dan segera panggilService.startForeground()
di dalam koneksi layanan.Context.bindService()
metode di dalam try-catch karena dalam beberapa kesempatan panggilan tersebut dapat menimbulkan pengecualian, dalam hal ini Anda harus mengandalkan panggilanContext.startForegroundService()
langsung dan berharap itu tidak akan gagal. Contoh dapat berupa konteks penerima siaran, namun mendapatkan konteks aplikasi tidak menimbulkan pengecualian dalam kasus itu, tetapi menggunakan konteks secara langsung.Ini bahkan berfungsi ketika saya sedang menunggu breakpoint setelah mengikat layanan dan sebelum memicu panggilan "startForeground". Menunggu antara 3-4 detik tidak memicu pengecualian sementara setelah 5 detik ia melempar pengecualian. (Jika perangkat tidak dapat menjalankan dua baris kode dalam 5 detik, maka sudah waktunya untuk membuangnya di tempat sampah.)
Jadi, mulailah dengan membuat koneksi layanan.
Di dalam layanan Anda, buat binder yang mengembalikan instance layanan Anda.
Kemudian, cobalah untuk mengikat layanan dari konteks itu. Jika berhasil, itu akan memanggil
ServiceConnection.onServiceConnected()
metode dari koneksi layanan yang Anda gunakan. Kemudian, tangani logika dalam kode yang ditunjukkan di atas. Contoh kode akan terlihat seperti ini:Tampaknya berfungsi pada aplikasi yang saya kembangkan, jadi itu harus bekerja ketika Anda mencoba juga.
sumber
Masalah dengan Android O API 26
Jika Anda menghentikan layanan segera (sehingga layanan Anda tidak benar-benar berjalan (kata-kata / pemahaman) dan Anda berada di bawah interval ANR, Anda masih perlu memanggil startForeground sebelum stopSelf
https://plus.google.com/116630648530850689477/posts/L2rn4T6SAJ5
Mencoba Pendekatan Ini Tetapi Masih menciptakan kesalahan: -
Saya Menggunakan ini sampai Kesalahan Terselesaikan
sumber
Saya menghadapi masalah yang sama dan setelah menghabiskan waktu menemukan soluton Anda dapat mencoba kode di bawah ini. Jika Anda menggunakan
Service
maka masukkan kode ini di onCreate menggunakan AndaIntent Service
kemudian masukkan kode ini di onHandleIntent.sumber
Saya telah meneliti masalah ini dan inilah yang saya temukan sejauh ini. Kecelakaan ini dapat terjadi jika kami memiliki kode yang mirip dengan ini:
MyForegroundService.java
MainActivity.java
Pengecualian dilemparkan dalam blok kode berikut:
ActiveServices.java
Metode ini dilaksanakan sebelum
onCreate()
dariMyForegroundService
karena jadwal Android penciptaan layanan pada handler thread utama tetapibringDownServiceLocked
disebut padaBinderThread
, yang merupakan kondisi lomba. Itu berarti bahwaMyForegroundService
tidak memiliki kesempatan untuk meneleponstartForeground
yang akan menyebabkan crash.Untuk memperbaiki ini kita harus memastikan bahwa
bringDownServiceLocked
tidak disebut sebelumnyaonCreate()
dariMyForegroundService
.Dengan menggunakan siaran lengket kami memastikan bahwa siaran tidak tersesat dan
stopReceiver
menerima berhenti niat secepat itu telah terdaftar dionCreate()
dariMyForegroundService
. Saat ini kita sudah meneleponstartForeground(...)
. Kami juga harus menghapus siaran lengket itu untuk mencegah stopReceiver diberitahukan lain kali.Harap dicatat bahwa metode
sendStickyBroadcast
ini sudah usang dan saya menggunakannya hanya sebagai solusi sementara untuk memperbaiki masalah ini.sumber
Begitu banyak jawaban tetapi tidak ada yang berhasil dalam kasus saya.
Saya sudah mulai layanan seperti ini.
Dan dalam layanan saya di onStartCommand
Dan jangan lupa untuk mengatur NOTIFICATION_ID bukan nol
SO semuanya sempurna tetapi masih crash pada 8.1 jadi penyebabnya adalah seperti di bawah ini.
Saya telah menelepon stop foreground dengan menghapus notificaton tetapi sekali pemberitahuan dihapus layanan menjadi latar belakang dan layanan latar belakang tidak dapat berjalan di android O dari latar belakang. dimulai setelah push diterima.
Jadi kata ajaibnya
Sejauh ini alasan apa pun layanan Anda macet, ikuti semua langkah di atas dan nikmati.
sumber
startForeground
seharusnya dipanggilonCreate
?https://developer.android.com/reference/android/content/Context.html#startForegroundService(android.content.Intent)
pastikan Anda memanggil
Service.startForeground(int, android.app.Notification)
onCreate () sehingga Anda memastikan itu akan dipanggil..Jika Anda memiliki kondisi apa pun yang dapat mencegah Anda melakukan itu, maka Anda sebaiknya menggunakan yang normalContext.startService(Intent)
dan meneleponService.startForeground(int, android.app.Notification)
diri sendiri.Tampaknya
Context.startForegroundService()
menambahkan pengawas untuk memastikan Anda meneleponService.startForeground(int, android.app.Notification)
sebelum dihancurkan ...sumber
Tolong jangan panggil StartForgroundServices apa pun di dalam metode onCreate () , Anda harus memanggil layanan StartForground di onStartCommand () setelah membuat utas pekerja jika tidak Anda akan selalu mendapatkan ANR, jadi jangan menulis login kompleks di utas utama onStartCommand () ;
EDIT: Perhatian! fungsi startForeground tidak dapat mengambil 0 sebagai argumen pertama, itu akan memunculkan pengecualian! contoh ini berisi panggilan fungsi yang salah, ubah 0 ke const Anda sendiri yang tidak bisa 0 atau lebih besar dari Max (Int32)
sumber
Bahkan setelah memanggil
startForeground
diService
, itu crash pada beberapa perangkat jika kita sebutstopService
sebelumonCreate
disebut. Jadi, saya memperbaiki masalah ini dengan Memulai layanan dengan bendera tambahan:dan menambahkan tanda centang di onStartCommand untuk melihat apakah sudah mulai berhenti:
PS Jika layanan tidak berjalan, itu akan memulai layanan pertama, yang merupakan overhead.
sumber
Anda harus menambahkan izin sebagai di bawah ini untuk perangkat Android 9 saat menggunakan target sdk 28 atau lebih baru atau pengecualian akan selalu terjadi:
sumber
Saya baru saja memeriksa
PendingIntent
nol atau tidak sebelum memanggilcontext.startForegroundService(service_intent)
fungsi.ini bekerja untuk saya
sumber
panggil saja metode startForeground segera setelah Layanan atau IntentService Dibuat. seperti ini:
sumber
Ok, sesuatu yang saya perhatikan pada hal ini mungkin dapat membantu beberapa orang lain juga. Ini semata-mata dari pengujian untuk melihat apakah saya bisa mencari cara untuk memperbaiki kejadian yang saya lihat. Demi kesederhanaan, katakanlah saya memiliki metode yang memanggil ini dari presenter.
Ini akan macet dengan kesalahan yang sama. Layanan TIDAK akan mulai sampai metode selesai, oleh karena itu tidak ada
onCreate()
dalam layanan.Jadi, bahkan jika Anda memperbarui UI dari utas utama, JIKA Anda memiliki sesuatu yang mungkin menahan metode itu setelah itu, itu tidak akan mulai tepat waktu dan memberi Anda Foreground Error yang ditakuti. Dalam kasus saya, kami memuat beberapa hal ke antrian dan masing-masing memanggil
startForegroundService
, tetapi beberapa logika terlibat dengan masing-masing di latar belakang. Jadi jika logika terlalu lama untuk menyelesaikan metode itu karena mereka dipanggil kembali ke belakang, waktu macet. Yang lamastartService
hanya mengabaikannya dan melanjutkannya dan karena kami menyebutnya setiap kali, babak selanjutnya akan selesai.Ini membuat saya bertanya-tanya, jika saya memanggil layanan dari utas di latar belakang, tidak bisakah itu sepenuhnya terikat pada awal dan berjalan segera, jadi saya mulai bereksperimen. Meskipun ini TIDAK memulainya segera, itu tidak crash.
Saya tidak akan berpura-pura tahu mengapa itu tidak crash meskipun saya curiga ini memaksanya menunggu sampai utas utama dapat menanganinya tepat waktu. Saya tahu itu tidak ideal untuk mengikatnya ke utas utama, tetapi karena penggunaan saya menyebutnya di latar belakang, saya tidak benar-benar khawatir jika menunggu sampai dapat menyelesaikan daripada crash.
sumber
Saya menambahkan beberapa kode dalam jawaban @humazed. Jadi tidak ada notifikasi awal. Ini mungkin merupakan solusi tetapi itu bekerja untuk saya.
Saya menambahkan TransparentColor dalam ikon kecil dan warna pada notifikasi. Itu akan berhasil.
sumber
Saya telah memperbaiki masalah dengan memulai layanan dengan
startService(intent)
alih - alihContext.startForeground()
dan meneleponstartForegound()
segera setelah itusuper.OnCreate()
. Selain itu, jika Anda memulai layanan saat boot, Anda dapat memulai Aktivitas yang memulai layanan pada siaran boot. Meskipun ini bukan solusi permanen, ia bekerja.sumber
Memperbarui Data di
onStartCommand(...)
onBind (...)
onBind(...)
adalah peristiwa siklus hidup yang lebih baik untuk memulaistartForeground
vsonCreate(...)
karenaonBind(...)
melewatiIntent
yang dapat berisi data penting yangBundle
diperlukan untuk menginisialisasiService
. Namun, itu tidak perlu sepertionStartCommand(...)
yang disebut ketikaService
dibuat untuk pertama kalinya atau disebut setelah waktu berikutnya.onStartCommand (...)
startForeground
inonStartCommand(...)
penting untuk memperbaruiService
setelah itu telah dibuat.Kapan
ContextCompat.startForegroundService(...)
dipanggil setelah aService
telah dibuatonBind(...)
danonCreate(...)
tidak dipanggil. Oleh karena itu, data yang diperbarui dapat diteruskan keonStartCommand(...)
melaluiIntent
Bundle
untuk memperbarui data dalamService
.Sampel
Saya menggunakan pola ini untuk menerapkan
PlayerNotificationManager
di aplikasi berita cryptocurrency Coinverse .Activity / Fragment.kt
AudioService.kt
sumber
Layanan
Penguji
Hasil
sumber