| d86b8fea43ebb6e5c31691b44d8ceb0d8d3c9072 |
|
03-Jun-2017 |
Jeff Sharkey <jsharkey@android.com> |
Annotate @SystemApi with required permissions.
Most @SystemApi methods should be protected with system (or higher)
permissions, so annotate common methods with @RequiresPermission to
make automatic verification easier.
Verification is really only relevant when calling into system
services (where permissions checking can happen on the other side of
a Binder call), so annotate managers with the new @SystemService
annotation, which is now automatically documented.
This is purely a docs change; no logic changes are being made.
Test: make -j32 update-api && make -j32 offline-sdk-docs
Bug: 62263906
Change-Id: I2554227202d84465676aa4ab0dd336b5c45fc651
/frameworks/base/core/java/android/hardware/ConsumerIrManager.java
|
| 49ca529a850e60482ddcc8c0762105b4aa10f35f |
|
10-May-2016 |
Jeff Sharkey <jsharkey@android.com> |
Avoid caching services with missing binders.
When fetching system services early during boot, if the underlying
binder interface hasn't been published yet, we end up caching a
manager class that is broken for the remainder of the process
lifetime, and innocent downstream callers end up using the broken
cached manager.
Fix this by using an explicit exception to quickly abort manager
creation when the underlying binder is missing. The exception is
only used to skip the remainder of the manager creation, and it
doesn't actually crash the process.
Bug: 28634953
Change-Id: I0cb62261e6d6833660704b93a11185aa11a2ac97
/frameworks/base/core/java/android/hardware/ConsumerIrManager.java
|
| c53962d4ede82a03b62f0c8bb86bd0da090a15eb |
|
02-Mar-2016 |
Jeff Sharkey <jsharkey@android.com> |
When system server goes down, crash apps more.
Apps making calls into the system server may end up persisting
internal state or making security decisions based on the perceived
success or failure of a call, or the default values returned.
The reality is that if the system process just died, init will be
along shortly to kill all running apps, so we should have no problem
rethrowing the RemoteException as a RuntimeException.
Bug: 27364859
Change-Id: Ife0bcb079636c88d54c44d17eb580409fd79028b
/frameworks/base/core/java/android/hardware/ConsumerIrManager.java
|
| 991c1005f3060fbf76f7f718317b367189ec51db |
|
24-Jan-2014 |
Martin Storsjo <martin@martin.st> |
Fix a typo in a javadoc comment
Change-Id: I7f3b5d3bf6ee2f966636a588c14908ee632a531a
/frameworks/base/core/java/android/hardware/ConsumerIrManager.java
|
| 1e679441af2e93841d5dbcddbb28756898108a9f |
|
11-Sep-2013 |
Alex Ray <aray@google.com> |
consumer ir: clarify @link in documentation
Change-Id: Ifebd0b550f5d9860697539646596a0b1cc782949
/frameworks/base/core/java/android/hardware/ConsumerIrManager.java
|
| 51e95df8f24e9ea30775686b9e324b9a671213dc |
|
26-Jun-2013 |
Erik Gilling <konkers@android.com> |
Add consumer IR framework
Change-Id: I786c00db0cce61ef75e4edc24e90f2cdcba6dbfb
/frameworks/base/core/java/android/hardware/ConsumerIrManager.java
|