*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 <[email protected]> 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
