Trait Request: Support brightness sensor (not a brightness level for light dimmer) [289504098]

Infeasible

Feature Request

Status Update

No update yet.

Description

ch...@gmail.com

created issue #1

Jun 30, 2023 08:59PM

---DESCRIPTION---
I would like to be able to read the sensor data of a brightness sensor, like on the Eve motion sensor that also measures light brightness. It apparently reports the data through the sensorData structure, but there isn't anything in the list of supported sensors for light sensing.

---EXAMPLE USE CASES---
- When the light level gets to certain brightness, send a command to smart blinds to close, and open again when the brightness drops below a certain level.
- When it gets dark, turn the light on.

---RATIONALE---
Brightness is not a supported sensor type.

Comments

si...@google.com <si...@google.com> Jul 10, 2023 06:15PM

Reassigned to si...@google.com.

si...@google.com <si...@google.com> #2Jul 17, 2023 01:10PM

Status: Won't Fix (Infeasible)

This was partially addressed by

https://android-review.googlesource.com/c/platform/frameworks/support/+/2076902, available now in 1.1 RC02, see

b/230665435

. As compilation on user builds requires a full target reinstall (which is a behavior change), we offer an opt out, which can be used to accomplish this feature request: 1) configure every macrobench to use `CompilationMode.Full()` 1) manually issuing the compile command `cmd package compile -f -m speed <packagename>` for your target 1) pass the instrumentation arg `androidx.benchmark.compilation.enable` = `false` to skip compilation/reinstall for each macrobenchmark. This should still give you the numbers you've been seeing, while avoiding the cost of a large AOT each test. Leaving this bug open, since in general we should be able to do this more automatically for everything without warmup driven profiles. (Somewhat related bug - there have been excess compilations issued specifically for `Compilation.None`, `StartupMode.COLD` benchmarks, which has been fixed, but not shipped publicly yet:

b/231976084

)

ch...@gmail.com <ch...@gmail.com> #3Jul 17, 2023 05:42PM

Note: ideally there's be a way to turn off all install related behavior without having to pass in an arg flag. If I want to handle installation & optimization without benchmark getting in the way, there should be an API for that. Arguably that's what Compilation.None should do, or there should be a Compilation.Interpreted and a Compilation.NoOp.

bo...@gmail.com <bo...@gmail.com> #4Oct 14, 2023 06:32PM

Also, generally clearing profiles doesn't make much sense for Full compilation mode. I understand this makes sense for profile based benchmarks, but not really for full where the output shouldn't vary.

de...@gmail.com <de...@gmail.com> #5Nov 14, 2023 02:21PM

> ideally there's be a way to turn off all install related behavior without having to pass in an arg flag. We can't change APIs in an RC, but we'll consider it for 1.2 > Arguably that's what Compilation.None should do, or there should be a Compilation.Interpreted and a Compilation.NoOp. `None` means "none of my app should be compiled", so at least a reset (if compilation has happened before) should occur. `Compilation.NoOp` or equivalent sounds reasonable. > Also, generally clearing profiles doesn't make much sense for Full compilation mode. I assume so too, I would want to validate that with ART and test it, but either way, we opted for full reinstallation for every test in 1.1 since it's predictable and consistent.

Message last modified on Nov 14, 2023 02:27PM

Issue 289504098