We generate an .aab or .apk depending on project settings. By default, only there ,.aab s generated these days, as .apks ar deprecated and no longer accepted by Google Play (as far as I understand).
I know but AAB is generated in only in temporary folder… by design? but APK is generated in BIN folder too , AAB not.
Should I set something ? - Gereate App Bundle i set YES APK is set to NO
Hm, you’re right. something is going wrong there, I just noticed that as well. I will investigate that now.
Workaround: use the .aab from the template folder 
Of course workaround is workaround but my question was about final solution (by design) 
Hmm, weird. the .apk is the .aab. it’s just named wrongly. the GenerateAPK task never hits at all.
Fixed for vNext, but unfortunately not in time for today’s .2809 build. This only happened when not signing the .aab, which is why I probably didn’t;t catch this back when I implemented .aab support last year…
Okay. confirmed, this works on Mac, fails on Windows, with the exact same project, and the exact same platform-specific) Android SDK version.
The odd thing is, when I look at the temporary build output, the files generated by “aapt2 compile” are identical on both systems (aside from hardcoded absolute paths).
Since we have (a) identical input to “aapt2 link”, and (b) the same parameters to “aapt2 link” on both platforms, having one fail and the other not, too me, looks like it can only be a big in aapt2 for Windows :(.
I’m out of ideas what do do at this stage.
One last hope would be if you could (try as I might, I cant make heads or tails of Android Studio and its build process or finds this info, but im not an expert in Android Studio, Gradle and its toolchain) see if — as you say the same project with the same resources compiles/links fine in Android Studio – you could find (a) the intermediate (“.flat”) files it generates and/or (b) the command line parameter sit uses for “aapt2 compile” and more importantly “aapt2 link”, to see of they pass any different parameters.
it’s this set of files we’d be interested in:
Actually, the explanation is in the log, duh:
W: aapt2 link: ignoring unrecognized file.
aapt2 link> Software\EBuild\Obj\28C06114BD7410428C1D3B54A08CA0F5A1979442\Release\Cooper-Android\res-aapt2\drawable-hdpi_icon.png.flat"
W: aapt2 link: ignoring unrecognized file.
aapt2 link> Software\EBuild\Obj\28C06114BD7410428C1D3B54A08CA0F5A1979442\Release\Cooper-Android\res-aapt2\drawable-ldpi_icon.png.flat"
W: aapt2 link: ignoring unrecognized file.
aapt2 link> Software\EBuild\Obj\28C06114BD7410428C1D3B54A08CA0F5A1979442\Release\Cooper-Android\res-aapt2\drawable-mdpi_icon.png.flat"
W: aapt2 link: ignoring unrecognized file.
aapt2 link> Software\EBuild\Obj\28C06114BD7410428C1D3B54A08CA0F5A1979442\Release\Cooper-Android\res-aapt2\drawable-xhdpi_icon.png.flat"
W: aapt2 link: ignoring unrecognized file.
aapt2 link> Software\EBuild\Obj\28C06114BD7410428C1D3B54A08CA0F5A1979442\Release\Cooper-Android\res-aapt2\drawable_icon.png.flat"
W: aapt2 link: ignoring unrecognized file.
aapt2 link> Software\EBuild\Obj\28C06114BD7410428C1D3B54A08CA0F5A1979442\Release\Cooper-Android\res-aapt2\layout_main.xml.flat"
W: aapt2 link: ignoring unrecognized file.
W: aapt2 link: ignoring unrecognized file.
aapt2 link> note: collapsing resource versions for minimum SDK 26.
its ignoring all the files, so of curse it cannot find any of the resources it is looking for.
the question is WHY is it ignoring these files?
It looks like it cannot handle spaces in the filenames 
Indeed. if I build with
--intermediatebasefolder:c:\Obj
to circumvent this, it seems to not fit on this (but shows a different error). This is, to use a technical term, fucked up. :(.
What I get now is equally unhelpful:
aapt2 link> note: including C:\Users\mh\AppData\Local\Android\sdk\platforms\android-33\android.jar.
aapt2 link> note: linking package 'org.me.testapt2' using package ID 7f.
aapt2 link> c:\Obj\28C06114BD7410428C1D3B54A08CA0F5A1979442\Release\Cooper-Android\res-aapt2\drawable-hdpi_icon.png.flat
aapt2 link> c:\Obj\28C06114BD7410428C1D3B54A08CA0F5A1979442\Release\Cooper-Android\res-aapt2\drawable-ldpi_icon.png.flat
aapt2 link> c:\Obj\28C06114BD7410428C1D3B54A08CA0F5A1979442\Release\Cooper-Android\res-aapt2\drawable-mdpi_icon.png.flat
aapt2 link> c:\Obj\28C06114BD7410428C1D3B54A08CA0F5A1979442\Release\Cooper-Android\res-aapt2\drawable-xhdpi_icon.png.flat
aapt2 link> c:\Obj\28C06114BD7410428C1D3B54A08CA0F5A1979442\Release\Cooper-Android\res-aapt2\drawable_icon.png.flat
aapt2 link> c:\Obj\28C06114BD7410428C1D3B54A08CA0F5A1979442\Release\Cooper-Android\res-aapt2\layout_main.xml.flat
E: aapt2 link: failed to open file: The device does not recognize the command. (22).
E: aapt2 link: failed parsing input.
<- Task ProcessAndroidResources failed for org.me.aapt2, Cooper-Android, took 1.3356s (1.335s).
Mateusz, can you check what results you get if you build from the command line with --intermediatebasefolder:c:\Obj?
I think the logging is losing some info (will check why/fix). This is the raw output:
c:\Obj\62C3E248B09F594B404F8AED326C152AC7BA0A10\Release\Cooper-Android\res-aapt2\values_strings.arsc.flat: error: failed to open file: The device does not recognize the command. (22).
error: failed parsing input.
so its the values_strings.arsc.flat file it doesn’t like, for some reason… the file is unreadable just fine for me, manually.
that said, if I drop the file from the txt, it just fails on the one before it. so MAYBE this is just the outout missing a line break. who knows.
Something in this tool is fucked :(.
I tried reducing all the other input filenames to short names too. no cigar
Y:\EBuild\Bin> C:\Users\mh\AppData\Local\Android\sdk\build-tools\33.0.1\aapt2.exe link -v -o c:\Obj\ForAAB.apk --manifest c:\Obj\m.xml --java c:\Obj\java -I C:\obj\a.jar --proto-format --min-sdk-version 26 --target-sdk-version 26 @c:\Obj\62C3E248B09F594B404F8AED326C152AC7BA0A10\Release\Cooper-Android\Aapt2LinkFiles.txt