I want to display health-service data such as step, pace, etc in AmbientMode.
But HealthServices(using ExerciseClient https://developer.android.com/training/wearables/health-services/active) seems to go into Sleep state when entering ambient mode.
I tried using AmbientUpdate with AlarmManager, but HealthServices did not wake up. Please let me know if you have a good way to solve this problem.
I want to change the data of the screen in the middle in AmbientMode.
Please help me.
Please add the relevant code that shows how you are setting up the connection to HealthServices. It will make it easier for people to help you. In the meantime, here are some suggestions for you to look into:
ExerciseClient will only send you data when you have an active workout with a listener set. It sounds like you do get updates in interactive mode so I'm going to assume that this part is working for you. Make sure that you don't accidentally end your workout e.g. in onPause or some other life cycle method/function that is called when the app loses focus (this happens when the device enters ambient mode).
Make sure that you have a Foreground service set up as outlined in the spec, and that you have the required permissions. Otherwise, you might run into issues when the device enters ambient mode and your app is sent to the background.
Use a continuously-running ForegroundService in conjunction with ExerciseClient to ensure correct operation for the entire workout.
Using a ForegroundService is essential when requesting location data. Your manifest file must specify foregroundServiceType="location and specify the appropriate permissions.
Note: If your app experiences AUTO_ENDED_PERMISSION_LOST errors, this is likely caused by a missing ForegroundService with appropriate location permissions.
Worth noting is that when the device is in ambient mode you will get data less frequently. HealthServices will do more batching of data in order to minimize the impact on battery life. The frequency and batch size varies based on the type of metric you are requesting. Make sure that you allow enough time for data to come through, and that you are parsing the batched data points correctly.
Make sure that you give enough time for the ExerciseClient to flush all data points when you end your workout or you might lose data.
Finally, if you're not actually tracking a workout, you might be better off using the PassiveMonitoringClient.
To receive data updates in the background, use the PassiveMonitoringClient. Your app must have a BroadcastReceiver declared in its AndroidManifest.xml. When you register to receive updates from Health Services, they will be delivered to this receiver.
Related
I'm developing a location aware app. This app will start tracking users when they are in their workday. These are the requirements:
The service should run on a regular basis (every 30 or 45 min).
It won't matter if the service does not trigger at the same basis everytime.
The service needs to upload data to our firestore db.
I doesn't need to be triggered on specific conditions (data is on, phone is charging, etc...)
I need this to run even if the user restarts his phone.
We may need to track the distance traveled by the user. (This is not a requirement per se, but it may be a feature someday)
I know there are a lot of ways to achieve this, but I have not decided which is the option that best fits my scenario. This is what I've thought so far:
Foreground service combined with BroadcastReciever in case the phone is rebooted
Background service using the new jetpack's Workmanager.
Which will the best solution? Do you think there is a better solution than those?
Thanks!
Was thinking create a GPS location tracker so when they are in work premise as well as outside it kinda shows.
Then consider adding the number 5 of the above. Like you said there could be mire awesome solutions than these so lets wait for options.
I'm developing a set of complications that I would like have regardless of the other installed apps and watch faces. Yes, at some point I am reinventing the wheel, but at the same time I am using this as a learning project. This will also ensure that I always have all the complications I use, available and that they all have the same format and style, instead of relying on 3rd party apps to provide them separately.
The set will have complications for Heart rate, gps coordinates, hours, minutes, seconds, dd/MM date, dd/MM/yy date, battery, etc.
When I started programing all this I found several problematic pieces (most likely because this is the first time I develop complications, or an app for android wear for that matter) and hence this question.
Note that some of this behavior might be specific to the Huawei Watch 2 LTE.
1) Upgrade interval push / pull.
I understand complications as data providers, whose only responsibility is to provide the data to whatever watch face is calling them. This means that we are not certain (and we rely on the watch face developer) to know about the complication and request updates accordingly. This turns some complications completely useless if not updated in time (for example display the Seconds). Could also leave to complications displaying old data (for example old GPS coordinates, old heart rate bpm).
So ok, I decided to implement ProviderUpdateRequester with the AlarmManager to push data to the watch face. The problem again, is with complications that should happen faster, like seconds, as Android will block pending intents if they are schedule too often. So in order to get around that, I decided to use Android handlers within the same service instance, which turn out to be not a good idea because of the next topic.
2) Complication lifecycle
By debugging, I found out that the instance of the ComplicationProviderService object that is executing onComplicationActivated, onComplicationUpdate, onComplicationDeactivated can be different. This means that this is not a sticky service (single instance) that will be always running, but every update creates a new instance of the service. This is problematic because of heavy initialization complications: for example GPS, or Heart Rate monitor that need to listen for new values and it might take a while to retrieve the first value. And also, for those complications that can't rely on AlarmManager, and/or need to keep some sort of state between updates executions.
3) Display aware service
To get around the previous point , let's say you have static variables on your complication service , which are initialized onComplicationActivated and disabled at onComplicationDeactivated. For example, this could be getting a reference for the LocationProvider and starting listening for location updates. This will ensure that each invocation to onComplicationUpdate will not have to perform the heavy/cold initialization and will have access to the most up-to-date data.
However, this also means that your logic will executed regardless if onComplicationUpdate is called or not.
When in ambient mode (or screen off) the watch face can decide not to update the complication by not calling onComplicationUpdate, but it's not aware of our static logic, nor the ComplicationProviderService has a callback invocation for when the screen goes into ambient mode or turns on/off. This is a problem, because in our example, if the screen is off, we are still going to be listening for GPS coordinates, and most likely draining the battery.
Sure, we can deal with this by using a combination of BroadcastReceiver (Intent.ACTION_SCREEN_ON/OFF) and DisplayManager.DisplayListener, but then again, not sure if i'm taking the correct path here, because this will mean that we are now creating services that need to be statically aware of the state of the display.
4) Detect screen on/off
The BroadcastReceiver for Intent.ACTION_SCREEN_ON/OFF works as expected when ambient mode is disabled, but it doesn't it's enabled. When ambient mode is enabled, Intent.ACTION_SCREEN_OFF is dispatched when going into ambient mode, but Intent.ACTION_SCREEN_ON is not dispatched when coming out of ambient mode. While a bit more complex, this can be accomplished by using DisplayManager.DisplayListener to get updates on the onDisplayChanged callback.
TL;RD
1) How do you ensure watch faces display your complications in a timely manner to always have correct and most up-to-date information?
2) How do you deal heavy/cold initialization of a ComplicationProviderService if everytime onComplicationUpdate is called the service instance is different?
3) Is making a long running service display-aware something crazy to do?
4) Technically the screen is still on when in ambient mode, so why is Intent.ACTION_SCREEN_OFF being broadcasted? Why isn't Intent.ACTION_SCREEN_ON/OFF symetrical when ambient mode is enabled?
5) Maybe complications shouldn't be use for exposing realtime information?
Thanks a lot
A couple of things to unpack:
Complications are not meant to be updated frequently (think minutes, not seconds) - this is to preserve battery.
ProviderUpdateRequester is designed more for (on average infrequent) irregular updates like messages coming through a chat app.
Time dependent complications - there are not an "update" as such but Wear provide ways for developers to count up / down from certain time and for displaying date related field (world clock, day of the month) without the provider sending the system updates all the time. For this last one, please refer to docs for ComplicationText.TimeDifferenceBuilder
and ComplicationText.TimeFormatBuilder.
For your use case, a more appropriate thing maybe to consider an always-on app. User uses it for a certain time period for a specific purpose so they explicitly agree to use to use more battery to track things like GPS or heart rate. For example, a lot of running apps on Wear do this.
I hope this helps.
What I want to do is is there a very way to prevent user from turning off Mobile Data & Location services?
My scenario is this, I am creating a mobile application for a big project we have now. This application is restricted for the use of their employees going out of the field, now this phone by any means should not turn off mobile data and location services as I have an application service that sends constant location data to the administration API.
OR maybe an existing application that prevent native functions like this from being accessed. This may sound crazy but I just have thought if there is something like this.
Thank you!
I hope someone could enlighten me.
No, you can't do that.
Even if you could, it would not solve anything, because there are many other reasons why those services may not work. For example when one is driving through a tunnel and there is no signal or out of town there may sometimes be no signal or the network may be overloaded or something. So you can't rely on these services anyway. Intermittent loss of connectivity is pretty common in mobile devices. You will have to take it into account (log data and send them when you succeed in reconnecting).
If the users need the application, and connectivity in it, to do their job, they won't be turning it off, because they need it. So all that is needed is to create a notification when connectivity and/or location is lost so the user can do something about it if:
the application fails to connect when they turn it on at the start of their shift or
the application looses connection for extended period of time for whatever reason.
And of course if there is somebody in the company using the data (some dispatcher), which I suppose there is, they will notice the particular worker is not sending anything and will try to contact them by calling or something. These should take care of mistakes and faults.
If the users don't need it and it is intended to spy on them (so they may have a reason to disable it), it is probably illegal anyway.
You cannot prevent user from turning off Mobile data. But you can simple record location in a file with time while data is off and send it immediately after user turn on the data.
That is impossible unless the device is rooted.
And it makes perfect sense, because that would compromise the user's experience of Android and/or security.
You must anticipate circumstances like the user turning off the data or connection and act appropriately (for example gracefully stall your connections with the internet and resume them later, inform the user that his device has been disconnected from the internet and that your application requires internet access etc...).
I am eager to know how ActivityRecognition which is in GooglePlay Services works?
I think activities are recognized by accelerometer data.Is it right?.Please give me the details how it goes?
I was looking for this answer also and your post was one of the top results on Google. I did a little more digging and found this https://developer.android.com/reference/com/google/android/gms/location/ActivityRecognitionApi.html which says:
The activities are detected by periodically waking up the device and reading short bursts of sensor data. It only makes use of low power sensors in order to keep the power usage to a minimum. For example, it can detect if the user is currently on foot, in a car, on a bicycle or still.
It doesn't explicitly say which sensors it uses, but we can safely assume that accelerometer is one of them. Since it says sensors (plural) it evidently uses others. But since it says low power you don't have to worry about it using GPS or anything like that. However, it does say that it wakes the device up which would bring it out of its super power saving mode. So, even though it is low power you still may not want it running every 5 seconds all day long. The documentation further down says:
A common use case is that an application wants to monitor activities in the background and perform an action when a specific activity is detected. To do this without needing a service that is always on in the background consuming resources, detected activities are delivered via an intent. The application specifies a PendingIntent callback (typically an IntentService) which will be called when activities are detected. See the documentation of PendingIntent for more details.
Hello
In my android application i would like to get Time since when the app is opened.
Initially what i tried was getting the time when the app is loaded from the server and then taking the difference with the current time from the device.But by doing that if the user changes the time then i willnot be getting the actual time.
Its not posiible to hit the server again for the same.
Is there any way to achieve this in android?
Please share your valuable suggestions.
Thanks in advance:)
Try the "SystemClock" class, "uptimeMillis()" method.
Store the result in a variable when the app starts.
Echoing what I said for your other question, you first need to become familiar with the activity lifecycle and understand the novel meanings (almost meaninglessness) of common words like "open" and "start" in the life of an android app.
There isn't any way you can prevent the user from changing the system time - you just don't have the right to do that to users. Normally this should be a rare event, unless you do something that makes them want to, such as lock them out of a free version of your app after so many minutes. (However if the phone is on a mobile network, presumably the mobile network occasionally adjusts its time to correct for errors in the device's oscillator, or administrative time changes)
What you can do is check the system time on every entry point to your application. If it ever goes backwards, well... something is going on. If the clock has been set back, you could assume no time between the calls with the negative time difference and resume your time meter from there, at least keeping all the previous used time in your record.
It may be that there are cpu cycle counters which you could query and correlate to system time, but this may be highly device specific and may in fact be resettable. And it may get weird if the cpu frequency is demand throttled.
You might be able to set a countdown timer as a bound on the maximum possible time between entry points at which you could meter. I don't know if these work reliably across system time changes or not - ideally they would. Testing or reading the source will reveal.
Use elapsedRealtime in your onCreate() store it. More reliable.