Status Update
Comments
au...@google.com <au...@google.com> #2
Fix (pending) is I2c2dc7b600603ee430fd0d91b23d52ea8aa29ca9.
sp...@google.com <sp...@google.com> #3
je...@google.com <je...@google.com> #4
#sdkmanager --package_file=${PATH_WORKSPACE}/packages
while read p; do echo "y" | sdkmanager "${p}"; done <${PATH_WORKSPACE}/packages
sp...@google.com <sp...@google.com> #5
sp...@google.com <sp...@google.com> #6
da...@google.com <da...@google.com> #7
sp...@google.com <sp...@google.com> #8
da...@google.com <da...@google.com> #9
em...@google.com <em...@google.com> #10
```
(15:58:11) C02W513SHTD8:files aso$ /opt/android-sdk-macosx/tools/bin/sdkmanager --version
26.1.1
(15:58:17) C02W513SHTD8:files aso$ /opt/android-sdk-macosx/tools/bin/sdkmanager --install --package_file=package_file
Warning: Unknown argument --package_file=package_file
```
sp...@google.com <sp...@google.com> #11
sp...@google.com <sp...@google.com> #12
sp...@google.com <sp...@google.com> #13
au...@google.com <au...@google.com> #14
sp...@google.com <sp...@google.com> #15
em...@google.com <em...@google.com> #16
Has anyone re-tried it?
We switched back to RUN sdkmanager --package_file=$ANDROID_HOME/packages.txt
in our Dockerfile back in March of 2021.
au...@google.com <au...@google.com> #17
For what it's worth, I did a quick test with the latest CLI: 11076708 (
./sdkmanager --sdk_root="../sdk" --package_file=deps.txt
Deps.txt:
platform-tools
extras;google;instantapps
build-tools;35.0.0-rc3
So perhaps this is now resolved? I haven't tried it with more packages
sp...@google.com <sp...@google.com> #18
Before looking into this, it would be nice to create a simple test app that demonstrates the problem.
Would it make sense to go ahead and merge
em...@google.com <em...@google.com> #19
The test app from
A more complex test app would have:
- An 'app' module with native code.
- A 'lib' module with native code.
- An app-to-lib
androidTestImplementation
dependency.
And, test cases:
- Run instrumented test of 'app' module, verify:
a. hit native breakpoints in 'app' module
b. hit native breakpoints in 'lib' module - Run instrumented test of 'lib' module, verify:
a. hit native breakpoints in 'lib' module.
Current Status (studio-main, around Hedgehog canary 3):
- The following tests pass: 1(a), 2(a)
- The following tests fail: 1(b)
I prepared ag/23066587, which also makes 1(b) pass. I need to add some integration tests to that change.
spollom@ Feel free to submit your ag/21235820.
sp...@google.com <sp...@google.com> #20
Thanks, Emre!
sp...@google.com <sp...@google.com> #21
spollom@ Feel free to submit your ag/21235820.
Just merged it.
em...@google.com <em...@google.com> #22
I just merged ag/23066587, which should fix the debugger for 1(b) in comment19. Adding integration tests is still WIP, it's done but is flaky due to some unexpected resource leaks.
au...@google.com <au...@google.com> #23
Is it too risky to cp this to 8.1.0?
sp...@google.com <sp...@google.com> #24
hs...@gmail.com <hs...@gmail.com> #26
Could someone share in which version of AGP this issue is (planned to be) fixed?
em...@google.com <em...@google.com> #27
The fix is in 8.2.0 and newer. It's currently in beta, but a stable version will be available soon.
Description
Currently,
AndroidTest.packaging.jniLibs.keepDebugSymbols
has no effect on native library stripping in androidTest APKs... native libraries are packaged unstripped regardless.Proposal: For androidTest APKs, AGP should continue to package unstripped native libraries by default, but ifAndroidTest.packaging.jniLibs.keepDebugSymbols
contains any patterns, only the matching native libraries should be packaged unstripped.See Issue 228627720 for context.
Edit: See #3 for new proposal.