History log of /frameworks/base/core/java/android/os/SystemVibrator.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
95d785346b4dae808a2d8f77356175e55a572d96 11-Sep-2013 Dianne Hackborn <hackbod@google.com> Fix issue #10688644: Java crash in com.android.phone:

java.lang.SecurityException: Operation not allowed

There was a situation I wasn't taking into account -- components
declared by the system has a special ability to run in the processes
of other uids. This means that if that code loaded into another
process tries to do anything needing an app op verification, it will
fail, because it will say it is calling as the system package name but
it is not actually coming from the system uid.

To fix this, we add a new Context.getOpPackageName() to go along-side
getBasePackageName(). This is a special call for use by all app ops
verification, which will be initialized with either the base package
name, the actual package name, or now the default package name of the
process if we are creating a context for system code being loaded into
a non-system process.

I had to update all of the code doing app ops checks to switch to this
method to get the calling package name.

Also improve the security exception throw to have a more descriptive
error message.

Change-Id: Ic04f77b3938585b02fccabbc12d2f0dc62b9ef25
/frameworks/base/core/java/android/os/SystemVibrator.java
f265ea9d8307282ff1da3915978625a94fc2859e 01-Feb-2013 Dianne Hackborn <hackbod@google.com> App ops: vibration, neighboring cells, dialing, etc.

Improve handling of vibration op, so that apps are
better blamed (there is now a hidden vibrator API that
supplies the app to blame, and the system now uses this
when vibrating on behalf of an app).

Add operation for retrieving neighboring cell information.

Add a new op for calling a phone number. This required
plumbing information about the launching package name through
the activity manager, which required changing the internal
startActivity class, which required hitting a ton of code that
uses those internal APIs.

Change-Id: I3f8015634fdb296558f07fe654fb8d53e5c94d07
/frameworks/base/core/java/android/os/SystemVibrator.java
d8e1dbb6bc1fbaf4f2e38c3ba92ced94270deaac 18-Jan-2013 Dianne Hackborn <hackbod@google.com> Rework ParceledListSlice to be much easier to use.

Take advantage of this to return better information about
packages filtered by permissions -- include the permissions
they have in the requested array.

Also fix issue #8026793 (Contact picture shows default pic
while searching for a contact in qsb) by using the base
package name of the Context when reporting the app name
of an operation. Otherwise you could make a resource-only
context for another application and do calls through that
and get reported as the wrong app.

Change-Id: I5e0488bf773acea5a3d22f245641828e1a106fb8
/frameworks/base/core/java/android/os/SystemVibrator.java
a06de0f29b58df9246779cc4bfd8f06f7205ddb6 12-Dec-2012 Dianne Hackborn <hackbod@google.com> New "app ops" service.

Initial implementation, tracking use of the vibrator, GPS,
and location reports.

Also includes an update to battery stats to also keep track of
vibrator usage (since I had to be in the vibrator code anyway
to instrument it).

The service itself is only half-done. Currently no API to
retrieve the data (which once there will allow us to show you
which apps are currently causing the GPS to run and who has
recently accessed your location), it doesn't persist its data
like it should, and no way to tell it to reject app requests
for various operations.

But hey, it's a start!

Change-Id: I05b8d76cc4a4f7f37bc758c1701f51f9e0550e15
/frameworks/base/core/java/android/os/SystemVibrator.java
c2346134bb519a54d50655cbef940fc3fdec60a9 13-Apr-2012 Jeff Brown <jeffbrown@google.com> Extract Vibrator implementation from interface.

Moved the core logic of Vibrator into SystemVibrator, potentially
allowing for the creation of other Vibrator subclasses.

Fixed several places where we were creating new Vibrator
instances unnecessarily instead of getting it from the Context.

It is safe to make Vibrator abstract because its constructor
was hidden from the SDK so it was not possible to subclass it.

Bug: 6334179
Change-Id: I18ece6544c26a7efb2d5099f8346a10aef8a5e18
/frameworks/base/core/java/android/os/SystemVibrator.java