Im facing an issue with alarms that androidAlarmManager never handle over doze mode even i used setAlarmClock() in my Flutter android app
Android Document says:"Alarms set with setAlarmClock() continue to fire normally — the system exits Doze shortly before those alarms fire."
Also i checked the plugin codes in android_alarm_manager-0.4.5 17 version,
with parameters ( wakeup: true, rescheduleOnReboot: true, alarmClock: true), AndroidAlarmManager.oneShot() func is returning setAlarmClock() with RTC_WAKEUP clock from native side.
Below you can find how im calling oneShot();
AndroidAlarmManager.oneShot(Duration(milliseconds: nextAlarmTimeInMilliseconds), item.id, _notificationCallBack,
rescheduleOnReboot: true,
alarmClock: true );
When first alarm goes off then second alarm set with the same id as oneShot().. it goes on and on..
Everythings seems working when phone awake however when phone enter doze mode, alarms not firing on exact time. Whenever the phone exit doze mode by moved or touched by someone, alarms are firing with delay.
Do you have any idea what might cause it?
Related
I would like a simple app that periodically checks the bluetooth connection between the phone and my watch (GTR 3 Pro), and buzzes the watch when it gets disconnected from my phone. This will be useful if I accidentally leave my phone somewhere and walk away from it, or my phone gets stolen or something like that.
Some previous amazfit watches had this feature built-in, but it doesn't seem to be available in my GTR 3 Pro right now. Thank you.
I made it, but only in ACTIVE application. So, if you open your mini-app, then it is possible to handle bluetooth status events (see the picture). Couldn't apply it in the background yet :-(.
You'll need to do a little hack to poll the Bluetooth connection to achieve the desired behavior, but first let's understand why.
Per ZeppOS architectural decision, your app will never run in background on the device. I believe this is for battery efficiency reasons or even available processing power.
With that in mind, We'll use hmApp.alarmNew and hmApp.alarmCancel in order to get it working, as follows:
Create a new page that will be responsible for checking the bluetooth connection, something like page/connectionCheck.js and declare it in your app.json target (you can also use the default index.js if you want)
In the onInit() of the page, register a new hmApp.alarm and cancel the existing ones if needed to avoid waking up the app unnecessarily
In the build() call, verify if it's connected to the cellphone using the hmBle.connectStatus() and alert the user.
Summarizing, it'll look like this:
(I'm using zeppOS API v1.0 here to make it work on all devices)
const WAKE_UP_INTERVAL_SECONDS = 30 // this value must be higher than the screen on time on app
const POLL_ALARM_PREF_ID = 'my_bluetooth_poll_alarm'
const vibrate = hmSensor.createSensor(hmSensor.id.VIBRATE)
Page({
onInit(param) {
vibrate.stop() // stop any vibration
vibrate.scene = 27 // set the vibration scene to 27 (1000ms vibration, high intensity)
// verify if this launch was triggered by an alarm or not
if(param === POLL_ALARM_PREF_ID) {
const existingAlarm = hmFS.SysProGetInt(POLL_ALARM_PREF_ID) // get existing alarm reference from system preferences
if(existingAlarm) {
// cancel existing alarm
hmApp.alarmCancel(existingAlarm)
}
}
// always create a new alarm to avoid alarm trigger while using the app
const alarm = hmApp.alarmNew({
file: 'pages/connectionCheck',
appid: 123123, // <YOU APP ID HERE>
delay: WAKE_UP_INTERVAL_SECONDS,
param: POLL_ALARM_PREF_ID
})
hmFS.SysProSetInt(POLL_ALARM_PREF_ID, alarm) // Save new alarm reference on system preferences
},
build() {
if(hmBle.connectStatus() === true) {
// Do something if already connected, maybe return to the home screen, exit the program or even turn the sreen off
hmApp.exit()
} else {
// show a message to the user / vibrate the watch
vibrate.start()
}
},
onDestroy() {
vibrate && vibrate.stop() // stop any vibration
}
})
Android 12 introduced the behavior where the last app you had active are continuing to run when inside the recent menu. I'm wondering if there's a flag or something to put in AndroidManifest file to prevent this behavior as it's conflicting with some logics in our app (which works fine for Android < 12). I've googled but it's hard to find unless you know exactly what this "feature" is called.
Steps:
Start app
Open recent menu
Observe that you can interact and that the app is still running as if you had it open/active
Why is this a problem? Because a user is now able to force quit the app (swiping it away) without entering the "paused" state in our game (using Unity) meaning some save logic won't run.
This can be worked around in one way or another, but for now I would like to just pause the app in recent menu if possible (our app has zero reason for being active in recent menu).
EDIT:
As #WyattL mentioned in his answer, android:excludeFromRecents="true" might work, but it will cause drop in playtime and retention of the game and would prefer to have a more proper solution to this "unnecessary" feature of Android 12.
I can't be sure without testing on every phone as it seems the issue varies by device (thanks Ruzihm), but if opening the Recent Apps screen generates an OnApplicationFocus() call, this would provide a solution.
In an active MonoBehaviour:
private void OnApplicationFocus( bool focus )
{
if( focus ) {
UnpauseLogic();
}
else {
PauseLogic();
SaveLogic();
}
}
(It might also be worth trying OnApplicationQuit() in case it's called on specific devices during a swipe termination, but in my own tests it was never called.)
According to some brief research, did you try adding
<activity>
...
android:excludeFromRecents="true"
android:label=""
...
</activity>
to the AndroidManifest.xml?
Many people appear to have a problem where their AppDelegate's applicationShouldTerminate is never called. I have the opposite problem!
Often (at a guess 20% of the time) when I come back to my Mac in the morning, I discover that something caused my app's applicationShouldTerminate to fire. My app then ran its cleanup code, after which applicationWillTerminate fired. However the app never shut down — it's still marked as running in my dock, and when I click on it there, applicationDidFinishLaunching fires and it starts up. Because it was already running, the dock icon does not bounce.
The logs indicate this seems to only happen when I wrap up for the day and my Mac goes to sleep, possibly only after having been plugged back in after running off its battery.
At first I thought it might be because my Mac was trying to shutdown apps to install a system update but this happens even when there are no updates available. And no other apps on my system have the issue.
The same happens with my app on a friend's Mac.
I do have a "tricky" applicationShouldTerminate to get around run loop issues (nb. I'm using Promises):
var shuttingDown: Bool = false
func applicationShouldTerminate(_ sender: NSApplication) -> NSApplication.TerminateReply {
log.debug("applicationShouldTerminate")
if shuttingDown { return .terminateNow }
shuttingDown = true
StuffController.shared.terminateRunningStuff()
.timeout(20) // If it hasn't shutdown within 20 seconds, force it.
.always {
// Tell the app it should now actually terminate.
NSApplication.shared.terminate(self)
}
return .terminateCancel
}
Can anyone suggest a reason my applicationShouldTerminate is firing without the user asking it to quit?
Turns out this is a feature not a bug (lol). In Mac OS X Lion (10.7) Apple introduced a feature called "Automatic Termination" where apps would automatically quit after a while of inactivity.
Note that this is intended to be invisible to the end-user; the app appears to be running in the dock, and should restore itself when needed, as if nothing ever happened.
It can be enabled or disabled via the "Application can be killed to reclaim memory or other extraordinary circumstances" configuration in Xcode (the NSSupportsAutomaticTermination key in an app's Info.plist).
I have an action that automatically loops on a collection of shorts audio tracks (each about 30 secs).
The action (same action, same code) on Google Assistant app executed on real smartphone works well, but on Google Home devices it has a strange behavior:
first track plays entirely
second track stops playing after 1 sec
third track plays entirely
fourth track stops playing after 1 sec
and so on, alternately one track plays entirely and the next one not.
So, is there any difference between the MediaObject on smartphone and the Google Home one?
Any hints, please? Thanks
UPDATE sept 2019:
The behavior of the Home device got worse over the last week (without changes to the active code):
now the first track plays completely, the second stops after a second, the third doesn't sound at all and the loop stops (crashes?).
SAMPLE CODE:
-> The next track automatically plays at receiving MEDIA_STATUS = FINISHED
app.intent('Media Status', (conv) => {
const mediaStatus = conv.arguments.get('MEDIA_STATUS');
if (mediaStatus && mediaStatus.status === 'FINISHED') {
// Automatically start playing the next track
nextTrackPower(conv, true, false, datapower);
} else {
console.log('Unknown media status received.');
conv.close(getRandomPrompt(conv, 'error'));
}
});
-> Then I emit three ask command from nextTrackPower() function (an intro text, in the middle the right MediaObject, finally some suggestion chips)
const nextTrackPower = (conv, intro, backwards, datapower) => {
// Loops the tracks
--- OMITTED ---
// Plays the next track
trackpower = datapower[conv.user.storage.trackpower - 1];
// Add a prompt intro
if (intro) {
conv.ask(nextPrompt);
}
// Create a media response
conv.ask(new MediaObject({
name: trackpower.title,
url: POWER_BASE_URL + trackpower.clip,
description: trackpower.artist,
icon: new Image({
url: POWER_BASE_URL + trackpower.link,
alt: 'Media icon'
})
}));
// Add suggestions to continue the conversation
conv.ask(suggestions1 );
};
This is, apparently, a currently known issue, although the engineering team is still investigating. See this thread on the official Reddit forum, which includes a response from a Googler saying
Thanks for reporting the issue. We are investigating.
and later
Our engineers are still investigating.
Tests with my existing Actions indicated problems on both Smart Speakers and Smart Displays, although it worked on an Android device. A Home Mini that I have that remained unplugged for a while seemed to work correctly as well, suggesting it might be an update that was done relatively recently.
I encourage you to add your information to the thread I mentioned above, indicating you're seeing problems similar to those described.
When I do Login I am starting to check observable working but when application is in background it is not executing. I am using observable because after every 5 seconds refresh should happen. It seems it is not running in background. Any other solution to run the code after every 1 minute whether application is in background or foreground. Thanks in advance !
Loginsuccessfully
this.provider.startBackgroundRefreshInterval();
In service class below code added
startBackgroundRefreshInterval() {
var refreshInterval = localStore.getPersistedData(App.ISCHECKBOX_KEY);
this.timerSubscription = Observable.interval(parseInt(refreshInterval))
.subscribe((val) => {
console.log("Observable subscribed");
});
}
/**
* unsubscribe subscription
*/
unSubscribeOnehourSubscription() {
console.log("Observable Unsubscribed");
this.timerOneHourSubscription.unsubscribe();
}
Now refreshInterval is based on checkbox value selection
updateCheckboxList(value:any) {
this.service.unSubscribeSubscription();
this.service.startBackgroundRefreshInterval();
}
Once application will go in background Observable not calling
currently refreshInterval selected as 1 minute
what is other way to call functon continuosly in background in ionic ?
I am currently working on the same thing. While I can't say I know all the things about this, here is what I have found so far.
When your app goes to the background, it is essentially put to sleep. Meaning none of the code you are counting on, including intervals is going to execute.
Here are some solutions to this problem I have worked on.
1) BackgroundFetch as seen here in this cordova plugin https://github.com/transistorsoft/cordova-plugin-background-fetch and https://ionicframework.com/docs/native/background-fetch will in both android and ios attempt to run a callback every approximately 15 minutes (read the link for why that timing is a thing).
2) BackgroundMode as seen here https://ionicframework.com/docs/native/background-mode will put your app into a "stay active while in background" mode that you can control. This will work in keeping your app up and running even in background, but you may find that this is not acceptable to the stores (particularly might get rejected by ios store).
That's what I've found thus far. Hope it's helpful.