Status Update
No update yet.
Comments
vi...@google.com
vi...@google.com
Thank you for reporting this issue. We have shared this with our product and engineering team and will update this issue with more information as it becomes available.
ct...@google.com
Can you describe exactly what version of Android Studio + SDKs you're using? This is not intended behavior, and does not appear to reproduce on physical Android products.
lf...@google.com
Hi, can you try this also on AOSP, non-Google-APIs variants of the emulator system images?
lb...@gmail.com
@3 I have a feeling this is caused by the IDE. I've tested now on stable version and it works fine, and on canary it doesn't.
See attached videos, comparing canary vs stable.
In addition, I'm not sure if it's related, but maybe this is also problematic to have "pendingShowList " as null in this case:
val pendingShowList = PendingIntent.getActivity(this, 1, Intent(this, AlarmsListActivity::class.java), PendingIntent.FLAG_UPDATE_CURRENT)
manager.setAlarmClock(AlarmManager.AlarmClockInfo(timeToTrigger, pendingShowList), pendingIntent)
Can you please tell me if it's considered ok to have it null instead of a real PendingIntent?
Info of the canary:
Android Studio 4.0 Beta 1
Build #AI-193.6494.35.40.6220182, built on February 19, 2020
Runtime version: 1.8.0_212-release-1586-b04 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0
GC: ParNew, ConcurrentMarkSweep
Memory: 7964M
Cores: 12
Registry: ide.new.welcome.screen.force=true
Non-Bundled Plugins: String Manipulation, com.longforus.kotlincodesorter, com.mistamek.drawablepreview.drawable-preview, ignaciotcrespo.github.com.vector-drawable-thumbnails, izhangzhihao.rainbow.brackets, org.intellij.plugins.markdown
@4 Hi, this was performed on emulator and Pixel 4 with Android R.
See attached videos, comparing canary vs stable.
In addition, I'm not sure if it's related, but maybe this is also problematic to have "pendingShowList " as null in this case:
val pendingShowList = PendingIntent.getActivity(this, 1, Intent(this, AlarmsListActivity::class.java), PendingIntent.FLAG_UPDATE_CURRENT)
manager.setAlarmClock(AlarmManager.AlarmClockInfo(timeToTrigger, pendingShowList), pendingIntent)
Can you please tell me if it's considered ok to have it null instead of a real PendingIntent?
Info of the canary:
Android Studio 4.0 Beta 1
Build #AI-193.6494.35.40.6220182, built on February 19, 2020
Runtime version: 1.8.0_212-release-1586-b04 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0
GC: ParNew, ConcurrentMarkSweep
Memory: 7964M
Cores: 12
Registry: ide.new.welcome.screen.force=true
Non-Bundled Plugins: String Manipulation, com.longforus.kotlincodesorter, com.mistamek.drawablepreview.drawable-preview, ignaciotcrespo.github.com.vector-drawable-thumbnails, izhangzhihao.rainbow.brackets, org.intellij.plugins.markdown
@4 Hi, this was performed on emulator and Pixel 4 with Android R.
lb...@gmail.com
@3 BTW, this seems to affect WorkManager and JobScheduler too.
Please check those as well.
Please check those as well.
ct...@google.com
Yup, canceling of jobs (which underly WorkManager activity on recent versions of Android) is also expected when there's a force-stop operation involved. The bug you're running into is that *something* is inappropriately causing a force-stop when you swipe the task out of recents.
Regarding a null "show" intent in an alarm clock alarm: you won't currently crash as a result, but it's unfriendly and may be considered a sign of malware. It's intended to provide a UX path for the user to go from "hey, something has scheduled an upcoming alarm clock event..." to accessing the app in question to manipulate that event.
Regarding a null "show" intent in an alarm clock alarm: you won't currently crash as a result, but it's unfriendly and may be considered a sign of malware. It's intended to provide a UX path for the user to go from "hey, something has scheduled an upcoming alarm clock event..." to accessing the app in question to manipulate that event.
lf...@google.com
Yahan, can you try reproing this in both the standalone emulator and Studio debugging scenario?
lb...@gmail.com
@7 So you say that somehow using canary of Android Studio will causes recent-tasks removal to do force-stop of the app?
My guess is that it will occur on previous versions of Android, right?
As for null, what exactly does this PendingIntent do? AlarmManager doesn't even have to show any UI. It can start a BroadcastReceiver that may or may not show something. In some cases it might show just a notification instead. How does the user see this "UX path" ?
How come the docs don't tell anything about this?
All it says is this:
"
PendingIntent: an intent that can be used to show or edit details of the alarm clock.
"
https://developer.android.com/reference/android/app/AlarmManager.AlarmClockInfo#public-constructors_1
It doesn't say that it's ok to use null here. Doesn't say anything...
Can you please update the docs?
My guess is that it will occur on previous versions of Android, right?
As for null, what exactly does this PendingIntent do? AlarmManager doesn't even have to show any UI. It can start a BroadcastReceiver that may or may not show something. In some cases it might show just a notification instead. How does the user see this "UX path" ?
How come the docs don't tell anything about this?
All it says is this:
"
PendingIntent: an intent that can be used to show or edit details of the alarm clock.
"
It doesn't say that it's ok to use null here. Doesn't say anything...
Can you please update the docs?
ct...@google.com
*Currently* that PendingIntent is not used, but it's part of the API because Android SysUI might choose to start using it in the future as the underlying action of a tappable affordance for the user to navigate to your app for interacting with whatever the alarm clock event's underlying purpose is.
ya...@google.com
Would you try it on a user build system image (the "playstore" image, or those that don't have root access).
Android Studio will try debugger connection on all debuggable processes. Maybe something goes wrong there? (The "playstore" image will make all system processes non-debuggable.)
Android Studio will try debugger connection on all debuggable processes. Maybe something goes wrong there? (The "playstore" image will make all system processes non-debuggable.)
lb...@gmail.com
@10 Since API 21 till API 29 (and probably 30), it's advised to use something that isn't even used anywhere?
API 21-29 is just "currently" ?
:)
@11 What's wrong with what I've shown? It's on both Pixel 4 device (without root yet, sadly, as R doesn't have it yet) and on emualators that have Play Store.
API 21-29 is just "currently" ?
:)
@11 What's wrong with what I've shown? It's on both Pixel 4 device (without root yet, sadly, as R doesn't have it yet) and on emualators that have Play Store.
lb...@gmail.com
@10 I think you are wrong.
When I set an alarm, I can see it in the notification drawer, and click on it:
https://stackoverflow.com/a/34699710/878126
It's not quite intuitive, and I wonder how many users really use it, but can I use the same PendingIntent that is used as the one that is handled by the trigger to the alarm?
Also, not all alarms are alarm clock ones, so is there a way to avoid it being shown as such?
When I set an alarm, I can see it in the notification drawer, and click on it:
It's not quite intuitive, and I wonder how many users really use it, but can I use the same PendingIntent that is used as the one that is handled by the trigger to the alarm?
Also, not all alarms are alarm clock ones, so is there a way to avoid it being shown as such?
ct...@google.com
lf...@google.com
Hi Chester, we are only seeing this when the app is launched via the green play button from studio, and not in an indepdent session such as when sideloading the apk or when clicking on the app icon from the device. Would there be any force stop logic triggered on recents swipe or process death when Studio is monitoring?
ct...@google.com
Re #13:
In general you do not want to use the same PendingIntent as the actual alarm, otherwise your code will think the alarm itself fired if the user tries to use the UI affordance. You should use an activity launch Intent that brings the user to a relevant place in your app's UI.
In general you do not want to use the same PendingIntent as the actual alarm, otherwise your code will think the alarm itself fired if the user tries to use the UI affordance. You should use an activity launch Intent that brings the user to a relevant place in your app's UI.
du...@google.com
Yes. If you Rerun (on top existing Studio session) or shut down studio, it potentially triggers AndroidProcessHandler to kill the outstanding session, which calls force-stop. This was the behavior all the way back shortly after Instant Run launched in...2.X? Note the mechanism could have been bugged and after I fixed it, "force-stop" finally triggered. If you're referring to the logcat Terminate VM button (looks just like the Stop button), then that was recent (ported "force-stop" over in November).
I only recently learned about the existence of "kill" and its difference to "force-stop" (I inherited the code). If the general use case for devs is to retain alarms/scheduled processes/etc..., then I can certainly switch over to use "kill" instead (and add an extra utility button for "force-stop"?). I'll loop in my PM to double check.
I only recently learned about the existence of "kill" and its difference to "force-stop" (I inherited the code). If the general use case for devs is to retain alarms/scheduled processes/etc..., then I can certainly switch over to use "kill" instead (and add an extra utility button for "force-stop"?). I'll loop in my PM to double check.
du...@google.com
lblb636@ Does this behavior happen back in, say, 3.5? 3.6 may have this change as well, but I'm not sure on the integration timeline...so try 3.5 instead if you have it.
lb...@gmail.com
@16 Please let recent tasks work as on normal cases.
Don't make Android Studio interfere.
Don't make Android Studio interfere.
lb...@gmail.com
@17 I don't know. I tested only on the current stable version. 3.6.1
vi...@google.com
k....@gmail.com
I tried it on android studio version 3.6.1 It did not work. Though i launched the app from launcher, it dd not work. The following code is working only if the app is present in recent apps list, else it is not working.
alarmManager.setAlarmClock(new AlarmManager.AlarmClockInfo(System.currentTimeMillis() + 60 * 1000, null), pendingIntent);
However your work around sample code using foreground service is working great.
I don't think this is android studio problem.
alarmManager.setAlarmClock(new AlarmManager.AlarmClockInfo(System.currentTimeMillis() + 60 * 1000, null), pendingIntent);
However your work around sample code using foreground service is working great.
I don't think this is android studio problem.
lb...@gmail.com
@20 I have no idea. You tested the exact same project I've published, and for you it doesn't work as I've shown on the video?
See here the videos and the sample:
https://issuetracker.google.com/issues/150080941#comment5
See here the videos and the sample:
vi...@google.com
Thank you for your feedback. We assure you we are doing our best to address the issues reported, however our product team has shifted work to higher priority bugs and may not be able to handle this bug. As for now, we will be closing the bug as won’t fix obsolete.
If you are still facing the issue recently, we request that you log a new bug along with the bug report herehttps://goo.gl/TbMiIO .
If you are still facing the issue recently, we request that you log a new bug along with the bug report here
jo...@google.com
Moving to Studio...not sure why this was never moved to the Studio tracker.
lb...@gmail.com
@23 Do you still need me to try to reproduce it? Or you've succeeded?
lb...@gmail.com
@25 Was it fixed for all Android versions, Or just starting from some version?
Also, how come you mark it as a duplicate of the other issue?
The other issue is about a service, and here I talk about scheduled stuff. There is no service...
Also, how come you mark it as a duplicate of the other issue?
The other issue is about a service, and here I talk about scheduled stuff. There is no service...
ac...@google.com
#26 we discovered that the issue is actually caused by Android Studio not a bug in the Android OS.
lb...@gmail.com
@27 So again, does it work on all Android versions?
And on which Android Studio versions does the fix work on?
Why have you marked it as a duplicate of an Android-service issue , and here it's about scheduled stuff?
And on which Android Studio versions does the fix work on?
Why have you marked it as a duplicate of an Android-service issue , and here it's about scheduled stuff?
ac...@google.com
Yes, it should work on all Android version as far as we can tell.
4.1.1 and all 4.2+
We marked it as duplicate because both bugs are caused by the same issue and have the same fix.
4.1.1 and all 4.2+
We marked it as duplicate because both bugs are caused by the same issue and have the same fix.
lb...@gmail.com
@29 Confirmed. Works fine. Tested on: Android Studio 4.1.1
Please fix other weird things. I've found one that's extremely annoying, when working on an app that uses notification listener (it almost always requires double build&run).
Please fix other weird things. I've found one that's extremely annoying, when working on an app that uses notification listener (it almost always requires double build&run).
ac...@google.com
Can you file another bug for any weird issue you found?
We rely on this tool to keep track on what needs work and what doesn't. It is very easy for us to lose track if you are reporting a separate issue at the end of a bug entry that we already marked as Fixed / Dup'ed.
We rely on this tool to keep track on what needs work and what doesn't. It is very easy for us to lose track if you are reporting a separate issue at the end of a bug entry that we already marked as Fixed / Dup'ed.
lb...@gmail.com
@31 Already did:
https://issuetracker.google.com/issues/174431980
And I think I reported about accessibility service too, but there the issue is that it gets reset, I think, which is weird because updating the APK shouldn't affect permissions state.
And I think I reported about accessibility service too, but there the issue is that it gets reset, I think, which is weird because updating the APK shouldn't affect permissions state.
Description
I've shown here about API 29.
- Steps to reproduce the problem (including sample code if appropriate).
1. Have a device/emulator that has no pending alarms set. I prefer an emulator as it's clean of such things.
2. In code, set an alarm about 30 seconds from now, using:
Check that indeed it was set, by using :
This should return you the nearest alarm being set, as the docs say:
"Gets information about the next alarm clock currently scheduled. The alarm clocks considered are those scheduled by any application using the setAlarmClock(AlarmManager.AlarmClockInfo, PendingIntent) method.
"
You can check it multiple times. You can also close the app using the back key, return to it, and check again.
3. Close the app that has scheduled the alarm by removing it from recent tasks.
4. Perform the check on step 2 again.
- What happened.
No pending intents. The scheduling was completely removed.
And indeed, if you wait long enough, you will see that it won't trigger.
- What you think the correct behavior should be.
Should remain.
That's what the docs say.
The docs don't say anything about them being removed in any special case. The only way to cancel them is via calling this:
But it was never called.
If there are special cases here, it should be documented, including explanation about it and how to overcome it in case we don't want them to be cancelled.
The attached sample is also available here: