Status Update
No update yet.
Comments
lb...@gmail.com
Oh, worth noting that rule from that sample project works fine if Lint run via console.
lb...@gmail.com
Hi all! I face the same issue when using AS 4.2.2. I've tried on macOS and on Windows, but I can't see highlighting. I don't see highlighting neither opening the project nor after running :app:lint command (but I can see errors in the console).
su...@google.com
lb...@gmail.com
+1
lb...@gmail.com
lb...@gmail.com
lb...@gmail.com
Something needs to trigger building the lint artifact, but as a workaround, here's what I did which made it work:
- Opened the sample project in Flamingo, and used the upgrade assistant to update it to 8.0.0-alpha10 (the same version of Flamingo I was using)
- Opened the test file ("Test) -- there's no lint warning yet
- Opened the terminal window inside the IDE (Help > Find Action > terminal)
- Ran "./gradlew lint"
That triggered a build, and once it finished, the IDE also updated to start showing the lint warning without me having to do anything else (see screenshot).
an...@gmail.com
However for some reason, after changing over to 8.0.0-alpha10 it started working in Flamingo Canary 10.
lb...@gmail.com
lb...@gmail.com
Something needs to trigger building the lint artifact
Here are 2 options that come to mind:
- Trigger building the lint.jar file during sync.
- Add a dependency from common build commands (e.g.,
assembleDebug) to the task that creates the lint.jar file (so that at least the lint.jar file would exist more often than it does now).
Chris, do you have more context to suggest the best way forward? Both of these seem like they might cause performance regressions, and I'm not sure that option 1 is even allowed.
ra...@google.com
ra...@google.com
Yes, I agree we need a way to do this, but also that those options both have downsides as Scott identifies.
I wonder if we need to have a 'build custom lint checks' action in the IDE, maybe with some level of prompting to trigger it in Studio if we detect that the user has configured their project to have custom lint rules but they're not built yet.
lb...@gmail.com
What if we had a lint{} block option which basically says to aggressively build local lint checks? And then I realized that maybe the presence of lintChecks in the dependencies block is that option?
Description
- Steps to reproduce the problem (including sample code if appropriate).
1. Try to find all possible cases of which wallpaper/s are set, using the functions of WallpaperManager:
val isLiveWallpaper = wallpaperManager.c!= null
val systemWallpaperId = wallpaperManager.getWallpaperId(WallpaperManager.FLAG_SYSTEM)
val lockWallpaperId = wallpaperManager.getWallpaperId(WallpaperManager.FLAG_LOCK)
Log.d("AppLog", "isLiveWallpaper:$isLiveWallpaper system?${systemWallpaperId >= 0} lock?${
lockWallpaperId >= 0
}")
Meaning the goal is to find if we have an image wallpaper set for lock and/system, and whether we have a live wallpaper set.
2. You can see that for the case of simple images, one for system and one for lock, you get isLiveWallpaper=false, and the rest aren't negative.
3. Now set a live wallpaper, and check again.
- What happened.
The bug is that you get the same result as before, unless you have QUERY_ALL_PACKAGES.
You can't get information about the current live wallpaper, and if you try to use the functions to import the wallpaper images (getDrawable,getWallpaperFile ), you will actually be reaching the previous state, of when you've set 2 images.
- What you think the correct behavior should be.
It should return us basic information about the current live wallpaper, and if needed, hide the package name of the app.
As I wrote, another bug is that you get the previous images that were set, too, instead of the most updated state, of image and live wallpaper.
The documentation doesn't even say that we should have such a permission for this to work:
We should have at least a boolean telling us if there is a live wallpaper set for lock/home screens, just as we have for images.
Also, it's very misleading to tell that images are available for both, even though the user has set a live wallpaper and not an image.
- Is this a security related issue? Yes/No
No