# By Roman Mazur
# Via Android Git Automerger (2) and others
* commit 'f2873456dd2c7f93b63d4bd6bc0c742dfd153b62':
Clear loaders array after they are destroyed.
# By Sungmin Choi
# Via Android Git Automerger (2) and others
* commit 'a3f82b1b2dca74e7f287912cd85069dd74b8bf4d':
add reply.writeNoException() for quick response
# By Roman Mazur
# Via Gerrit Code Review (1) and Roman Mazur (1)
* commit '0d47af1131c4d4f9f29dad790d919d8599e3a3cc':
Clear loaders array after they are destroyed.
Also fix a build.
And fix a bug that I think was introduced in the multi-user work
that removed the permission check for writing to settings...!
Change-Id: I5945682faa789ffc78fd3546c0df7d03693f106d
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
This is an important step toward being able to reason about
Notifications after they've been built and sent to the
NoMan; right now most of that information is baked into the
contentView and bigContentView before being thrown away.
TODO: more stuff. Right now we're just grabbing the basics:
title, text, subtext, and small icon res ID.
Change-Id: Ief725bb38d160d340b0e3c46f83bc02d5a283d13
Also add new ops for calendar and wi-fi scans, finish
implementing rejection of content provider calls, fix
issues with rejecting location calls, fix bug in the
new pm call to retrieve apps with permissions.
Change-Id: I29d9f8600bfbbf6561abf6d491907e2bbf6af417
# Via Android Git Automerger (3) and others
* commit 'a41f9cfbbd1d137bf1baab49e0d453a40a0ecd33':
Touch action bar title text: you will go to space today!
# Via Android Git Automerger (2) and others
* commit '53d49f1702df41a4ca342a1df6e720b16e094797':
Touch action bar title text: you will go to space today!
Title/subtitle text in an action bar is now a full alias for home/up.
Add some prototype ActionBar functionality around titles for future
API consideration.
Bug 7966136
Change-Id: I14377121dcb976d0a5f1e1862f35c3d267eb5458
When launching an assist, we have a new API allowing the
current foreground activity/application to provide additional
arbitrary contextual information that is stuffed in the
assist intent before it is launched.
Change-Id: I0b2a6f5a266dc42cc0175327fa76774f814af3b4
This change adds APIs support for implementing UI tests. Such tests do
not rely on internal application structure and can span across application
boundaries. UI automation APIs are encapsulated in the UiAutomation object
that is provided by an Instrumentation object. It is initialized by the
system and can be used for both introspecting the screen and performing
interactions simulating a user. UI test are normal instrumentation tests
and are executed on the device.
UiAutomation uses the accessibility APIs to introspect the screen and
a special delegate object to perform privileged operations such as
injecting input events. Since instrumentation tests are invoked by a shell
command, the shell program launching the tests creates a delegate object and
passes it as an argument to started instrumentation. This delegate
allows the APK that runs the tests to access some privileged operations
protected by a signature level permissions which are explicitly granted
to the shell user.
The UiAutomation object also supports running tests in the legacy way
where the tests are run as a Java shell program. This enables existing
UiAutomator tests to keep working while the new ones should be implemented
using the new APIs. The UiAutomation object exposes lower level APIs which
allow simulation of arbitrary user interactions and writing complete UI test
cases. Clients, such as UiAutomator, are encouraged to implement higher-
level APIs which minimize development effort and can be used as a helper
library by the test developer.
The benefit of this change is decoupling UiAutomator from the system
since the former was calling hidden APIs which required that it is
bundled in the system image. This prevented UiAutomator from being
evolved separately from the system. Also UiAutomator was creating
additional API surface in the system image. Another benefit of the new
design is that now test cases have access to a context and can use
public platform APIs in addition to the UiAutomator ones. Further,
third-parties can develop their own higher level test APIs on top
of the lower level ones exposes by UiAutomation.
bug:8028258
Also this change adds the fully qualified resource name of the view's
id in the emitted AccessibilityNodeInfo if a special flag is set while
configuring the accessibility service. Also added is API for looking
up node infos by this id. The id resource name is relatively more stable
compared to the generaed id number which may change from one build to
another. This API facilitate reuing the already defined ids for UI
automation.
bug:7678973
Change-Id: I589ad14790320dec8a33095953926c2a2dd0228b
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
Also add MockContentResolver constructor to provide a Context, and
move to singleton ActivityThread, since there is only one inside
each process. This makes ActivityThread accessible from threads like
InstrumentationThread.
Change-Id: Ib8b18f1b9bba8820ff412d782a43511066eabf24
Implemented reading and writing state to retain information
across boots, API to retrieve state from it, improved location
manager interaction to monitor both coarse and fine access
and only note operations when location data is being delivered
back to app (not when it is just registering to get the data at
some time in the future).
Also implement tracking of read/write ops on contacts and the
call log. This involved tweaking the content provider protocol
to pass over the name of the calling package, and some
infrastructure in the ContentProvider transport to note incoming
calls with the app ops service. The contacts provider and call
log provider turn this on for themselves.
This also implements some of the mechanics of being able to ignore
incoming provider calls... all that is left are some new APIs for
the real content provider implementation to be involved with
providing the correct behavior for query() (return an empty
cursor with the right columns) and insert() (need to figure out
what URI to return).
Change-Id: I36ebbcd63dee58264a480f3d3786891ca7cbdb4c
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
