I am based in Germany and publish the "Last Call Widget" on the Android Market. I have been steady improving it over time, but one group of users still complain about it not working on their devices.
My widget listens for the "android.intent.action.PHONE_STATE" intent, and then sets an alarm to update the last call UI in 20 seconds, then 60 seconds, then 5 minutes, 1 hour, etc. This works reliably on all my test devices, even with aggressive task killers (try it yourself). Unfortunately I have a cluster of users with Motorola Droids on the Verizon network who complain that the UI does not automatically update.
I believe Verizon is a CDMA network (we have GSM here in Europe), though the Android API docs don't specify any implementation differences. This could also be a driver issue on the Motorola Droid (we have GSM Motorola Milestones in Europe).
I am wondering if anyone reading is in a position to offer any ideas, or test the widget on a Droid and/or CDMA network to see if they can reproduce an issue (with logs)?
Regards
Mark
Well, while I have DROIDs, none have active Verizon accounts, as I moved my Verizon account to an Incredible. Hence, I cannot test your app, as I cannot place phone calls (except 911, and the police really won't appreciate my calling them just to test your app widget).
You might integrate some Flurry-type logging to see if it's that you are not getting the Intent at all, or if it is somehow not meeting your expectations (e.g., EXTRA_STATE not what you're expecting).
Beyond that, you can use the Build class to detect the DROID and have the alarm go off every N seconds all the time the phone is awake, instead of based on the incoming call. This will chew up more battery, and DROID users with your app who attack you with a task killer will stop those alarms. That's why I'd only do this for the DROID, or any other devices that you determine have similar behavior.
Related
I faced the Android scan stopping issue in background when I am developing my COVID contact tracing app for my company. Here is what I have tried:
Add foreground service
Disable all the battery related optimization options in the phones
Enable the application running in background
Tesging devices:Galaxy S20 and Xperia with Android 10, Huawei with Android 8.
The scan stops immediately when going to background if you don't disable those battery optimization settings and application background update. After you disabled those settings, the scan can run about a couple of minutes(~5 minutes), then still stops. From the blog of David:http://www.davidgyoungtech.com/2017/08/07/beacon-detection-with-android-8, it seems that it is impossible to scan continuesly in background, because the JobScheduler will restart every 15 minutes while each scan lasts ~10 minutes at most. Is this the reality, or this is the best solution that I can scan 10 minutes at every 15 mins cycle?
Background beacon detections are tricky to implement because many small issues can trip you up, and the specific issues vary by Android version, Android manufacturer and sometimes model. While Android 8+ restricts background ranging to every 15 mins using the Job Scheduler, if you add a Foreground Service, you can unlock unlimited background ranging.
A few tips:
Focus first on the Galaxy S20 as Samsung behaviors are better documented and closer to vanilla Android. (Ideally you would test on a Pixel device first.) Only once it works on Samsung, move on to the others.
Using the Android Beacon Library reference app configured with the built-in foreground service, I have seen detections of a standard iBeacon or AltBeacon continue on a Galaxy S10 indefinitely in the background, even with a 1.1 second scan period. See if you can reproduce the same.
Be careful of Doze mode. If the CPU is put to sleep due to the phone being motionless with the screen off and not charging, your detections will stop. You can defeat Doze mode with wake locks, but it has a punishing impact on battery usage. You are better off accepting its limitations and keeping your phone in motion periodically during testing. If you want to get logs to see what is happening, use ADB commands to disable charging when connected via USB or learn to use ADB over WiFi.
When I publish a new version in google play, why is not updated automatically in the final devices? even though the option of automatic update in the devices is activated
It will be updated automatically in devices with automatic updates, but not immediately. Some things that you might not expect:
Devices only checkin to Play about once a day for updates, then do all their updates together, instead of getting a push notification to update when a new version of an app comes out. If the push notification happened, imagine what would happen when YouTube pushes an update. Immediately 2 billion devices would all hit Google Play servers at the same time. This would be like a DoS attack on Google Play. Because different devices check in at different points over 24 hours, the load is spread.
By default devices only update when connected to WiFi and plugged into a power supply. Plugged into WiFi is the option because data can be very expensive for some users. If users want to update on mobile data they can change the setting. Power is because some update operations can use a lot of CPU. Downloading uses the network circuits and decompression and patching can be quite CPU intensive. By waiting until the device is plugged in, Google Play doesn't suddenly drain the battery of a user who is hoping it will last until they get home.
But you should see automatic updates for most users within a day or two of publishing your update. Some users itwill take a lot longer because they have disabled automatic updates or rarely have WiFi and Power at the same time.
I'm working on an Android app that needs to detect if other users of the app are close to each other (lets say within the same room or Bluetooth range). The app needs to be able to detect this without any user interaction.
Geolocation is not an option as this is too inaccurate indoors.
The app runs only on company owned phones that stay on company ground, privacy is not a concern.
All devices are always connected to the same wifi network and BT is always enabled.
My idea is to detect if users are within a close distance of eachother by periodically Bluetooth scanning and checking the results against a list of MAC adresses that contain all the devices that have the app installed.
The MAC adresses of all devices are send to a server, the devices then grab this list of mac adresses from the server to compare to the results of a BT scan.
Problem is, BT and Google's seem to use Advertisement / Discovery patterns where one device acts as the server and one device acts as the client. For this to work properly i feel like the devices need to always be discoverable.
Will an implementation based on Google's Nearby or BT work for my needs ?
Is it possible to detect the presence of a nearby device without it being discoverable ?
As battery life is a concern (need to be able to do this for atleast 8 hours a day) is BLE an option?
You can almost certainly handle 8 hours a day if the phones aren't really used for much else. There are a lot of variables, however.
Many older phones require a different type of scanning using infinite scanner restarts in order to properly report "seeing" a peripheral. This can dramatically decrease battery life.
If the phones are running Marshmallow or later, they have a doze mode which interrupts scanning. This can be circumvented using an AlarmManager, JobService/Dispatcher, or WorkManager. This can dramatically decrease battery life.
If the phones are running Oreo or later, they require a foreground service (persistent notification) in order to prevent the app from being automatically killed by the OS to save battery. The app should also be whitelisted from battery optimization because even with the foreground service, the app will still be killed off by the OS.
Finally, scanning and broadcasting and using location services is pretty expensive battery-wise. If you're attempting to cluster phones and guess their position based upon what other phones are nearby, at some level you'll still need the location data off of the phones to figure out where they're at.
You're much better off just scanning. You could carpet your company property with beacons, where each individual beacon's location is recorded. When the phone "enters a region" (comes within range of a beacon), it should send something to your api reporting which beacon it just found. This will tell you what room/area it's in.
Another less flashy (and potentially less accurate) way to track everything would be via the IP addresses of the wireless access points they're connected to. Use a WorkManager to periodically update an api with some unique ID for the phone and the IP address of the AP. Your IT department should know the locations of each of them. This way you get reasonably good tracking and virtually no battery drain.
We've been working on a custom BLE peripheral gadget and writing an Android app to interface with it. We've discovered a failure mode that we can not seem to figure out.
The peripheral device has a number of characteristics, some of them marked as PROPERTY_INDICATE.
Normally the app works great. In particular, when we issue a gatt.disconnect() eventually followed by a gatt.close(), the device senses the disconnect and returns to advertising mode.
There is a mode the peripheral may enter though where it broadcasts changes to 2 characteristics with PROPERTY_INDICATE every second. When the peripheral is in that mode and we disconnect, the device never receives the disconnect. Somehow the android device (either a Samsung Tab2 or a Samsung S9) stays connected. We know it is connected, because until we power the handheld down, the device won't sense the disconnect. BUT, if you query BluetoothManager.getConnectedDevices() it shows 0.
We've done a number of iterations to try and triangulate on the cause:
Reduce the characteristic count -> NO CHANGE
Reduce the update rate to every 2 seconds -> SUCCESS
Change one of the characteristics to use NOTIFY -> SUCCESS
Interleave the changes so that we change both, but 0.5 seconds out of phase with each other, so they're not the exact same time -> NO CHANGE
Can anyone suggest what might be the issue? Or how to get closer to what's going on?
A quick fix for us would be the 3rd change. For this scenario NOTIFY vs INDICATE isn't that important. But it worries me to make that kind of change without understanding why.
We have an iOS variant of the app that doesn't have any of these issues. The iOS connection works fine (meaning it disconnects correctly) with the two indications happening every second.
After porting the app to use SweetBlue (a commercial offering that I was pretty impressed with actually), this behavior persisted. We will be modifying our peripheral to use PROPERTY_INDICATION sparingly, preferring PROPERTY_NOTIFY for any cases where the extra acknowledgment provided by INDICATE isn't critical.
At the end of the day my take away answer (until someone shows up with a better one) is:
Android and PROPERTY_INDICATE don't mix/scale well. Developer Beware.
I cannot get some Android devices to wake up using the AlarmManager. Following the advice in other StackOverflow posts, I am testing CommonsWares cwac-wakeful demo unmodified, compiled in Eclipse, and sent directly to my tablet devices.
When the screen is on the app wakes every 15 minutes and dutifully writes a log message, if I switch the screen off (short press on the power button) and remove the USB cable, then reconnect say 30 minutes later, there are no log messages for the period during which the device was asleep. The alarm does trigger immediately after I wake the device up (according to the log message timestamp). If I leave the USB cable connected the alarm does trigger even with the screen off, presumably because the device is in "debug" mode.
I have seen this behaviour on an older Android 2.2 tablet and I think it might be a bug in the hardware or OS common to both devices. However, I would like to rule out a bug in the cwac-wakeful utility and "operator error" if possible.
Has anyone else seen this behaviour and have any suggestions about further diagnostics or remedies?
I actually get the same behaviour when I set the built-in clock alarm from the home page, i.e. the A90 and the VEGAn-TAB don't wake up until the next manual power on. Therefore it must be a fundamental problem with the tablets rather than a bug in AlarmManager or WakefulIntentService.