Fixed
Status Update
No update yet.
Comments
vi...@google.com
ac...@google.com
Hi,
set title before set Toolbar as ActionBar
Toolbar toolbar = (Toolbar) findViewById(R.id.my_awesome_toolbar);
toolbar.settitle("ddidid");
setSupportActionBar(toolbar);
set title before set Toolbar as ActionBar
Toolbar toolbar = (Toolbar) findViewById(R.id.my_awesome_toolbar);
toolbar.settitle("ddidid");
setSupportActionBar(toolbar);
lb...@gmail.com
Hi,
Thanks for the answer :-).
I am searching for a solution to change the title some times (E. G. changing view). Or should i use for every fragmant an own toolbar?
Thanks for the answer :-).
I am searching for a solution to change the title some times (E. G. changing view). Or should i use for every fragmant an own toolbar?
lb...@gmail.com
Hey not working for me?????
lb...@gmail.com
I,m trying to change the toolbar title when activity run for the second time but it is working only for the first run.
ac...@google.com
hi,i get the same issues,but i cant fix it. :( can u tell me what's wrong?thanks....
lb...@gmail.com
Thank you for your feedback. We assure you that we are doing our best to address the issue reported, however our product team has shifted work priority that doesn't include this issue. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with latest bug report here https://goo.gl/TbMiIO .
ac...@google.com
Unfortunately I can't think of any viable commands in the the launch configuration that can work around this.
lb...@gmail.com
@8 Can you please add more options to this UI of Android Studio?
Maybe not just actions before, but also after the app is installed?
This way, at least developers who use Android Studio might be able to use the workarounds you've offered, such as temporarily disable/deny the notification-listener, and after install, enable/grant it again.
It's a good addition regardless of this issue I write, no? Maybe there are other cases that this could be useful .
Maybe not just actions before, but also after the app is installed?
This way, at least developers who use Android Studio might be able to use the workarounds you've offered, such as temporarily disable/deny the notification-listener, and after install, enable/grant it again.
It's a good addition regardless of this issue I write, no? Maybe there are other cases that this could be useful .
sj...@gmail.com
Temp workaround I'm using is to attach a dynamic build suffix to the versionName in build.gradle, which will hopefully allow you to continue working without manual commands until there is a fix:
def buildCode = (int)(((new Date().getTime()/1000) - 1451606400) / 10)
android {
compileSdkVersion 30
buildToolsVersion "30.0.2"
defaultConfig {
...
versionName "0.1.${buildCode}"
...
}
}
lb...@gmail.com
@10 I think I should do it only for debug variant, right?
I don't want users to see weird numbers there...
Possible to use it here:
buildTypes {
release {
shrinkResources true
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
zipAlignEnabled true
}
debug {
versionNameSuffix "-DEBUG"
pseudoLocalesEnabled true
}
}
?
Maybe with versionNameSuffix , as an additional suffix?
Similar to :
https://stackoverflow.com/a/19209759/878126
?
Did you check that it works?
Also, why the weird calculation ? Can't you just use the timestamp instead, directly? Or format by date&time?
I don't want users to see weird numbers there...
Possible to use it here:
buildTypes {
release {
shrinkResources true
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
zipAlignEnabled true
}
debug {
versionNameSuffix "-DEBUG"
pseudoLocalesEnabled true
}
}
?
Maybe with versionNameSuffix , as an additional suffix?
Similar to :
?
Did you check that it works?
Also, why the weird calculation ? Can't you just use the timestamp instead, directly? Or format by date&time?
sj...@gmail.com
The solution I'm using is just a workaround during app development to get work done, it's not meant to be permanent or used in an actual release to the play store.
lb...@gmail.com
@12 I see. It might pollute Crashlytics though, as it will generate a new version name each time you do it. Probably better to somehow disable Crashlytics when having this. Do you know how to do it officially?
lb...@gmail.com
@12 I tried this:
static final def buildTime() {
def df = new SimpleDateFormat("yyyy-MM-dd,HH:mm:ss") // you can change it
df.setTimeZone(TimeZone.getTimeZone("UTC"))
return df.format(new Date())
}
...
buildTypes {
debug {
versionNameSuffix "-DEBUG-" + buildTime()
}
...
It doesn't help with the issue I described. I still need to start the app twice to see new changes. You can try it on the sample I've provided, too.
static final def buildTime() {
def df = new SimpleDateFormat("yyyy-MM-dd,HH:mm:ss") // you can change it
df.setTimeZone(TimeZone.getTimeZone("UTC"))
return df.format(new Date())
}
...
buildTypes {
debug {
versionNameSuffix "-DEBUG-" + buildTime()
}
...
It doesn't help with the issue I described. I still need to start the app twice to see new changes. You can try it on the sample I've provided, too.
lb...@gmail.com
@8 Someone on reddit said that this issue didn't occur on old Android Studio, which makes sense because I don't remember seeing it back then, even though I have played with NotificationListenerService multiple times:
https://www.reddit.com/r/androiddev/comments/kd2rip/android_studio_42_beta_2_available/gfvebhv/?utm_source=reddit&utm_medium=web2x&context=3
la...@gmail.com
That was me. I noticed it first on Android Studio 4.1.0. But I also don't directly use NotificationListenerService, so it's possible that around the same time I started using a 3rd party library that uses it.
lb...@gmail.com
@8 @16 OK I now tried 4.1.0 with the sample I've provided, and indeed the issue doesn't occur there:
https://developer.android.com/studio/archive
I used this one:
https://redirector.gvt1.com/edgedl/android/studio/ide-zips/4.1.0.19/android-studio-ide-201.6858069-windows.zip
So something after 4.1.0 has changed to cause this issue.
See attached.
It does seem like it's restarted for a split of a second with the old version, but right after that it uses the new code you've updated.
I used this one:
So something after 4.1.0 has changed to cause this issue.
See attached.
It does seem like it's restarted for a split of a second with the old version, but right after that it uses the new code you've updated.
lb...@gmail.com
ac...@google.com
There have been a lot similar bug reports and response.
Here are the summary:
1) There is a bug introduced in 4.1.1 that causes applications not restarting despite installing the APK as intended. There is a test / workaround by restarting the application manually. This bug will be fixed in 4.1.2 and it is not found in 4.1.0 nor 4.2+
2) A similar bug (174431980, this one in question) which involves an application that automatically restarts itself if it has certain intent listeners. It would make it appear the application had been killed and relaunched but unfortunately it is not the launch that Studio triggered so the APK might not be fully updated at that time. The workaround is still restarting the application manually. This bug will not be in 4.1.0 and we are still working on a fix.
3) A bug exists in the Canary 2 build (174783087) which would make Run stop pushing changes to API30 devices (even after pressing it again afterward). This has been quickly addressed in Canary 3 build.
Finally 1) and 2) are all timing / race condition related. Changing your build process might or might NOT work. Also if you have having that does not match what was described in the above 3 bugs, we kindly ask you to open a new bug with more detailed description and reproducing steps.
Again, we understand the frustration, we are working hard to address the issues.
Here are the summary:
1) There is a bug introduced in 4.1.1 that causes applications not restarting despite installing the APK as intended. There is a test / workaround by restarting the application manually. This bug will be fixed in 4.1.2 and it is not found in 4.1.0 nor 4.2+
2) A similar bug (174431980, this one in question) which involves an application that automatically restarts itself if it has certain intent listeners. It would make it appear the application had been killed and relaunched but unfortunately it is not the launch that Studio triggered so the APK might not be fully updated at that time. The workaround is still restarting the application manually. This bug will not be in 4.1.0 and we are still working on a fix.
3) A bug exists in the Canary 2 build (174783087) which would make Run stop pushing changes to API30 devices (even after pressing it again afterward). This has been quickly addressed in Canary 3 build.
Finally 1) and 2) are all timing / race condition related. Changing your build process might or might NOT work. Also if you have having that does not match what was described in the above 3 bugs, we kindly ask you to open a new bug with more detailed description and reproducing steps.
Again, we understand the frustration, we are working hard to address the issues.
lb...@gmail.com
@19 Sadly new Android-Studio versions (beta and canary) cause some apps I work on to completely fail to be build, so those are not valid options to try out.
As for the list of known bugs, is one of those the same as I've found today, on the emulator (doesn't occur on real device), as I wrote on @18 ? If so, please write there.
As for the list of known bugs, is one of those the same as I've found today, on the emulator (doesn't occur on real device), as I wrote on @18 ? If so, please write there.
ac...@google.com
We have a fix for this and targetted to Canary 6.
We are currently in progress of cherry picking to 4.2. Unfortunately, it might be too late for 4.1
We are currently in progress of cherry picking to 4.2. Unfortunately, it might be too late for 4.1
ac...@google.com
lb...@gmail.com
@21 Can you think of a workaround for the time being? Maybe there is a way of force-stop the app on all connected devices&emulators before each launch (important because for some reason I failed to do it on more than one) ? Would that help?
ac...@google.com
Yes, if the application you are developing has the tendency of not killing cleaning on Run, the only thing I can think of is create a simple script to kill / restart the application and invoke that after the application is installed.
jp...@gmail.com
It's a major pain for sure.. in my case this happens with my Accessibility Service app so I need to force close the app and restart it on the device after I 'run' from Android Studio.
Unfortunately, force closing and restarting an Accessibility Service app removes the accessibility services permission so I have to manually grant it again -- after every re-start from Android Studio..
There's a few work-arounds you can do to help somewhat.. I've got I've got a bash script that stops the app, starts it again and then uses 'adb shell input touchscreen tap X Y' to simulate screen touches to grant accessibility services permission.. it works but not super easy to setup
adb -s $ADB_DEVICE shell am force-stop $PACKAGE
adb -s $ADB_DEVICE shell am start -n $PACKAGE
lb...@gmail.com
@23 Can you please demonstrate how it's done? Maybe what @24 wrote?
Also, is there a way to overcome what he wrote? I also tried to work on Accessibility Service, and many times I got it revoked.
Is there a command to set an app to have its accessibility enabled?
I know only of "-g" for permissions, and something for notification access. I don't know about using adb to grant accessibility, admin, set as default apps, etc...
Those could be extremely useful in general. Not just in this case as a workaround.
@24 This will work on Windows OS too? I didn't know about "start". This is the opposite of force-stop? This doesn't open some Activity, right? Just changes its state from "stopped" to "started", meaning it's no active and can respond to various OS Intents.
What if instead of this, you try to disable&re-enable ?
Also, is there a way to overcome what he wrote? I also tried to work on Accessibility Service, and many times I got it revoked.
Is there a command to set an app to have its accessibility enabled?
I know only of "-g" for permissions, and something for notification access. I don't know about using adb to grant accessibility, admin, set as default apps, etc...
Those could be extremely useful in general. Not just in this case as a workaround.
@24 This will work on Windows OS too? I didn't know about "start". This is the opposite of force-stop? This doesn't open some Activity, right? Just changes its state from "stopped" to "started", meaning it's no active and can respond to various OS Intents.
What if instead of this, you try to disable&re-enable ?
lb...@gmail.com
@23 Doesn't seem like this is fixed at all on Android S. See here:
https://issuetracker.google.com/issues/186782667
Granted it's not about notification-access anymore, but still happens.
And I still haven't tested the notification-access issue on the original app that has it.
Granted it's not about notification-access anymore, but still happens.
And I still haven't tested the notification-access issue on the original app that has it.
j....@get.systems
We are facing a quite similar problem
currently also no nice solutions, but maybe this helps
https://issuetracker.google.com/issues/187448820
currently also no nice solutions, but maybe this helps
Description
Version of Gradle Plugin:
Version of Gradle:
Version of Java:
OS:
Android Studio 4.1.1
Build #AI-201.8743.12.41.6953283, built on November 5, 2020
Runtime version: 1.8.0_242-release-1644-b01 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0
GC: ParNew, ConcurrentMarkSweep
Memory: 3916M
Cores: 12
Registry: ide.new.welcome.screen.force=true, external.system.auto.import.disabled=true, debugger.watches.in.variables=false
Non-Bundled Plugins: String Manipulation, com.dubreuia, com.thoughtworks.gauge, org.intellij.plugins.markdown, com.intellij.marketplace, org.jetbrains.kotlin
Steps to Reproduce:
1. Have an app that has notification listener (NotificationListenerService) being used.
2. Write something on the log, in the class that extends Application.
3. Choose to install&run the app.
The bug is that many times, the new log won't be shown, and instead you will see the previous state.
See attached.
This was tested on both emulator and Pixel 4, both with Android R.