Configurable snooze times. Supports all devices running iOS 7 - 8. Subject of my JailbreakCon 2014 talk. Retired in favor of Sleeper, which will offer support in the years to come. Snooze is available for free with purchase of Sleeper, and both are open source.
Snooze is a fantastic example of, at least for me, an average tweak's development from idea to iteration to completion. When I first decided to develop Snooze, I assumed it had to begin in the MobileTimer private framework, that's why it wasn't possible to alter it with utilities like Flex, and why it didn't show up when I cursory-searched a few months ago (in a less experienced time). So, I dived in, and found a few great methods in the Alarm and Alarm/Clock/TimerManager classes. Unfortunately, %log'ing all of them wasn't very pretty. Only one was consistently called:
+[Alarm isSnoozeNotification:arg1]
But still, that sounded good. Here's what it spit out, after I snoozed an alarm:
+[<Alarm: 0x199679bf8> isSnoozeNotification:<UIConcreteLocalNotification: 0x178134dc0>
{
fire date = Thursday, March 20, 2014 at 10:16:02 PM Eastern Daylight Time,
time zone = (null),
repeat interval = 0,
repeat count = 0,
next fire date = Thursday, March 20, 2014 at 10:16:02 PM Eastern Daylight Time,
user info = {
alarmId = "C4D933A4-0987-4DE2-91E0-51344EFB39B8";
hour = 22;
lastModified = "2014-03-21 02:06:17 +0000";
minute = 7;
repeatDay = "-1";
revision = 1;
soundType = 1;
}
}]
That seemed simple. But it was called more than once, maybe even dozens of times. Comparing all of those calls would be exhausting. A simple implementation (reducing the "fire date" by 9, the default snooze time, and increasing it by SZADD_AMOUNT, my test amount) failed on all counts. Although it did alter the notification, that didn't seem to have any effect on the actual performance of an Alarm. So, I peeled through some dumps I had lying around for the Clock app and SpringBoard. In a twist, I found this handy method, in a class I'd never even heard of:
-[SBClockDataProvider _handleAlarmSnoozedNotification:]
The implementation went something like:
-(void)_handleAlarmSnoozedNotification:(NSConcreteNotification *)notification {
...
... userInfo = [notification userInfo;]
... alarm = [userInfo objectForKey:@"AlarmNotification"];
... bulletin = [self _bulletinRequestForSnoozedAlarm:alarm];
... timer = [[PCPersistentTimer alloc] init];
[timer setFireDate:bulletin.fireDate];
...
}
So, I assumed overriding this to swap out the notification argument would be far more effective than the previous logic check, and it seemed to be the start of the call stack. Here's what it logged out:
-[<SBClockDataProvider: 0x1708710c0> _handleAlarmSnoozedNotification:NSConcreteNotification 0x170a43450
{
name = SBApplicationClockAlarmSnoozedNotification;
userInfo = {
AlarmNotification = <UIConcreteLocalNotification: 0x17012c620>{
fire date = Thursday, March 20, 2014 at 11:17:12 PM Eastern Daylight Time,
time zone = (null),
repeat interval = 0,
repeat count = 0,
next fire date = Thursday, March 20, 2014 at 11:17:12 PM Eastern Daylight Time,
user info = {
alarmId = "9D663886-D567-4DA0-A130-D1B7315FBF19";
hour = 23;
lastModified = "2014-03-21 03:07:34 +0000";
minute = 8;
repeatDay = "-1";
revision = 1;
soundType = 1;
}
};
}
}]
[Snooze] Added 10 to current time of 2014-03-21 03:22:01 +0000,
to alter NSConcreteNotification 0x178c5a7c0 {
name = SBApplicationClockAlarmSnoozedNotification; userInfo = {
AlarmNotification = "<UIConcreteLocalNotification: 0x178134a00>{
fire date = Thursday, March 20, 2014 at 11:22:11 PM Eastern Daylight Time,
time zone = (null),
repeat interval = 0,
repeat count = 0,
next fire date = Thursday, March 20, 2014 at 11:22:11 PM Eastern Daylight Time,
user info = {
alarmId = "49EB1B0B-63EA-46E7-99E2-F1AB6769F476";
hour = 23;
lastModified = "2014-03-21 03:21:25 +0000";
minute = 22;
repeatDay = "-1";
revision = 1;
soundType = 1;
}
};
}
}'s
<UIConcreteLocalNotification: 0x178134a00>{
fire date = Thursday, March 20, 2014 at 11:22:11 PM Eastern Daylight Time,
time zone = (null),
repeat interval = 0,
repeat count = 0,
next fire date = Thursday, March 20, 2014 at 11:22:11 PM Eastern Daylight Time,
user info = {
alarmId = "49EB1B0B-63EA-46E7-99E2-F1AB6769F476";
hour = 23;
lastModified = "2014-03-21 03:21:25 +0000";
minute = 22;
repeatDay = "-1";
revision = 1;
soundType = 1;
}
}
and send NSConcreteNotification 0x178e4f000 {
name = SBApplicationClockAlarmSnoozedNotification;
userInfo = {
AlarmNotification = <UIConcreteLocalNotification: 0x178134a00>{
fire date = Thursday, March 20, 2014 at 11:22:11 PM Eastern Daylight Time,
time zone = (null),
repeat interval = 0,
repeat count = 0,
next fire date = Thursday, March 20, 2014 at 11:22:11 PM Eastern Daylight Time,
user info = {
alarmId = "49EB1B0B-63EA-46E7-99E2-F1AB6769F476\";
hour = 23;
lastModified = "2014-03-21 03:21:25 +0000";
minute = 22;
repeatDay = "-1";
revision = 1;
soundType = 1;
}
};
}
}
But that didn't work. Hijacking the notification did update the timer for the bulletins (super easy to see on the lock screen), but it had no real effect on the notification fire date, or Alarm. Some minor investigations into that area of the decompilation made me feel hopeful for some global snooze-time key, but there was only this weird SBLocalNotificationSnoozeIntervalOverride reference, and I couldn't find more than a single mention of it in the entire SpringBoard. And, because alerts from a few other apps can be "snoozed" (e.g. Reminders), it was clear it was some system value for other alerts. Moving on, I traced this method next:
-[SBClockDataProvider _handlePossibleAlarmNotificationUpdate:]
Tracing this had no immediate effect, but it ended me up in the PCPersistentTimer class, which was part of the sister framework PersistentConnection. Popping some logs from time-dependent PCPersistentTimer -init hook was nice looking:
SpringBoard[30169]: [Snooze] Overriding preset time interval 9.999883 to be personalized 1395372853.630588...
%hook PCPersistentTimer
- (id)initWithTimeInterval:(double)arg1 serviceIdentifier:(id)arg2 target:(id)arg3 selector:(SEL)arg4 userInfo:(id)arg5 {
if (sz_overrideInterval != 0.0) {
NSLog(@"[Snooze] Overriding preset time interval %f to be personalized %f...", arg1, sz_overrideInterval);
double snoozeInterval = sz_overrideInterval;
sz_overrideInterval = 0.0;
return %orig(snoozeInterval, arg2, arg3, arg4, arg5);
}
else {
return %orig();
}
}
%end
But that had no noticeable effect on the codebase. Everything operated as it had before, meaning I was simply following the crumb trail down, instead of up. Without any other choice, I went back to the mysterious SBClockDataProvider, this time for -_publishAlarmsWithScheduledNotifications:
without anything (set for 11:59, log 8 seconds later)
-[<SBClockDataProvider: 0x17867a500> _publishAlarmsWithScheduledNotifications:(
<UIConcreteLocalNotification: 0x170322300>{
fire date = Friday, March 21, 2014 at 12:08:08 AM Eastern Daylight Time,
time zone = (null),
repeat interval = 0,
repeat count = 0,
next fire date = Friday, March 21, 2014 at 12:08:08 AM Eastern Daylight Time,
user info = {
alarmId = "54D017B7-7ED8-468C-A23B-F0495CC85EC9";
hour = 23;
lastModified = "2014-03-21 03:58:15 +0000";
minute = 59;
repeatDay = \"-1\";
revision = 1;
soundType = 1;
}
}"
)]
--- last message repeated 1 time ---
Uh-oh. This was down as well. The "fire date" was identical to the time snoozed. Hm... but inspecting the decompilation led me to a middle-man-looking method:
-[<SBClockDataProvider _nextAlarmForFeed:32 withNotifications]
Let's see what it prints:
-[<SBClockDataProvider: 0x170a7efc0> _nextAlarmForFeed:32 withNotifications:(
<UIConcreteLocalNotification: 0x1783288e0> {
fire date = Friday, March 21, 2014 at 12:16:01 AM Eastern Daylight Time,
time zone = (null),
repeat interval = 0,
repeat count = 0,
next fire date = Friday, March 21, 2014 at 12:16:01 AM Eastern Daylight Time,
user info = {
alarmId = \"E6A01559-F7A0-4A16-B016-CE65AC2EB953\";\n
hour = 0;\n
lastModified = \"2014-03-21 04:06:55 +0000\";\n
minute = 7;
repeatDay = "-1";
revision = 1;
soundType = 1;
}
}
)]
Not bad! Looks like a very similar functionality to our original %hook, back up there. Rubbing my hands together, I decided to create a global, static array that could hold all the alarmIds, and then, in this method, check to see if, in any of the notifications, there's one of those ids. If so, it would reduce the time by 9 minutes, and add my fake value (10 seconds). This, however, was no more than a hopeful thought. Since this method is called several times back-to-back, comparing the dates would be tough: sometimes they were the same between calls, something they'd be upped by 9 minutes, sometimes they'd have my 10 second addition applied more than once. What was happening? After playing around with a bit too many stringy ideas for this method, I realized I was still going down the call chain.
That's when SBLocalNotificationSnoozeIntervalOverride caught my eye again. It popped up in the stack trace for this method, upwards. But how did I miss that? Because it was surrounded by conditionals in the method I had started in, and sounded bizarre. The full, jargon-y method had this one, serene line, that I underestimated:
`_R0 = objc_msgSend(v7, "integerForKey:", CFSTR("SBLocalNotificationSnoozeIntervalOverride"));`
In essence, that translated into:
If exists, make the snooze time additional equal to
[[NSUserDefaults standardUserDefaults] integerForKey:SBLocalNotificationSnoozeIntervalOverride]
It wasn't an opaque system override at all— and could be used to alter the snooze interval with hardly any lines of code. Logging all of the -integerForKeys of NSUserDefaults (the universal XML-wrapped quick-and-dirty storage system for iOS, useful for tiny values) made me realize Apple uses it immensely, for tons of different things. Just for fun, I %hook'd the method, with a very simply body:
%hook NSUserDefaults
- (NSInteger)integerForKey:(NSString *)defaultName {
if ([defaultName isEqualToString:@"SBLocalNotificationSnoozeIntervalOverride"]) {
return SZADD_AMOUNT;
}
else {
return %orig();
}
}
%end
And you know what? It worked. Perfectly. That's the only block of code that mattered, in the hundreds of lines of code that I had written. The answer was reducible to three.
Just another day in tweak land.
Snooze: Configurable snooze times.
Copyright (C) 2014-2015 Julian (insanj) Weiss
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.