I am using Notifications.local.scheduleNotification to schedule a notification. However, if the phone is rebooted before the fire event, the notification does not fire.
I would like to have the app start when the phone boots up so that I can add the notification to the alarm manager again. In the android manifest I would be asking for the following permission.
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
How can this be implemented in smartface?
Today, this is not supported by Smartface, but there will be plugin support soon, you can write your own plugin and use it.
Also for licenced users, there is an option to ask for new implementations. If they need some new features, they can report them to Smartface team, and these features will be added to road map.
Related
I have an Android app on Play store for 8 years. Recently Google release Android S or 12 introduce some limit with Foreground service launch restrictions
https://developer.android.com/about/versions/12/behavior-changes-12#foreground-service-launch-restrictions
and
Exact alarm permission
https://developer.android.com/about/versions/12/behavior-changes-12#exact-alarm-permission
In the app I use foreground service and alarm clock to schedule update weather data from the cloud and device sensor and send notification to user, update the widget.
But they said: Exact alarms should only be used for user-facing features so if I continue use those API, it is safe (with Google Play policy)?
I ask this because other solution like sticky notification with foreground service and workmanager not work as my requirements.
if you are testing android 12 then don't forget to add this line to Manifest
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" />
Yes, the android.permission.SCHEDULE_EXACT_ALARM it's safe to use, on Android 12 this permission is automatically granted by the Android system but on Android 13 you need to check if the user has granted this permission.
So you need to add the permission to the manifest
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM"/>
And then you need to check if the permission was granted, if not granted then you need to redirect the user to the Alarms & Reminders page
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
val alarmManager = ContextCompat.getSystemService(context, AlarmManager::class.java)
if (alarmManager?.canScheduleExactAlarms() == false) {
Intent().also { intent ->
intent.action = Settings.ACTION_REQUEST_SCHEDULE_EXACT_ALARM
context.startActivity(intent)
}
}
}
Google also suggests that you need to check any changes on this permission by registering a Broadcast Receiver and check the changes on ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED
Google states: "(when your app) requires precisely-timed actions". Your use case is "to schedule update weather data (…) send notification to user". While this might be user-facing, it doesn't seem to require to be precisely on a certain time. I would guess your app doesn't qualify.
The methods requiring the additional permission are currently: setExact(), setExactAndAllowWhileIdle() and setAlarmClock(). Repeating alarms will always be inexact. Seems like getting processing weather data and device sensors is something repetitive anyway.
From what you've mentioned, you're talking about user-facing features.
A hypothetical example of the opposite would be Facebook forcing synchronization of user data at some specific time. That would be bad because it's preferable not to force a schedule on those types of things as it doesn't matter whether it happens at a specific time or a minute later when system resources are not used by some other service.
Also, "should" means it's a recommendation. Facebook can do the above, but it would be a less optimal solution. It's best to leave control over those kinds of services to Android as it would likely do a better job at distributing resources and preventing lag. So in other words, you not listening to their recommendation won't get your app removed from the app store or something like that.
Also, the paragraph you quoted from the second link, has a link to examples of acceptable use cases, and it mentions alarm apps. This is likely why your question was downvoted.
effective solution
you need to add the permission to the manifest before <application
I am having problems while doing work in the background in Android. I need to do a http request every 5s in a app of my own use (won't publish the app). I've seem that since version O Android had put limitations on the operational system and I'm doing what is recomended, that is, I'm creating a foreground service with a persistent notification to run this task. It works fine with the screen on, and even with the app closed, but after a while if the phone is locked it enters the Doze mode and lock my requests until I turn the screen on again. I've tried to mess with the power savings configurations of my phone with no luck.
Anyone have faced that issue?
Preferably without FCM (Firebase Cloud Messaging).
I am doing it on Xamarin.Forms, but if you have some example in Java that's ok, I'll get the idea.
You have to set REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission in your manifest.
<uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />
Also you have to ask the user to put your app on the Battery_Optimization whitelist at runtime, like descriped here:
//check for ignoring battery optimization
PowerManager mPowerManager = (PowerManager) your_context.getSystemService(Context.POWER_SERVICE)
if (!mPowerManager.isIgnoringBatteryOptimization(your_context.getPackageName())) {
//ask for permission
Intent intent = new Intent(android.provider.Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS);
intent.setData(Uri.parse("package:" + your_context.getApplicationContext().getPackageName()));
startActivity(intent);
}
BUT your app is most likely not going to get approved by Google Play, when you try to release it to the PlayStore!
You should use FCM high-priority messages instead.
There aren't too many ways to do it on Android in nowadays.
Try to look at this Google tutorial and choose the right one.
Regarding the REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission, your app should fit these conditions.
You'll find more details here android-doze-standby.
Honestly if you need do a task every X seconds use an alarm broadcast:
https://developer.android.com/reference/android/app/AlarmManager
You just implement a receiver and you can perform the task. If you need it in a specific class implement the receiver as in inner class running on a new thread re-registering the alarm every time.
I am building an SDK that is using Google Awareness API.
I have some actions that need to be executed based on different schedules for each day, also when the app is backgrounded - a perfect match for Google's FenceClient or so I thought.
The problem is that the notifications I'm getting are not really related to times I configured in the fence - sometimes the notifications are minutes/hours late and sometimes I'm not getting those notifications at all.
What's weirder is that all Google's examples are still using the deprecatedGoogleApiClient.
Technical issues:
I defined these two permissions in the manifest:
uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
uses-permission
android:name="android.permission.ACCESS_COARSE_LOCATION"
Awareness is activated in the Google console and I have the API keys defined in the manifest.
I tried to use both (one of them in each time) BroadcastReceiver and JobIntentService using PendingIntent.getBroadcast and PendingIntent.getService. Both of them also defied in the manifest.
I'm building the AwarenessFence like this: TimeFence.inIntervalOfDay(dayOfWeek, TimeZone.getDefault(), startTimeOfDayMillis, stopTimeOfDayMillis); start and stop times are in milliseconds since the start of the day.
fenceClient.updateFences is completed successfully.
I have some code that detects when there is new voicemail. It's based on a PhoneStateListener.onMessageWaitingIndicatorChanged() implementation (so technically it fires only when the MWI indicator changes, not necessarily for every new voicemail).
It has been working perfectly for many months until 4.x.x updates to the devices.
Now, this works when the device is rebooted, otherwise its very unreliable. I can see the voicemail icon appear in the notification bar, but the debug logs in onMWIChanged stay silent.
I know that with 4.x.x there is a voicemail provider API. Thinking that this may have a connection, I added the android.intent.action.NEW_VOICEMAIL and android.intent.action.PROVIDER_CHANGED intents to my receiver, but they don't fire (in my BroadcastReceiver onReceive) either (my app's minSdkVersion is 8).
This is a post from Android Developers about the Android 4.0 APIs.
http://developer.android.com/about/versions/android-4.0.html
If you scroll down there is a section about Voicemail Providers where it explains:
Because the APIs currently do not allow third-party apps to read all the voicemails from the system, the only third-party apps that should use the voicemail APIs are those that have voicemail to deliver to the user.
However, I assume if you are trying to receive voicemails from a third party and not from your service then this still may be possible. Check out this link about VoicemailContracts where I believe it says you need the permission ADD_VOICEMAIL in your manifest to use the actions you are using above.
http://developer.android.com/reference/android/provider/VoicemailContract.html
There are also samples that I did not get a chance to look at called Voicemail Provider Demo in your SDK. I hope this helps.
It does require the READ_PHONE_STATE permission. Although, if it worked before you must of had it set.
See LISTEN_MESSAGE_WAITING_INDICATOR.
Yesterday I wanted to deploy/publish my first Android app at google play store but get stuck on the STICKY_BROADCAST permission that is needed/added.
Explanation on the google play store permission tab of the app:
SEND STICKY BROADCAST
Allows the app to send sticky broadcasts, which remain after the broadcast ends. Malicious apps may make the tablet slow or unstable by causing it to use too much memory. Allows the app to send sticky broadcasts, which remain after the broadcast ends. Malicious apps may make the phone slow or unstable by causing it to use too much memory.
I don't want that users may think that my app is an evil or slow app (BECAUSE I DON'T USE ANY STICKY_BROADCAST functionality in my CODE). How can i remove this permission or is it required by Adobe Air? Just one article found on the adobe site (with sort of same question) but without an answer.
In the app.xml configuration I defined only two permissions:
<uses-permission android:name="android.permission.INTERNET"/>
<uses-permission android:name="android.permission.VIBRATE"/>
I use the internet connection to get some configuration for the app. I use the vibrate ane of adobe examples to vibrate the phone when the user tap the screen.
Why is the permission SEND STICKY BROADCAST needed/added to the package when I deploy/publish the app and what can I do to avoid it. Or better: Is there a way to avoid this permission?
I have the same problem and I just discovered it was caused by the adobe air I packaged together with my apk file.
Either you tell the user to download adobe air or get a newer version of flex.
Sorry I am late, I started working with flash just last week.