To monitor the dropbox an application have to either poll the dropbox
and keep track of all entries or observ the /data/system/dropbox
directory. The later requires that the application runs as system-user.
This commit adds that a broadcast intent is sent when something is written
to the dropbox and an application can just listen on this intent and
then reads the entry with help of the DropboxManager class.
The application have to hold the permission android.permission.READ_LOGS
to get the intent.
Change-Id: I1f77f206a243df69f4ed5306078c47f7bf6181ec
* commit 'a2977c383d363e1e88a5b36230b1fa4c312807d2':
[3171580] SurfaceFlinger Bypass mode. (DO NOT MERGE)
[3171580] Add transform field to native buffers. (DO NOT MERGE)
* commit '05813b0eb92cb1bc79607ee402f14ca1e4b43f6d':
[3253328, 3171580] Treat GONE and INVISIBLE views the same when calculating transparent regions
[3171580] Fix two typos related to fixed-size buffers
This is a poor's man precursor to the h/w composer HAL.
Basically we detect when a window is full screen and in
that case we bypass surfaceflinger's composition step, which
yields to much improved performance.
Change-Id: Ie03796ae81a1c951949b771c9323044b980cb347
mFixedSize was never set, this bug was introduced during some "cleanup", in
practice this could cause some issues when a fixed-size buffer was used and
the window was resized.
Layer::drawForSreenShot() had a typo that had no effect.
mFixedSize was used to determine if filtering was needed, which was a bit too
conservative and created a dependency between filtering and "fixed size" states
which should exist.
Now we enable filtering based on the size of the buffer vs. the size of the layer.
Change-Id: I32044e91b0c944c1b137efdceb3f01dfaa78119d
some of these failures are not fatal and even expected in some cases
so they should not emit a dump in the log in those cases.
Change-Id: Idcfa252e3bfa9d74e27fe4ad8f8623aa01aa9c5e
This patch allows users of WindowManagerService.injectKeyEvent() to
set flags on the key event being injected.
In particular this allows long presses (FLAG_LONG_PRESS) to be
injected into the window manager.
The problem is that the code in AudioPolicyManagerBase::checkAndSetVolume() that forces
voice volume to max when setting bluetooth SCO volume is not called if the bluetooth stream
volume did not actually change. So even if we re apply volumes when switching to bluetooth
device, the volume voice volume is not changed and remains what it was when routed to earpiece
What makes things worse on Passion is that stream volumes are limited when connected to bluetooth
and their actual value does not change as soon as they exceed the limit threshold.
Change-Id: Id7c317db45b392a1c20dca2859678e3c64a371ed
There is a bug in the way audio policy manager handles A2DP interface suspend/restore
when SCO is used. This bug is not new but has been triggered by a change in the timing
of the events received by audio policy manager when a call is setup and torn down
introduced by commit 164a8f86c7e48992691368c4895709c3bdb835a4.
The fix consists in grouping the control of A2DP suspended state in a single function
that is called systematically when conditions affecting this state are changed:
- call state change
- device connection/disconnection
- change in forced usage.
Change-Id: I46ee2399ee5547b60511fc6cfd32e2720091b0f8
The worksource reporting gets blocked by the
statetracker lock which can cause system restarts when
done from broadcastreceiver thread
Bug: 3153787
Change-Id: Ie70687e7453a1c3618bac1424562be44762b2c9d
whether a physical sensor needed to be active or not was managed by
a simpe reference counter; unfortunatelly nothing prevented it to
get out of sync if a sensor was disabled more than once.
sensorservice already maintainted a list of all the "clients"
connected to a physical sensor; we now use that list to determine if
a sensor should be enabled. This can never be "out-of-sync" since
this is the only data structure linking a sensor to a user of that
sensor.
also removed the isEnabled() method, which was never used and
implemented wrongly (since it didn't take into account that a sensor
could be disabled for a client but not of another).
Change-Id: I789affb877728ca957e99f7ba749def37c4db1c7
Most accelerometers have 8-bits accuracy so we beed to
reject 48dB in thestop-band, which requires a 4-th order
filter at the cut-off frequency we're using.
Change-Id: Ic00421d38d751641f86b1f3ad7663e6b44a91198
- upadte documentation for rotation vector
- update method dealing with rotation vector to deal with 4 components
- virtual rotation-vector sensor reports all four components
- improve SensorManager documentation layout
Whent he 4-th component of the rotation-vector is present, we can save
a square-root when computing the quaternion or rotation matrix from it.
Change-Id: Ia84d278dd5f0909fab1c5ba050f8df2679e2c7c8
indeed, by construction of the rotation matrix, it is
guaranteed to have a length of 1.
moreover, the normalization code was missing a square-root,
fortunatelly, since the length is 1, this didn't cause any
damage (since sqrt(1) = 1).
Change-Id: I9facd668caaf5bb3bfccb139ab872f2bb2066365
Rework sensorservice to allow "virtual sensors", that is
sensors that report a synthetized value based on real sensors.
the main change to sensorservice is around managing which real
sensor need to be activated and which rate to use.
The logic for all this has been moved into SensorDevice, which
essentially wraps the sensor HAL but adds two features to it:
- it keeps track of which sensors need to be activated
- it keeps track of what rate needs to be used
For this purpose an "identity" is associated with each real sensor
activation, so we can track them.
On start-up we check for gravity, linear-acceleration and
rotation-vector sensors, if they're not present in the HAL, we
synthetize them in sensor-service.
Change-Id: I841db2c1b37ef127ed571efa21732ecc5adf1800
the per-connection state assumed the main sensorservice
lock was held during access. This is however not true while
pre-processing the events just before sending them to clients.
Therefore, there was a small window during which this state
could be modified while being used.
we now have an internal lock that protects this state.
Change-Id: I594680f20f09d6a4f1f38f093a1d3f650dcef1be
We only recorded the last received event (which is needed when a sensor
is activated on a connection) when there was some connection active.
This should fix an issue where sometimes the light sensor doesn't
return an event whent activated.
we also didn't need to hold the main lock while dispatching events
to clients.
Change-Id: I6c6386c040051ce205e3c0516c678e0603fa45e1
If the memory card is not inserted (or removed) from
the phone the shut down process is very long. It
takes almost 24 seconds. For the phone with memory
card the averige is 5-6 seconds
Make sure to send onShutDownComplete even if an SD
card is not mounted and no unmount is done.
Change-Id: I0e79b82e294a971f5e7144cdd3cc16b7ff414b9c
the increased maximum rate is needed for proper gyro integration, current gyro
parts can sample at up to 800Hz
Change-Id: Ide75f6d5bc7a0fdafeb2dafd72db39e7afb9e794
versionCode and mVersionName were added recently but ps.pkg can be null
in some situations. Move them to where it will check before
dereferencing it.
Bug: 3152896
Change-Id: If992a1f29ac7b8f595f847b7743fd2374662bb6e
Two issues:
1. First, due to an inverted conditional in the input dispatcher, we were
reporting touches as long touches and vice-versa to the power manager.
2. Power manager user activity cheek event suppression also suppresses touch
events (but not long touch or up events). As a result, if cheek event
suppression was enabled, touches would not poke the user activity timer.
However due to the above logic inversion, this actually affected long
touches. Net result, if cheek suppression was enabled in the power manager
and you held your thumb on the screen long enough, the phone would
go to sleep!
Cheek event suppression is commonly turned on when making a phone call.
Interestingly, it does not seem to get turned off afterward...
This change fixes the logic inversion and exempts touches from the cheek
suppression. The reason we do the latter is because the old behavior
was actually harmful in other ways too: a touch down would be suppressed
but not a long touch or the touch up. This would cause bizarre behavior
if you touched the screen while it was dimmed. Instead of brightening
immediately, it would brighten either when you lifted your finger or
300ms later, whichever came first.
Bug: 3154895
Change-Id: Ied9ccec6718fbe86506322ff47a4e3eb58f81834
Two bugs were counter acting each other.
- rotation matrices are on the left-hand side of multiplies
- the transform of the overlay is applied before that of the layer
Change-Id: Ia79bd368e9b719235c89ecf244ea263f01ce906a
