Also, if the service is not showing up as a running service in manage apps,
then that should mean that it is not started, so it it is created that is
because something has bound to it. You can see what is bound to it with
those shell commands. If it is not started, the only reason it would be
recreated is because another process continue to be bound to it after its
process is killed.
On Sat, Aug 11, 2012 at 11:21 AM, Dianne Hackborn <hack...@android.com>wrote:
> Unless the service has something bound to it or it is started, it will not
> be re-created.
>
> You can look at the service state with "adb shell dumpsys activity
> services" or "adb shell dumpsys activity service <package_name or
> service_name>". If your service is listed there, it will show you what its
> current state is -- what is bound to it, whether it is started, etc.
>
>
> On Fri, Aug 10, 2012 at 2:26 PM, Johan Appelgren <
> johan.appelg...@gmail.com> wrote:
>
>> You're right that I'm not understanding something here, most likely it is
>> something really obvious too. :(
>>
>> As I wrote, my understanding of what you describe is not the behavior I'm
>> seeing with my test app on my Galaxy Nexus with Android 4.1.1 nor the 4.1.1
>> emulator image. After I've unbound from the service, in my test I do this
>> in the activity's onPause, when the app process is killed, it and the
>> service is restarted. Then after that the process and service is killed and
>> restarted every now and then, without starting the activity or any calls to
>> startService or bindService made by any code in my test app. It starts
>> quicker if I start a couple of different games to put some memory pressure
>> on the system.
>>
>> Not even stopping the cached process in the Cached processes list stops
>> it, it is restarted a little while after. Only going to the Downloaded list
>> and pressing the Force stop button stops the stop/restart cycle.
>>
>> Perhaps someone could look at my dummy app code and point out what I'm
>> doing wrong. If someone does, I'm sorry for most likely wasting your time.
>>
>> public class MainActivity extends Activity {
>>
>> @SuppressWarnings("unused")
>> private int[] mDummyData = new int[3 * 1024 * 1024];
>> private final String TAG = "MainActivity";
>> private boolean mBound;
>> private boolean mCalledBind;
>> private boolean mStarted;
>> private final ServiceConnection mConnection = new
>> ServiceConnection() {
>>
>> @Override
>> public void onServiceConnected(ComponentName className, IBinder
>> service) {
>> Log.d(TAG, "onServiceConnected");
>> mBound = true;
>> }
>>
>> @Override
>> public void onServiceDisconnected(ComponentName arg0) {
>> Log.d(TAG, "onServiceDisconnected");
>> }
>> };
>>
>> public MainActivity(){
>> Log.d(TAG, "ctor");
>> }
>>
>> @Override
>> public void onCreate(Bundle savedInstanceState) {
>> super.onCreate(savedInstanceState);
>> setContentView(R.layout.activity_main);
>>
>> Intent intent = new Intent(this, MainService.class);
>>
>> Log.d(TAG, "onCreate");
>>
>> if (!mStarted) {
>> Log.d(TAG, "startService");
>> startService(intent);
>> mStarted = true;
>> }
>>
>> if (!mBound && !mCalledBind) {
>> Log.d(TAG, "bindService");
>> bindService(intent, mConnection, BIND_AUTO_CREATE);
>> mCalledBind = true;
>> }
>> }
>>
>> @Override
>> protected void onPause() {
>> Log.d(TAG, "onPause");
>>
>> if (mBound) {
>> Log.d(TAG, "unbindService");
>> unbindService(mConnection);
>> mBound = false;
>> mCalledBind = false;
>> }
>>
>> super.onPause();
>> }
>>
>> @Override
>> protected void onDestroy() {
>> Log.d(TAG, "onDestroy");
>>
>> super.onDestroy();
>> }
>> }
>>
>> public class MainService extends Service {
>>
>> @SuppressWarnings("unused")
>> private int[] mDummyData = new int[1024*1024];
>> private static final String TAG = "MainService";
>> private final IBinder mBinder = new LocalBinder();
>> public class LocalBinder extends Binder {
>> MainService getService() {
>> return MainService.this;
>> }
>> }
>> @Override
>> public IBinder onBind(Intent arg0) {
>> Log.d(TAG, "onBind");
>> return mBinder;
>> }
>>
>> @Override
>> public int onStartCommand(Intent intent, int flags, int startId) {
>> Log.d(TAG, "onStartCommand");
>> return START_NOT_STICKY;
>> }
>> @Override
>> public void onCreate() {
>> Log.d(TAG, "onCreate");
>> super.onCreate();
>> }
>> }
>>
>> On Friday, August 10, 2012 8:39:46 PM UTC+2, Dianne Hackborn wrote:
>>>
>>> On Fri, Aug 10, 2012 at 12:17 AM, Johan Appelgren
>>> <johan.a...@gmail.com>wrote:
>>>
>>>> Still occupies some amount of memory though, and the service's onCreate
>>>> might not be cheap.
>>>
>>>
>>> I'm not sure what this means...? If you are concerned about the service
>>> having too much overhead because you have bound to it and it doesn't need
>>> to run just while bound, don't use BIND_AUTO_CREATE.
>>>
>>>
>>>> Anyways, I guess this is one of those little undocumented things you
>>>> just have to learn. Do not rely on START_NOT_STICKY if you both start and
>>>> bind to a service if you don't want the service to stay around forever as a
>>>> cached process after you've unbound it.
>>>>
>>>
>>> Honestly I think it is pretty fully documented. But maybe we have a
>>> misunderstanding -- once you unbind from the service, the fact that you had
>>> previously bound to it has no further impact on how it is handled, and if
>>> its process is killed after that it will not be restarted.
>>>
>>> As long as you are bound to it with BIND_AUTO_CREATE, the system will
>>> try to keep it created and if the process is killed while you remain bound
>>> to it then it will try to restart it.
>>>
>>> As long as the service is in the started state, the system will try to
>>> keep it created/started, and if the process is killed then it will be
>>> restarted if it is not sticky.
>>>
>>> The decision about whether to restart the service is if either of those
>>> conditions result in it wanting to restart it.
>>>
>>> Again starting and binding are orthogonal to each other. You just have
>>> to know how each works individually, and what happens in the service is
>>> based on whether either of them drive it to need to be created. As I think
>>> is covered pretty fully in the documentation.
>>>
>>> --
>>> Dianne Hackborn
>>> Android framework engineer
>>> hac...@android.com
>>>
>>>
>>> Note: please don't send private questions to me, as I don't have time to
>>> provide private support, and so won't reply to such e-mails. All such
>>> questions should be posted on public forums, where I and others can see and
>>> answer them.
>>>
>>> --
>> 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
>>
>
>
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
>
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support, and so won't reply to such e-mails. All such
> questions should be posted on public forums, where I and others can see and
> answer them.
>
>
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--
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
