Develop Reference

Android NFC enableReaderMode stopped working; needed to delete and reinstall app?

We have an app utilizing NFC and recently migrated from enableForegroundDispatch to enableReaderMode. Since then, we have been receiving bug reports where the user intermittently has trouble scanning tags.
I was troubleshooting remotely with a customer today who was unable to scan any tags (the app was working through yesterday). Sometimes they would receive an "NFC read error. Try again" message.
When we had them install the older version of our app which uses enableForegroundDispatch, NFC scans worked as intended. Scanning using the NFC Tools app was also working during this time, as was scanning with no app open. We tried rebooting the device and also toggling NFC on / off with no luck. It was just our app.
After much debugging, what appears to have resolved it was to fully delete our app from the device and then reinstall it. The device is a Google Pixel 2 running Android 11.
I have read countless threads about enableReaderMode and am also aware of this bug affecting kiosk apps in Android 11 (but our app isn't a kiosk). I also read about how there is a bug where Android might think our app is not in the foreground.
Is there any credence to the theory that deleting our app (vs. updating the same installed package with different builds) is what resolved this, and if so then what exactly is happening that is causing this?
Edit: I just found the threads about "NFC service dead" and am guessing this is what happened.

I have read the public code for NFC service, I cannot remember it having anything that would be affected differently by update vs uninstall/install other than possibly the Manifest(PackageManager?) permission to use NFC.
I have not looked in to details about how an app update updates the Manifest permissions, but guess an update might not update the permissions if it thinks they are not changed whereas remove/install would probably delete the whole entry and re-add it thus if there was corruption in the permission list a remove/install would likely fix it.
Also if the NFC Service is dead then other App's would not scan as well. I do seem to remember there is something in there to restart the NFC service if it had died.

Android Wear 2.0 - alternative to (deprecated) BIND_LISTENER

I tried really really hard (scanning/trying sample code, reading docs …) but, haven’t been able to figure out how swap out BIND_LISTENER for the new-and-improved CapabilityApi/CapabilityClient scheme.
I recently got a Ticwatch E (from kickstarter) & its running AW 2.0. I came to AW from a Garmin FR-230 & before that, a Pebble smartwatch. I developed similar watchfaces on the Garmin + Pebble platform & one function I included in both, was to vibrate when Bluetooth connectivity breaks (so basically, I don’t leave my mobile phone at home).
I ported my watchface to AW and it works fine w/ BIND_LISTENER in the manifest pointing to my WearableListenerService class - i.e. see logs & pop-up notification. However, I get errors when I try to publish to google playstore `cause BIND_LISTENER is deprecated.
I tried changing the intent-filter to CAPABILITY_CHANGED (I was hoping it was as simple as that). I tried adding onCapabilityChanged() to this WearableListenerService – nothing/no log events.
The links below are to my watchface & the “working” source code on GitHub (w/ BIND_LISTENER). Check-out the manifest + the listener class.
Most of the examples I’ve seen are for activities or for passing data around between wear + mobile – I just want an alert when connectivity changes. A connectivity icon pops up on my watch when BT is gone so, it’s gotta be possible to get an alert.
Newbie Android Wear developer & struggling with the documentation. Appreciate an explicit example, if possible.
https://android-developers.googleblog.com/2016/04/deprecation-of-bindlistener.html
https://play.google.com/store/apps/details?id=com.antonio_asaro.www.marvin_watchface
https://github.com/antonioasaro/Android-Marvin_Watchface
Thanks,
--Antonio

Android Boot Completed Receiver doesn't work on system app

My application contains a BOOT_COMPLETED receiver like described in other threads here. It works perfectly until I changed my app into a system application. Now the Receiver does not trigger the event anymore.
Any ideas for this issue? I'm using Android Kitkat 4.4.2 on a Radxa Rock Pro. Compiled my own image to register the app as system application.

we need more detail to help you, post the code and the manifest, also debug log, in other hand you must use Log.i(TAG, "onReceive."); to know if the problem is in onReceive() or when trying to run the service class.

Unregister android client from aerogear unified push server

I´m facing a problem on handling the register-unregister my activities/services or whatever I use from an aerogear installation.
If I register from a service onCreate() and unregister in onDestroy(), when I uninstall the application, the device keeps registered on server side... If I install the application again, it registers the device again and you can repeat this until you get tired. And, of course, sending a push to the alias given by the user, the messages will arrive once per registration.
Also, each time the application registers to aerogear, the deviceToken is different, meaning that it´s got more to do with a generated hash for each installation than for a unique identifier for the pair (app, device).
So, now the question, how to handle the whole cycle? and I mean, the daily run and the issue about if the user decides to uninstall the app, it gets killed and could not unregister and one month later decides he liked it so much that ends up reinstalling the thing again.
thx.
update
The problem grows as I go testing my application. If I log with two different users in the same device, then I get both user messages and I've got to twist a little bit more the client implementation.
update with aerogear database data
here´s the installation log for two devices with three reinstalls:
id alias deviceToken deviceType enabled operatingSystem osVersion platform variantID
0dd99505-bba9-45e9-bfbf-38621bd41c3d 568b347a5df69915000pig#gmail.com APA91bG9XSPpwbFenw0UETFLRxr2XoFw-HlH5yZpPgoCIVZLnv0QSqCx5iKqqhJ-tWF5CRISbydv6ItWZKxklD8OPtfxvuq1ekQEI3XkbFajsmGIJ3yjUIC0MGw3v2ITVd6byVtZLsI9uTfiDXyeNrXTxprzVxr9ng ANDROID 1 android 4.4.4 android 4ae83272-5db7-41f6-879d-c907a39bd3fc
0ee3619f-0eb4-4139-b1fa-fe3403eb380c 1c24c6e05b58738f000edu#gmail.com APA91bFrNknt7d57dFR5DagE4Nf1bCVyB93Jl1xU5_qELwYn5JmjYUpXrLE10yC6beZdUgae0ZgtKXgLI4LI-E_ROAFEI4xi-ZPhuE8UZB6K05L_mIWSk7kt32D7S9G2clw3WG51zvcQmaeg8xsG_VW-rnwfKZQVcg ANDROID 1 android 4.4.4 android 4ae83272-5db7-41f6-879d-c907a39bd3fc
107d4dac-fbcf-4f82-9135-702b83d06f7f 568b347a5df69915000pig#gmail.com APA91bEaN4AMJPZgML931rO4AdrMudfTmGVmYPqqARVLX1RxIfyYB46fGxlSK0w7g3qnU2d_cVOBi907TFIMoxBaOe3bvKI8DqsacrXMmT-DjhFoFRS2z4QCec9u0aRPm-EB9UwhfMrE3RrctdxDdNCQ0douuppYVQ ANDROID 1 android 4.4.4 android 4ae83272-5db7-41f6-879d-c907a39bd3fc
161474b6-067d-4b54-a750-e21a9896814e 1c24c6e05b58738f000edu#gmail.com APA91bGFE6cxLcxPDoRmv-HEIpA2jQndccrCryuR3q5BN4PG3EyHxISFoMCIwaPPXX8BIinrJOvNCbwpIrVOKw_mSv5TcLZnSgonR1grpiRkJ0mmwbFCme2CrwoMpkLkVUP7ZjwnYsr0HR3MKzmJLakrnlN-eMKr-g ANDROID 1 android 4.4.4 android 4ae83272-5db7-41f6-879d-c907a39bd3fc
a5cddabe-1c00-4369-b4cc-f6c5da8f8740 568b347a5df69915000pig#gmail.com APA91bGmFT7NCpfb1q4WHFK2wmQCQdMtW9ulQLiZYwrt9oyU4mqv9gCBN959pCw_wKy2zHw-JBU0p5SCzdpKN5l8i7uqPWk24ORHKE1Vf6rRUINkIRJheKVT6V6Wk38WQ7Rw1AgrqYXZN7WUImVSgd5cqq_p8lLISg ANDROID 1 android 4.4.4 android 4ae83272-5db7-41f6-879d-c907a39bd3fc
f7514716-68d9-4d00-837a-f1f9da503151 1c24c6e05b58738f000edu#gmail.com APA91bHTFJE7-nz_KB4aa2RUcEnFTVB0IzQZ-ZffPTujLWgi60xTMUeAet6YoUZJnXKnhBOSdAPgoaLDW18PWnwKXtc2MXxKjMYQQENNDdOxKQIV4fnMrAFWfwD_VT6x5XOJUWdQovGUwXiMX9SshCDvZJ4QnM1x_w ANDROID 1 android 4.4.4 android 4ae83272-5db7-41f6-879d-c907a39bd3fc

I think the first problem was a UnifiedPush server bug, but it's already fixed.
About your update when you register a device on UPS the UPS don't know about your users, so you will need to send some information with your message and control it on your client.

Android: detect when app finishes installation

I want to detect when an application in android has finished installation without using a brodcast receiver. Is this possible?

you might be able to read logs instead , but that requires "bad" permission , which is no longer supported as of API 16 (jelly bean) .