Status Update
Comments
xo...@google.com <xo...@google.com>
ya...@google.com <ya...@google.com>
mu...@gmail.com <mu...@gmail.com> #2
We are currently using AGP internal task types to flag memory-intensive tasks to enforce a reduced parallelism at execution time. I've raised this separately (with a lot more detail) as a feature request (
wd...@google.com <wd...@google.com> #4
Another use case that we have is to reactively respond to the creation of APKs and AABs. The new AGP APIs allow us to connect out tasks into the artifact pipeline via wiredWith
but the best we can come up with to receive the completed artifact is to wire in toTransform
. This A) does not guarantee that we will receive the final artifact as more transforms may be applied after our task is called, and B) requires us to copy the input property file/dir to our tasks output property file/dir in order to not break the build cache.
The reactive behavior of the above is the complicating factor.
A non-reactive approach could simply depend upon the task name and then look for a hardcoded path in the build directory (which is still sort of gross, since the build output paths are not documented as public API and change from time to time).
Another approach would be to wire a custom task to consume the output of the build via the built artifacts loader feeding an input property. However, this approach cannot be applied reactively. Either the custom task is included in the build and causes the creation of the binary artifact, or it is not included in the build and never gets invoked.
wd...@google.com <wd...@google.com> #6
We didn't provide a task wiring helper for that case as there's only one thing to wire, but I can see how the inconsistency can be misleading
Description
Android Studio Version: Unknown
Emulator Version (Emulator--> Extended Controls--> Emulator Version): 31.2.9-8316981
HAXM / KVM Version: HVF 12.3.0
Android SDK Tools: 26.1.1
Host Operating System: macOS 12.3.1
CPU Manufacturer: Intel CPU
Virtualization is supported
64-bit CPU
RAM: 16384 MB
GPU: GPU #1
Make: 1002
Model: 7340
Device ID: 7340
Build Fingerprint: google/sdk_google_phone_x86/generic_x86:7.0/NYC/4409132:user/release-keys
AVD Details: Name: 4base_makine_rooted
CPU/ABI: x86
Path: /Users/mustafa/.android/avd/4base_makine_rooted.avd
Target: google_apis_playstore [Google Play] (API level 24)
Skin: 1080x1920
SD Card: 512 MB
AvdId: 4base_makine_rooted
PlayStore.enabled: true
avd.ini.displayname: 4base_makine_rooted
avd.ini.encoding: UTF-8
disk.dataPartition.size: 2G
fastboot.chosenSnapshotFile:
fastboot.forceChosenSnapshotBoot: no
fastboot.forceColdBoot: no
fastboot.forceFastBoot: yes
hw.accelerometer: yes
hw.arc: false
hw.audioInput: yes
hw.battery: yes
hw.camera.back: virtualscene
hw.camera.front: emulated
hw.cpu.ncore: 4
hw.dPad: no
hw.device.hash2: MD5:55acbc835978f326788ed66a5cd4c9a7
hw.device.manufacturer: Google
hw.gps: yes
hw.gpu.enabled: yes
hw.gpu.mode: auto
hw.initialOrientation: Portrait
hw.keyboard: yes
hw.lcd.density: 420
hw.lcd.height: 1920
hw.lcd.width: 1080
hw.mainKeys: no
hw.ramSize: 1536
hw.sdCard: yes
hw.sensors.orientation: yes
hw.sensors.proximity: yes
hw.trackBall: no
image.sysdir.1: system-images/android-24/google_apis_playstore/x86/
runtime.network.latency: none
runtime.network.speed: full
showDeviceFrame: no
skin.dynamic: yes
skin.path.backup: _no_skin
tag.display: Google Play
vm.heapSize: 256
Steps to Reproduce Bug:
Expected Behavior:
Observed Behavior: Sometimes, the avd feels sticky touch. It doesnt release touch even if I dont touch trackpad. I m using macbook pro.and tap to click is enabled. I think avd cant handle mis-touches or cant differentiate between navigating and tap on trackpad. As a result, UI behaves oddly sometimes gets unresponsive