I have refer this link to implement but dialog not showing.
override fun onResume() {
super.onResume()
val appUpdateManager = AppUpdateManagerFactory.create(this)
appUpdateManager.appUpdateInfo
.addOnSuccessListener {
if (it.updateAvailability() == UpdateAvailability.DEVELOPER_TRIGGERED_UPDATE_IN_PROGRESS) {
// resume the update flow
appUpdateManager.startUpdateFlowForResult(
it,
IMMEDIATE,
this,
123)
}
}
}
decrease my current version and check but "addOnSuccessListener" listener not calling.
I have the same confusion when I implemented this. But It takes time.
It will not work immediately. You will get it in 24 hours as per my experience.
For more information, you can have a look at this S.O. answer. I followed the same and It's working now.
It worked for some device on the same day and for other devices, in-app dialog came the next day. We've tested with various devices without any issue. you just need to wait for a while.
Related
When i was trying to developing GPS tracking Android APP with Google Activity Recognition Transition API, I had a API-working stop issue.
I thought that it is a problem of device-model compatible but not sure exactly about it because it occurs very irregulary and dose not process any error log for it.
If someone has know about the solution, please give me some good advise for it.
I really appreciate for hearing some good advise to solve this problem.
Android device information:
SDK_INT : 31
RELEASE : 12
BRAND : samsung
An explanation for when not working Transition API:
First of all, Transition API is working good under to device model ‘Android 12’.
But when I try to test on 12 or over version, the API-stoping problem is occurs in 1 days to 1 week.
Also the problem dose not make any error log to find and analysis the exact problem.
Stoped Google Activity Recognition Transition API will work when reboots the device, but not work with re-installation.
Other APP that using Transition API having no problem while my APP is not working.
Also, other APP and my APP can be not working when the Transition API is stopped.
3.Installation in test-phone
Build the Apk or generate a Signed Build generate Signed Build or Apk and upload the
The same problem has occurred when try to test with the uploaded internal version of google ‘Play Store’
4.Sorce explanation
My app has one foregound service is runing.
When the APP is executed first time, the Transition API is runing that insideof the foreground service.
How to activate the API:
val intent = Intent(ACTIVITY_RECOGNITION_EVENT)
val pendingIntent = PendingIntent.getBroadcast(context, 0, intent, if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
PendingIntent.FLAG_MUTABLE or PendingIntent.FLAG_UPDATE_CURRENT
} else {
PendingIntent.FLAG_UPDATE_CURRENT
})
...
val activityRecognitionClient = ActivityRecognition.getClient(context)
// val interval = 20 * 1000L
val interval = 3 * 60 * 1000L
val task = activityRecognitionClient.requestActivityUpdates(interval, pendingIntent)
task.addOnSuccessListener {
...
}
task.addOnCompleteListener {
...
}
task.addOnCanceledListener {
...
}
task.addOnFailureListener {
...
}
// createRequest skip
val activityRecognitionClient = ActivityRecognition.getClient(context)
val task = activityRecognitionClient.requestActivityTransitionUpdates(
createRequest(),
pendingIntent
)
task.addOnSuccessListener {
...
}
task.addOnCanceledListener {
...
}
task.addOnFailureListener {
...
}
task.addOnCompleteListener {
...
}
// In receiver, it work like this:
private val transitionsReceiver = object: BroadcastReceiver() {
override fun onReceive(_context: Context, intent: Intent) {
if (ActivityRecognitionResult.hasResult(intent)) {
val result = ActivityRecognitionResult.extractResult(intent)
...
}
else if (ActivityTransitionResult.hasResult(intent)) {
val result = ActivityTransitionResult.extractResult(intent)
...
}
}
}
val intentFilter = IntentFilter()
intentFilter.addAction(ACTIVITY_RECOGNITION_EVENT)
context.registerReceiver(transitionsReceiver, intentFilter)
Is there any one having this problem?
I’m still working on this problem but can not find the reason of the Google Activity Recognition Transition API stopping.
I would like to know any advice or hint for solving this and appreciate it for your comment.
Am I miss something or having wrong point?
I'm having the same issue as you. It happens on both Sampling API and Transition API. We noticed on multiple Samsung devices but not sure if it is happening on other. I opened a issue on tracker
I'm having a similar issue. Currently what I've found is that when my app can retrieve Sensor.TYPE_SIGNIFICANT_MOTION then Activity Transitions updates come in correctly, but then at some point, sensor is null in my logs and I receive no updates whatsoever. Feels to me that OS blocks this sensor at some point (allows it to fall in deep sleep) and then there's no coming back. :(
I'm using Google guide about in-app review dialog. i'm using standard Google offers:
val manager = ReviewManagerFactory.create(context)
private fun startInnAppReview() {
val requestFlow = manager.requestReviewFlow()
requestFlow.addOnCompleteListener { request ->
if (request.isSuccessful) {
manager.launchReviewFlow(this, request.result).apply {
addOnFailureListener { exception -> Timber.e(exception) }
}
} else {
Timber.e("${request.exception}")
}
}
}
And i need to show this in-app dialog only once when app is installed for 5 days and in use more than 20 minutes. Can you explain an optimal variation of making it? I guess we need to use preferences?
I would use SharedPreferences and two variables, one for installation time and another one to keep track of the time the app is used, then when both satisfy the conditions, show the dialog.
You can schedule tasks using WorkManager, you need to check the docs to decide which task type(s) best suit your use case.
I am trying to implement in-app updates in my android app following the official documentation.
I launched one version of my app on Play Store using internal testing track followed by another version with incremented versionCode.
When I opened the app first time it crashed with the following exception:
Fatal Exception: com.google.android.play.core.install.InstallException: Install Error(-10): The app is not owned by any user on this device. An app is "owned" if it has been acquired from Play. (https://developer.android.com/reference/com/google/android/play/core/install/model/InstallErrorCode#ERROR_APP_NOT_OWNED)
at com.google.android.play.core.appupdate.o.a(o.java:6)
at com.google.android.play.core.internal.o.a(o.java:28)
at com.google.android.play.core.internal.j.onTransact(j.java:20)
at android.os.Binder.execTransactInternal(Binder.java:1166)
at android.os.Binder.execTransact(Binder.java:1130)
But when I reopened the app, the update flow started properly. So maybe the PlayCore library wasn't able to fetch the right data first time and it threw the InstallException.
What I want is to catch all such InstallExceptions but I am not able to find where exactly to put the try-catch block. Which function of AppUpdateManager throws this InstallException? Is it the startUpdateFlow() method?
My code:
private lateinit var updateInfo: AppUpdateInfo
suspend fun checkForUpdate() {
updateInfo = appUpdateManager.requestAppUpdateInfo() // suspend function from play-core-ktx
if(updateInfo.updateAvailability() == UpdateAvailability.UPDATE_AVAILABLE && updateInfo.isImmediateUpdateAllowed) {
startImmediateUpdate(activity)
}
}
fun startImmediateUpdate(activity: Activity) {
appUpdateManager.startUpdateFlow( // Here I am using startUpdateFlow and not startUpdateFlowForResult
updateInfo, activity, AppUpdateOptions.defaultOptions(AppUpdateType.IMMEDIATE)
).addOnSuccessListener { result ->
if (result == Activity.RESULT_CANCELED) {
activity.finish()
}
}
}
Similar question: Android workmanager scheduled worker lost after task killed
The answer here suggests that this is a problem with specific manufacturers, but I am using an Android One phone which has the unmodified OS.
For the most part my PeriodicWorkRequest works as expected, but then for a straight 5-8 hours window, it doesn't get executed at all. I log whenever the request is executed in a log file, and this is how it looks:
As visible in the image, the red box indicates the interval where WorkManager did not run the request. I can assure that the app was never force killed since install. It was cleared from recents some times, but that did not seem to have any immediate effects.
This is how I initialized the request:
PeriodicWorkRequest checkLastSeenRequest =
new PeriodicWorkRequest.Builder(LastSeenWorker.class,
PeriodicWorkRequest.MIN_PERIODIC_INTERVAL_MILLIS, TimeUnit.MILLISECONDS,
PeriodicWorkRequest.MIN_PERIODIC_FLEX_MILLIS, TimeUnit.MILLISECONDS)
.setBackoffCriteria(
BackoffPolicy.LINEAR,
PeriodicWorkRequest.MIN_BACKOFF_MILLIS,
TimeUnit.MILLISECONDS)
.build();
WorkManager.getInstance(this).enqueueUniquePeriodicWork(
"checkLastSeen",
ExistingPeriodicWorkPolicy.KEEP,
checkLastSeenRequest);
And this is the createWork() method of RxWorker:
#NonNull
#Override
public Single<Result> createWork() {
return Single.create(subscriber -> {
FirebaseFirestore firestore = FirebaseFirestore.getInstance();
firestore.collection("users").document("doc").get()
.addOnCompleteListener(task -> {
if (task.isSuccessful()) {
DocumentSnapshot doc = task.getResult();
if (doc != null && doc.exists() && doc.getData() != null
&& doc.getData().get("lastSeen") != null) {
--> // this is where I log
subscriber.onSuccess(Result.success());
} else {
--> XLog.e("No document found to read from");
subscriber.onError(new Error("Document not found"));
}
} else {
--> XLog.e(task.getException());
subscriber.onError(task.getException());
}
});
});
}
From the documentation here my understanding is that in doze mode as well there is a window where all the requests are allowed to execute even as these become less frequent. So why is there a complete blackout for more than 6 hours? Do I need to get battery optimization permissions for it to work as expected? Any help appreciated!
try to check working your code in the Doze mode as described it here
Maintenance windows in Doze won’t happen frequently. First window occurs an hour after last activity, the next after two, the next after four and so on. But it doesn’t matter that much since user isn’t even moving her device anyway.
Some useful information
Maybe you have another choice: Schedule tasks with WorkManager
I was using In App Update API with update type as Flexible using below code
appUpdateManager.startUpdateFlowForResult(
appUpdateInfo,
AppUpdateType.FLEXIBLE,
this,
APP_UPDATE_REQUEST_CODE)
Where the update type is provided as AppUpdateType.FLEXIBLE.
It showcases the correct UI where it provides option for users to either select Update or No Thanks.
As showcased in below image.
However clicking on Update actually showcases a fullscreen UI with progressbar generally associated with Immediate updated instead of performing the update in background.
Using play code SDK version 1.8.X
// Rate this app
// So, make sure you also include that repository in your project's build.gradle file.
implementation 'com.google.android.play:core:1.8.0'
// For Kotlin users also import the Kotlin extensions library for Play Core:
implementation 'com.google.android.play:core-ktx:1.8.1'
Does anyone has a idea why this would be happening?
Thanks in Advance.
Maybe your problem is
override fun onResume() {
super.onResume()
appUpdateManager
.appUpdateInfo
.addOnSuccessListener {
// If an in-app update is already running, resume the update.
if (it.updateAvailability() == UpdateAvailability.DEVELOPER_TRIGGERED_UPDATE_IN_PROGRESS)
startUpdate(it, AppUpdateType.IMMEDIATE) // <<-- !!HERE!!
// If the update is downloaded but not installed, notify the user to complete the update.
if (it.installStatus == InstallStatus.DOWNLOADED) {
nav_progress_download.hide()
popupSnackbarForCompleteUpdate()
}
}
}
When you click Update button, onResume is called.
And updateAvailability() of AppUpdateType.FLEXIBLE is same as UpdateAvailability.DEVELOPER_TRIGGERED_UPDATE_IN_PROGRESS
Check this...
How to know the AppUpdateType at the origin of the DEVELOPER_TRIGGERED_UPDATE_IN_PROGRESS update availability?
https://issuetracker.google.com/issues/153785560