*bump* It seems that the implementation of startForeground() delegates to this code:
public void setServiceForeground(ComponentName className, IBinder token, 1781 <#127f1bc903f2e1c4_l1781> int id, Notification notification, boolean removeNotification) throws RemoteException { 1782 <#127f1bc903f2e1c4_l1782> Parcel data = Parcel.obtain(); 1783 <#127f1bc903f2e1c4_l1783> Parcel reply = Parcel.obtain(); 1784 <#127f1bc903f2e1c4_l1784> data.writeInterfaceToken(IActivityManager.descriptor); 1785 <#127f1bc903f2e1c4_l1785> ComponentName.writeToParcel(className, data); 1786 <#127f1bc903f2e1c4_l1786> data.writeStrongBinder(token); 1787 <#127f1bc903f2e1c4_l1787> data.writeInt(id); 1788 <#127f1bc903f2e1c4_l1788> if (notification != null) { 1789 <#127f1bc903f2e1c4_l1789> data.writeInt(1); 1790 <#127f1bc903f2e1c4_l1790> notification.writeToParcel(data, 0); 1791 <#127f1bc903f2e1c4_l1791> } else { 1792 <#127f1bc903f2e1c4_l1792> data.writeInt(0); 1793 <#127f1bc903f2e1c4_l1793> } 1794 <#127f1bc903f2e1c4_l1794> data.writeInt(removeNotification ? 1 : 0); 1795 <#127f1bc903f2e1c4_l1795> mRemote.transact(SET_SERVICE_FOREGROUND_TRANSACTION, data, reply, 0); 1796 <#127f1bc903f2e1c4_l1796> reply.readException(); 1797 <#127f1bc903f2e1c4_l1797> data.recycle(); 1798 <#127f1bc903f2e1c4_l1798> reply.recycle(); 1799 <#127f1bc903f2e1c4_l1799> } Which isn't all that more helpful ;-( I don't see that it messes with priorities either. But then I also don't see the actual implementation of making this foreground/background service more unkillable. It seems just to be the IPC code. Any ideas? On Thu, Apr 8, 2010 at 6:40 PM, Mariano Kamp <mariano.k...@gmail.com> wrote: > Hi. > > I updated my app to use the "new" startForeground() method of Service. Now > beta testers are complaining about the foreground app going slow. Is that a > coincidence or does startForeground() mess with the thread's prio or does > anything else but what is written below? > > Just as an additional information the background activity does some > syncing, reports the progress to the notification using remote views and as > it is not latency dependent I use (and did that before already) > this: Process.setThreadPriority(Process.THREAD_PRIORITY_LOWEST); > > Should I use another Priority? And if it makes any difference, how does > that play with Android 1.5 devices? > > Cheers, > Mariano > > http://developer.android.com/reference/android/app/Service.html#startForeground(int, > android.app.Notification)<http://developer.android.com/reference/android/app/Service.html#startForeground(int,+android.app.Notification)> > > Make this service run in the foreground, supplying the ongoing notification > to be shown to the user while in this state. By default services are > background, meaning that if the system needs to kill them to reclaim more > memory (such as to display a large page in a web browser), they can be > killed without too much harm. You can set this flag if killing your service > would be disruptive to the user, such as if your service is performing > background music playback, so the user would notice if their music stopped > playing. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en