Android TagTime build or build instructions for latest update

Beginning with Android API 19, setAlarmClock is inexact and will be subject to windowing just the same. AlarmManager  |  Android Developers

Note: Beginning with API 19 ( Build.VERSION_CODES.KITKAT ) alarm delivery is inexact: the OS will shift alarms in order to minimize wakeups and battery use

One of the things about Android is that the source is generally available. When Doze came out, I read a lot of source code, and foreground services did stop Doze, although it was not in the docs. I verified that it was true. It may not still be true.

1 Like

Then let’s just kick it back to API 18 but keep @chrp’s changes.

Google Play no longer accepts anything with a target API of less than 26.

1 Like

If you’re asking how I’d implement it in code to make the foreground service be optional, I can outline it, but I am working towards a contract delivery this week and cannot commit to do so until the weekend.

http://adam.commits.to/outline_tagtime_foreground_delivery

1 Like

I tried with setAlarmClock and it still delayed the pings.

Can we also get an on-screen popup that grabs focus when it pings?

1 Like

Remember how I said at the beginning that functionality depends both upon OS version level and Target API levlel? That’s probably what you’re seeing.

1 Like

I also tried the App Store version, whitelisted on Android 9, and it still has the delays! But only when the screen is off.

So I think it may just be the OS version causing the problem.

It should be only an hour or three to get the foreground service in place. It may do it.

This seems normal and fine to have delays when the screen is off. On my phone if the screen is off long enough it will go into doze mode or whatever and may not ping at all (such pings will show up auto-tagged as “OFF” when TagTime next runs). That seems reasonable, though it would be nice to have a setting to have it always stay running and never miss any pings. Not sure what the battery tradeoffs are there.

But the main thing I’m concerned about is that when the display is on it pings at the exact right time. That’s what the Google Play version targeting API level 18 does. But apparently we can’t just set the new version to level 18 so… yeah, maybe a permanent notification is the answer?

@dreev I misunderstood the problem then. I’m getting different results:

With both the current build and the Google Play one, I am not getting delays with screen on - it pings at the exact right time. I am still getting pings even when the screen has been off for a while but the pings are up to 60 seconds late.

I’m not sure why the delays are ok when the screen is off but not when it’s on. But it seems very bad if you are actually missing pings! I’m only using it on my phone and the screen is off most of the time, so TagTime would be pretty useless if I totally missed pings when the screen was off.

But as I said, I’m not having that problem on Android 9 even with the updated build, though I’ll keep an eye out.

1 Like

Also relevant:

1 Like

Somebody has a build out there that fixes the issue…

What makes you think that, and which of the multiple issues discussed here are you talking about?

Sorry, ignore me. I replied without reading the whole thread - I was simply talking about the chrp’s build, I see the discussion has moved on…

However, to add some actual signal, screen off doze delays were not really acceptable for me and enough to render TagTime useless. Frequently, use of TagTime was the only thing keeping the phone from dozing and if I happened upon a ping with a significant interval, then doze would win the “race condition” so to speak. This would happen frequently enough that output of TagTime was no longer converging with reality.

As far as the solution to that - running a foreground service (in a separate process) should work but apparently doesn’t on Samsung phones.

screen off doze delays were not really acceptable for me and enough to render TagTime useless. Frequently, use of TagTime was the only thing keeping the phone from dozing and if I happened upon a ping with a significant interval, then doze would win the “race condition” so to speak. This would happen frequently enough that output of TagTime was no longer converging with reality.

Which build were you using? Did you turn optimization off? On Android 9 I so far get delays of no more than 60 seconds with the most recent build (more recent than chrp’s).

As far as the solution to that - running a foreground service (in a separate process) should work but apparently doesn’t on Samsung phones.

I’m not sure what you mean - TagTime has not yet been updated to include a foreground service. Adamwolf is working on that.

Optimization, as you’ve seen, is not going to matter but I’m going with what dreev said above - haven’t tried a recent build myself as I have switched to lock-screen based tracking. If pings are being missed as OFF with screen off even with the latest build, then the problem persists.

There are reports that running a foreground service may not fix Doze issues on Samsung phones.

What is lock-screen based tracking?

When I try it with the latest build, pings are NOT being missed as “OFF” with screen off. I think @dreev reported they were for him though.

Alright, so here’s what I would try first, if you want an optional foreground service.

Setup a boolean preference.

I would set up a Service, call it TagTimeService.java. Remember to declare it in the AndroidManifest.xml. While you’re in there, don’t forget to ask for the FOREGROUND_SERVICE permission.

Then, in the onCreate of your launch activity, I would do something like the following, after loading preferences, and checking that the preference is set to launch the foreground service:

Intent launch = new Intent( sContext, TagTimeService.class );
ContextCompat.startForegroundService(this, launch);

For newer Androids, you have to use notification channels, so set that up. You can set that up idempotently, so let’s do that, in the onCreate of your TagTimeService:

        NotificationChannel fgChannel = new NotificationChannel(FOREGROUND_CHANNEL_ID,
                "Foreground Service",
                NotificationManager.IMPORTANCE_LOW);


        fgChannel.setDescription("A persistent notification helping remind both you and Android about TagTime.  Feel free to hide, it will still do its job hidden :)");
        NotificationManager notificationManager = (NotificationManager) getSystemService( Context.NOTIFICATION_SERVICE );
        notificationManager.createNotificationChannel(fgChannel);

And then actually show the notification…

            Intent notificationIntent = new Intent(fooContext, WhereShouldTheNotificationGoIfTappedBytheUser.class);

        PendingIntent pendingIntent = PendingIntent.getActivity(fooContext,
                0,
                notificationIntent,
                0);

        Notification notification = new NotificationCompat.Builder(this, FOREGROUND_CHANNEL_ID)
                .setSmallIcon(R.drawable.tagTimeIconOrSomething)
                .setPriority(NotificationManager.IMPORTANCE_LOW)
                .setContentIntent(pendingIntent).build();

        startForeground(PERSISTENT_NOTIFICATION_ID, notification);
        if (LOCAL_LOGV) Log.v(TAG, "runAsForeground: created persistent notification.");

I am experimenting launching this as a collapsed notification, but I haven’t gotten to that quite yet.

You may want to wrap that all in a “If on O or newer” conditional.

Let me know how it goes, but I am still wrapping up a large offline project and will have limited availability. This should get you most of the way!

2 Likes

So as frustrating as Doze is, some vendors have their own layer of “we kill your app when its in the background… sometimes.”

I ran into this this morning: https://dontkillmyapp.com/

:pursedgrimacesmilething:

2 Likes

@adamwolf I’m confused. Is there a version, or is someone working on a version, that has a non-optional foreground service?