android-stem icon indicating copy to clipboard operation
android-stem copied to clipboard

Ocasional unresolved placeholders

Open ankandrew opened this issue 1 year ago • 10 comments

@LikeTheSalad I'm opening this issue to avoid spamming the other closed one. Following this conversation, seems like sometimes placeholders aren't resolved. To be sure placeholders are resolved I have to do Build > Clean Project.

I've uploaded a sample to reproduce, which I'm seeing the exact same problem: https://github.com/ankandrew/AndroidStemIssue

BTW: Thanks for this awesome library!

ankandrew avatar Jul 20 '22 22:07 ankandrew

Hi @ankandrew! yeah I agree it's better to have its own ticket 👍

Many thanks for your sample project, it helps a lot to find the root cause issues! Just one more thing though, please can you let me know what version of Android Studio are you using (I want to make sure if it's a Gradle or an Android Studio related issue), and also, do you have a rough idea of what steps are likely to reproduce the issue? For example, if you hit the "play" button and install your app twice, the second time has the issue? Or, maybe if you build your app once, then change some strings, then build it again, the recently changed strings aren't resolved? Something like that would help a lot, even if it isn't always reproducible, at least those steps would provide valuable hints.

LikeTheSalad avatar Jul 21 '22 05:07 LikeTheSalad

Sure @LikeTheSalad, sorry for the late response.

Android Studio & Related information

Android Studio Chipmunk | 2021.2.1 Patch 1
Build #AI-212.5712.43.2112.8609683, built on May 18, 2022
Runtime version: 11.0.12+7-b1504.28-7817840 amd64
VM: OpenJDK 64-Bit Server VM by Oracle Corporation
Windows 10 10.0
GC: G1 Young Generation, G1 Old Generation
Memory: 1280M
Cores: 20
Registry: external.system.auto.import.disabled=true, debugger.watches.in.variables=false, ide.images.show.chessboard=true
Non-Bundled Plugins: org.jetbrains.kotlin (212-1.6.21-release-334-AS5457.46)

Steps to Reproduce Issue

  1. I start from uninstalled app on device
  2. Building and Installing the app shows the correct results (placeholders being resolved)
  3. Hit Run app (green triangle) on Android Studio
  4. Placeholders aren't resolved

ankandrew avatar Jul 22 '22 21:07 ankandrew

Got it, many thanks for all the details!

LikeTheSalad avatar Jul 27 '22 11:07 LikeTheSalad

Hi @ankandrew, I tried following the steps you mentioned but I couldn't repro the issue. I ran the app multiple times, without changing the placeholders, then after changing them and in none of those cases I got an unresolved placeholder. The only thing that comes to my mind that could be happening is if the resolving task doesn't run in some cases, but I couldn't find a way to reproduce it. If you ever happen to find the issue again, the only thing I'd recommend would be to run the android assembling task in a terminal using the --info flag (for example: ./gradlew app:assembleDebug --info) and paste the console output here so that we can see the whole set of tasks that run in your project and we could spot if Stem's tasks aren't running for some reason.

LikeTheSalad avatar Aug 15 '22 15:08 LikeTheSalad

@LikeTheSalad Thanks for giving it a look!

Tasks executed when I see the error
> Configure project :app
AGPBI: {"kind":"warning","text":"Using flatDir should be avoided because it doesn't support any meta-data formats.","sources":[{}]}

> Task :app:preBuild UP-TO-DATE
> Task :app:preDebugBuild UP-TO-DATE
> Task :app:mergeDebugNativeDebugMetadata NO-SOURCE
> Task :app:compileDebugAidl NO-SOURCE
> Task :app:compileDebugRenderscript NO-SOURCE
> Task :app:generateDebugBuildConfig UP-TO-DATE
> Task :app:javaPreCompileDebug UP-TO-DATE
> Task :app:checkDebugAarMetadata UP-TO-DATE
> Task :app:generateDebugResValues UP-TO-DATE
> Task :app:generateDebugResources UP-TO-DATE
> Task :app:commonStringDebugResourceLocator
> Task :app:templateStringDebugResourceLocator
> Task :app:templatesDebugIdentifier
> Task :app:gatherDebugStringTemplates
> Task :app:resolveDebugPlaceholders
> Task :app:createDebugCompatibleScreenManifests UP-TO-DATE
> Task :app:extractDeepLinksDebug UP-TO-DATE
> Task :app:processDebugMainManifest UP-TO-DATE
> Task :app:processDebugManifest UP-TO-DATE
> Task :app:processDebugManifestForPackage UP-TO-DATE
> Task :app:mergeDebugShaders UP-TO-DATE
> Task :app:compileDebugShaders NO-SOURCE
> Task :app:generateDebugAssets UP-TO-DATE
> Task :app:mergeDebugAssets UP-TO-DATE
> Task :app:compressDebugAssets UP-TO-DATE
> Task :app:processDebugJavaRes NO-SOURCE
> Task :app:mergeDebugJavaResource UP-TO-DATE
> Task :app:checkDebugDuplicateClasses UP-TO-DATE
> Task :app:desugarDebugFileDependencies UP-TO-DATE
> Task :app:mergeExtDexDebug UP-TO-DATE
> Task :app:mergeLibDexDebug UP-TO-DATE
> Task :app:configureCMakeDebug[arm64-v8a]
> Task :app:buildCMakeDebug[arm64-v8a]
> Task :app:externalNativeBuildDebug
> Task :app:mergeDebugJniLibFolders UP-TO-DATE
> Task :app:mergeDebugNativeLibs UP-TO-DATE
> Task :app:stripDebugDebugSymbols UP-TO-DATE
> Task :app:validateSigningDebug UP-TO-DATE
> Task :app:writeDebugAppMetadata UP-TO-DATE
> Task :app:writeDebugSigningConfigVersions UP-TO-DATE
> Task :app:mergeDebugResources
> Task :app:mapDebugSourceSetPaths UP-TO-DATE
> Task :app:processDebugResources
> Task :app:compileDebugJavaWithJavac UP-TO-DATE
> Task :app:dexBuilderDebug UP-TO-DATE
> Task :app:mergeProjectDexDebug UP-TO-DATE
> Task :app:packageDebug
> Task :app:createDebugApkListingFileRedirect UP-TO-DATE
> Task :app:assembleDebug

BUILD SUCCESSFUL in 3s
39 actionable tasks: 11 executed, 28 up-to-date

ankandrew avatar Aug 16 '22 00:08 ankandrew

Got it, so it seems like the resolving task has run there > Task :app:resolveDebugPlaceholders there's no "UP-TO-DATE" next to it so it definitely ran. Now, all is left is checking if the generated XML file has its strings properly resolved app/build/generated/resolved/debug/values/resolved.xml From that on, if the resolved.xml file has its values correctly, and yet the running app doesn't, then at least I'd know that the internal works of Stem are fine, but it might be the merging of those resources what's failing, which would be strange but at least a lot of other stuff would be discarded.

There's one thing that seems a little strange to me in this output, and it's that there are several other tasks in between the resolving task and the merging task > Task :app:mergeDebugResources. Usually they run one right after the other (the merging running last) so for a moment I was thinking that maybe some of the in-between tasks might be messing up something, but if you also can reproduce this same issue using the sample project you sent me, then the in-between tasks are not the issue because I don't see them when running the sample project.

So for now, if you can check the generated XML files to see if they're fine, that'll help a lot.

LikeTheSalad avatar Aug 16 '22 06:08 LikeTheSalad

@LikeTheSalad Yep, the output from my last comment isn't from the sample project but from the real one. Anyway I'm experimenting the same in both.

I actually don't see any file in this path app/build/generated/resolved/debug/values/resolved.xml when I get unresolved references. Interesting that when I do the Clean Project trick I'm able to see these files.

Files structure (Working)

├───ap_generated_sources
│   └───debug
│       └───out
├───res
│   ├───pngs
│   │   └───debug
│   │       └───drawable-anydpi-v24
│   └───resValues
│       └───debug
├───resolved
│   └───debug
│       ├───values
│       └───values-es

Files structure (Not Working)

├───ap_generated_sources
│   └───debug
│       └───out
├───res
│   ├───pngs
│   │   └───debug
│   │       └───drawable-anydpi-v24
│   └───resValues
│       └───debug

So the problem is that these files aren't even getting created.

ankandrew avatar Aug 17 '22 02:08 ankandrew

This is key to know where to go next, so it could be that, either Stem can't create its output folders sometimes, or, there might be something external clearing this part of the build directory. Interestingly enough, the "build/generated/res" dir seems to be left untouched, probably because it's Android's official dir to place their generated resources, so it makes sense that, if it's the case that some other plugin is clearing build files, then most likely they added validations to avoid touching official Android dirs. So I'm thinking of changing Stem's output dir to be inside that other one, and maybe that'd avoid strange issues, but that's just a guess. It'd be a pretty significant change (easy to apply, but still significant), so I might provide some snapshot builds first to test it out if you don't mind trying them.

LikeTheSalad avatar Aug 17 '22 06:08 LikeTheSalad

@LikeTheSalad Yep, I'm available to test any snapshot build and check if fixes this problem. What's weird with this issue:

  • Why after Cleaning Project the path/folder is created properly
  • You can't reproduce. Might be an OS problem?

ankandrew avatar Aug 17 '22 22:08 ankandrew

Awesome thanks! Yeah I thought about that, though I don't have a Windows machine to test it on my side with the same OS. But I'll have a look at possible Gradle issues with Windows to check that possibility, the way Stem creates its output dir right now is by delegating that to Gradle's internal tools, so if there's an issue with that, I should be able to find something about it on the internet. And if not, then I can print some logs to check what's going on in that part, if the dir gets created or not.

LikeTheSalad avatar Aug 18 '22 07:08 LikeTheSalad

Hi @ankandrew - apologies for the delay, it's been a crazy week. Ok so I just created a snapshot build version 2.2.2-SNAPSHOT - It's in Maven central's snapshot repo so you'll have to add it to your buildscript.repositories block:

repositories {
    maven {
         url "https://oss.sonatype.org/content/repositories/snapshots"
    }
}

After adding Stem's version 2.2.2-SNAPSHOT to your project and running it, you should see some stem logs in the console output, they all start with [STEM] - Please send me those logs for when it works, and for when it doesn't!

Please let me know if any questions.

LikeTheSalad avatar Aug 27 '22 15:08 LikeTheSalad

Thanks @LikeTheSalad for providing the snapshot! So what I'm observing is that I don't see [STEM] logs in the build when it's not working compared when it is.

Logs

Working (Placeholders are resolved)

Executing tasks: [:app:assembleDebug] in project C:\Users\Anka\AndroidStudioProjects\AndroidStemIssue

> Task :app:preBuild UP-TO-DATE
> Task :app:preDebugBuild UP-TO-DATE
> Task :app:mergeDebugNativeDebugMetadata NO-SOURCE
> Task :app:compileDebugAidl NO-SOURCE
> Task :app:compileDebugRenderscript NO-SOURCE
> Task :app:generateDebugBuildConfig UP-TO-DATE
> Task :app:javaPreCompileDebug UP-TO-DATE
> Task :app:checkDebugAarMetadata UP-TO-DATE
> Task :app:generateDebugResValues UP-TO-DATE
> Task :app:generateDebugResources UP-TO-DATE
> Task :app:commonStringDebugResourceLocator
> Task :app:templateStringDebugResourceLocator
> Task :app:templatesDebugIdentifier
> Task :app:gatherDebugStringTemplates

> Task :app:resolveDebugPlaceholders
[STEM] - Starting to resolve placeholders
[STEM] - Output dir amount of files: 0
[STEM] - Output dir amount of files2: 0
[STEM] - Templates amount of files: 2
[STEM] - Resolving files for language: es into the dir: C:\Users\Anka\AndroidStudioProjects\AndroidStemIssue\app\build\generated\resolved\debug which exists = true
[STEM] - Saved resolved strings into file: C:\Users\Anka\AndroidStudioProjects\AndroidStemIssue\app\build\generated\resolved\debug\values-es\resolved.xml which exists = true
[STEM] - Resolving files for language: main into the dir: C:\Users\Anka\AndroidStudioProjects\AndroidStemIssue\app\build\generated\resolved\debug which exists = true
[STEM] - Saved resolved strings into file: C:\Users\Anka\AndroidStudioProjects\AndroidStemIssue\app\build\generated\resolved\debug\values\resolved.xml which exists = true

> Task :app:packageDebugResources
> Task :app:createDebugCompatibleScreenManifests UP-TO-DATE
> Task :app:extractDeepLinksDebug UP-TO-DATE
> Task :app:processDebugMainManifest UP-TO-DATE
> Task :app:processDebugManifest UP-TO-DATE
> Task :app:processDebugManifestForPackage UP-TO-DATE
> Task :app:mergeDebugShaders UP-TO-DATE
> Task :app:compileDebugShaders NO-SOURCE
> Task :app:generateDebugAssets UP-TO-DATE
> Task :app:parseDebugLocalResources
> Task :app:mergeDebugAssets UP-TO-DATE
> Task :app:compressDebugAssets UP-TO-DATE
> Task :app:processDebugJavaRes NO-SOURCE
> Task :app:mergeDebugJavaResource UP-TO-DATE
> Task :app:checkDebugDuplicateClasses UP-TO-DATE
> Task :app:desugarDebugFileDependencies UP-TO-DATE
> Task :app:mergeExtDexDebug UP-TO-DATE
> Task :app:mergeLibDexDebug UP-TO-DATE
> Task :app:mergeDebugJniLibFolders UP-TO-DATE
> Task :app:mergeDebugNativeLibs NO-SOURCE
> Task :app:stripDebugDebugSymbols NO-SOURCE
> Task :app:validateSigningDebug UP-TO-DATE
> Task :app:writeDebugAppMetadata UP-TO-DATE
> Task :app:writeDebugSigningConfigVersions UP-TO-DATE
> Task :app:mergeDebugResources
> Task :app:mapDebugSourceSetPaths UP-TO-DATE
> Task :app:processDebugResources
> Task :app:compileDebugJavaWithJavac UP-TO-DATE
> Task :app:dexBuilderDebug UP-TO-DATE
> Task :app:mergeProjectDexDebug UP-TO-DATE
> Task :app:packageDebug
> Task :app:createDebugApkListingFileRedirect UP-TO-DATE
> Task :app:assembleDebug

BUILD SUCCESSFUL in 1s
36 actionable tasks: 10 executed, 26 up-to-date

NOT Working (Placeholders are NOT resolved)

> Task :app:preBuild UP-TO-DATE
> Task :app:preDebugBuild UP-TO-DATE
> Task :app:mergeDebugNativeDebugMetadata NO-SOURCE
> Task :app:compileDebugAidl NO-SOURCE
> Task :app:compileDebugRenderscript NO-SOURCE
> Task :app:generateDebugBuildConfig UP-TO-DATE
> Task :app:javaPreCompileDebug UP-TO-DATE
> Task :app:checkDebugAarMetadata UP-TO-DATE
> Task :app:generateDebugResValues UP-TO-DATE
> Task :app:generateDebugResources UP-TO-DATE
> Task :app:commonStringDebugResourceLocator
> Task :app:templateStringDebugResourceLocator
> Task :app:templatesDebugIdentifier
> Task :app:gatherDebugStringTemplates
> Task :app:resolveDebugPlaceholders
> Task :app:packageDebugResources
> Task :app:createDebugCompatibleScreenManifests UP-TO-DATE
> Task :app:extractDeepLinksDebug UP-TO-DATE
> Task :app:processDebugMainManifest UP-TO-DATE
> Task :app:processDebugManifest UP-TO-DATE
> Task :app:processDebugManifestForPackage UP-TO-DATE
> Task :app:mergeDebugShaders UP-TO-DATE
> Task :app:compileDebugShaders NO-SOURCE
> Task :app:generateDebugAssets UP-TO-DATE
> Task :app:mergeDebugAssets UP-TO-DATE
> Task :app:compressDebugAssets UP-TO-DATE
> Task :app:processDebugJavaRes NO-SOURCE
> Task :app:parseDebugLocalResources
> Task :app:mergeDebugJavaResource UP-TO-DATE
> Task :app:checkDebugDuplicateClasses UP-TO-DATE
> Task :app:desugarDebugFileDependencies UP-TO-DATE
> Task :app:mergeExtDexDebug UP-TO-DATE
> Task :app:mergeLibDexDebug UP-TO-DATE
> Task :app:mergeDebugJniLibFolders UP-TO-DATE
> Task :app:mergeDebugNativeLibs NO-SOURCE
> Task :app:stripDebugDebugSymbols NO-SOURCE
> Task :app:validateSigningDebug UP-TO-DATE
> Task :app:writeDebugAppMetadata UP-TO-DATE
> Task :app:writeDebugSigningConfigVersions UP-TO-DATE
> Task :app:mergeDebugResources
> Task :app:mapDebugSourceSetPaths UP-TO-DATE
> Task :app:processDebugResources
> Task :app:compileDebugJavaWithJavac UP-TO-DATE
> Task :app:dexBuilderDebug UP-TO-DATE
> Task :app:mergeProjectDexDebug UP-TO-DATE
> Task :app:packageDebug
> Task :app:createDebugApkListingFileRedirect UP-TO-DATE
> Task :app:assembleDebug

BUILD SUCCESSFUL in 2s
36 actionable tasks: 10 executed, 26 up-to-date

How I reproduce

Every 2 builds, fails on the seconds one. For example I hit run 'app' (builds) I see correctly the placeholders being resolved, do again and it doesn't. The third time works, but not the fourth and so on. I updated my sample-to-reproduce repo AndroidStemIssue.

ankandrew avatar Aug 29 '22 01:08 ankandrew

Got it, thanks! Ok so it seems like nothing is deleting this dir, but rather it's just not being run (or it is, but it's just cleaning up its output, usually this happens when the inputs are empty). We need to know why, usually that kind of information is provided by Gradle when the --info flag is passed. So please if you can run it when not working like so: ./gradlew assembleDebug --info. That way there should be a verbose output explaining why the task app:resolveDebugPlaceholders didn't run. And it'd be also useful to see what the others (prior to the resolving one) are doing.

LikeTheSalad avatar Aug 29 '22 06:08 LikeTheSalad

@LikeTheSalad I think this will held some interesting results. I attach you below the full build log (all tasks included)

Unresolved placeholders

build_log_not_working.txt

Resolved placeholders

build_log_working.txt

ankandrew avatar Aug 29 '22 21:08 ankandrew

Oh my God, I think I know what happens 🤦 - According to the output, Stem is including its output (resolved.xml files) as its inputs. That's not good, and it shouldn't be happening because I added filters for it, the thing is that, those filters include file paths that I defined with / as separators... And for Windows it'd be \ instead, so maybe that's why the filter isn't working on Windows X_x.

I've just re-uploaded 2.2.2-SNAPSHOT with a fix for it, please can you try again? (it's the same version so you should just try again and Gradle should fetch the changes) I changed a [STEM] log to read "Starting to resolve placeholders on snapshot released on 30/08/2022" So that you can verify that you're using the artifact I just released 👍

Please let me know how it goes!

LikeTheSalad avatar Aug 30 '22 07:08 LikeTheSalad

Yep, that did it. No longer I can reproduce this error with the 2.2.2-SNAPSHOT :). I attach anyways the build log of running ./gradlew assembleDebug --info below.

build_log_after_fix.txt

ankandrew avatar Aug 31 '22 02:08 ankandrew

Awesome! I've just released version 2.2.2 with this fix. Many thanks for your help in solving this issue, I couldn't even notice it by myself since I'm not on Windows, so all your support was key to sort this out!

I'm going to close this issue now, feel free to reopen it if needed.

Thanks again.

LikeTheSalad avatar Aug 31 '22 07:08 LikeTheSalad

Thanks a lot for the patience and fixing the issue! Glad that now works :)

ankandrew avatar Aug 31 '22 19:08 ankandrew