GitLab

Change-Id: I10b05c28954a27f11482751e14287ec21422dce2

Bug: 8175766
Change-Id: I0f0739d9f71386bae6c4ad23a2eb33e38d6a2d87

Change-Id: Ie390d2bbd8abc0d063c1f313797e8c3d21d27490

Change-Id: I35e824e47ad758ab6408e91e2ba5dcda053a82f5

This change required fixing some bugs in how AAPT handles
qualified symbols such as "android:layout_height"
when generating JavaDoc links.  The links were being
generated using the package name of the generated R file
rather than the package name of the referenced symbol.
These broken links caused the JavaDoc build to fail.

Bug: 8175766
Change-Id: I52fbef27825a25abca960cb44b59c2132267e9d6

By adding these stubs, they will be automatically added to framework.aidl
in sdk builds.

This makes it easier for unbundled apps to pass these objects across
AIDL calls.

ContentValues & CursorWindow are already public Parcelables. It is an
oversight that they were not already in framework.aidl.

There are a lot of other public Parcelables that are missing from
framework.aidl. This just fixes two commonly requested ones.

Change-Id: If61e19b1206da1680413d9ea03de87a90b6d233e

b/8631678

1.GeofenceRequest object created.
2.MonitorState moved to a new callback
3.getTypeAndStatus separated to 2 calls.
4.Binder death implemented
5.geofenceChange callback name changed.
6.Parameters rearranged in some calls.

Change-Id: I8fe9621186aeb49efeb0eef1821a2556afe03cfc

Change-Id: Iea2e13ef2fad47d6a19d380b5655aeeda0414930

Add support for doing geofencing in hardware.

Change-Id: I6d5015190e8d84e1f4beb1010ed977a71c1622d0

This is the best and only way for apps to listen for
notifications: create a NotificationListenerService, wait
for the NoMan to bind to you (as a result of the user
checking a box somewhere in Settings and agreeing to a
scary dialog box), and you'll start receiving notification
posted and dismissed callbacks. Your service, while enabled,
will also be able to clear one or all notifications.

Use this power wisely.

This change moves StatusBarNotification out of
com.android.internal into android.service.notification.
[Internal customers, including System UI and early users of
the system-only listener binder API, will need to be
updated.]

Bug: 8199624
Change-Id: I1be46f823d4b3ddc901109ec1e085cd6deb740c2

This is the best and only way for apps to listen for
notifications: create a NotificationListenerService, wait
for the NoMan to bind to you (as a result of the user
checking a box somewhere in Settings and agreeing to a
scary dialog box), and you'll start receiving notification
posted and dismissed callbacks. Your service, while enabled,
will also be able to clear one or all notifications.

Use this power wisely.

This change moves StatusBarNotification out of
com.android.internal into android.service.notification.
[Internal customers, including System UI and early users of
the system-only listener binder API, will need to be
updated.]

Bug: 8199624
Change-Id: I1be46f823d4b3ddc901109ec1e085cd6deb740c2

Change-Id: I2a80f3c3f30a3d15673d797fa3d1211286f75030

The input method manager service now supplies an input channel for
communication while creating an IME session on behalf of the
application.

This change significanly reduces the overhead of IME event dispatch
by using a standard input channel to send input events rather than
using binder.  This results in fewer thread context switches
and fewer object allocations.

What's more, the IME may perform additional batching of the motion
events that it receives which may help it catch up if it is
getting behind while processing them.

Bug: 7984576
Bug: 8473020
Change-Id: Ibe26311edd0060cdcae80194f1753482e635786f

Bug: 8276952
Change-Id: If7051086c060fcce5d1e958ebbddec0784c851da

OBB backup/ restore is no longer handled within the target app
process.  This is done to avoid having to require that OBB-using
apps have full read/write permission for external storage.

The new OBB backup service is a new component running in the
same app as the already-existing shared storage backup agent.
The backup infrastructure delegates backup/restore of apps'
OBB contents to this component (because the system process
may not itself read/write external storage).

From the command line, OBB backup is enabled by using new
-obb / -noobb flags with adb backup.  The default is noobb.

Finally, a couple of nit fixes:

- buffer-size mismatch between the writer and reader of chunked
  file data has been corrected; now the reading side won't be
  issuing an extra pipe read per chunk.

- bu now explicitly closes the transport socket fd after
  adopting it. This was benign but triggered a logged
  warning about leaked fds.

(Cherrypicked)

Change-Id: I471f6348abcccb7bf1e1710b7beda9f23de53e14

This is a class representing a window and providing limited
interaction with it, which can be handed across processes.

Change-Id: I22885f2064a9cc8c68d690a5858c2e28bbb6a0f3

The API classes are hidden for now. Will unhide after API console
approval.
Change-Id: I8283dd562fd6189fdd15c866ef2efb8bbdbc4109

Use with INotificationManager.registerListener(). Limited to
system only right now.

Change-Id: I65b6a8778267022cdc5e58eb75ae607a54b1cc52

Now the dependency should be correctly established by
framework_docs_LOCAL_JAVA_LIBRARIES.

Change-Id: I4c0ed2d3fb2855539027c7a0eb663f5747ae3ebd

This reverts commit 5f9922d7

Change-Id: I310f27b231c6d64d6d407ae451b189a6ecf6b34f

This reverts commit 5f9922d7

Change-Id: I310f27b231c6d64d6d407ae451b189a6ecf6b34f

This reverts commit 4c01047e

Change-Id: I4465cfa678717ff7c202347ae6ad36d12d5393bc

Change-Id: I44c51e12225cd0b1d82bfb70129fefa8ba66e8b4

Change-Id: I501cc140994b2822c3df1f00639076f17765f256

Because ISms.aidl imports PendingIntent we couldn't easily
make opt/telephony part of the PDK. So this change moves
ISms.aidl and SmsRawData.*, which ISms.aidl also imports,
back to frameworks/base.

Change-Id: Ia64c6e771d5a292d9bfebb413a43f3745df55c85

Change-Id: I5653eb710f13f0a097cb1cf447469c4da7342fe2

Change-Id: I273e82bdad66ada3bf0f7ec9176bc304b9ee1ee8

Doc change: remove htmlified samples from docs build for now. Samples are still downloadable thorugh SDK Manager.

Change-Id: I9cfa53e605f476daf6cf914f256df600e1d77f89

Change-Id: I933cbafa0712de47b4bcf72d2a7c4f99bf18f930

Change-Id: I6ad24252f10211a88d1f98e356bc9da97442f91c

Change-Id: I4f1d099995402613f58401a506ba272abfb563ba

Change-Id: Ieaba759a0f69b45c4b8839cbed1fe757cdf190c5

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

Change-Id: I63e8514f34c880d0badaab33a347f54a80c84da6

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

1. This patch takes care of the case where a magnified window is covering an unmagnigied
   one. One example is a dialog that covers the IME window.

bug:7634430

2. Ensuring that the UI automator tool can connect and correctly dump the screen.

bug:7694696

3. Removed the partial implementation for multi display magnification. It adds
   unnecessary complexity since it cannot be implemented without support for
   input from multiple screens. We will revisit when necessary.

4. Moved the magnified border window as a surface in the window manager.

5. Moved the mediator APIs on the window manager and the policy methods on the
   WindowManagerPolicy.

6. Implemented batch event processing for the accessibility input filter.

Change-Id: I4ebf68b94fb07201e124794f69611ece388ec116

So they can be used in unbundled builds.

Bug: 7296240

Change-Id: Ib0ba88387cb45ff795a4e8e3a836cf670d5016b7

1. The screen magnification feature was implemented entirely as a part of the accessibility
   manager. To achieve that the window manager had to implement a bunch of hooks for an
   external client to observe its internal state. This was problematic since it dilutes
   the window manager interface and allows code that is deeply coupled with the window
   manager to reside outside of it. Also the observer callbacks were IPCs which cannot
   be called with the window manager's lock held. To avoid that the window manager had
   to post messages requesting notification of interested parties which makes the code
   consuming the callbacks to run asynchronously of the window manager. This causes timing
   issues and adds unnecessary complexity.

   Now the magnification logic is split in two halves. The first half that is responsible
   to track the magnified portion of the screen and serve as a policy which windows can be
   magnified and it is a part of the window manager. This part exposes higher level APIs
   allowing interested parties with the right permissions to control the magnification
   of a given display. The APIs also allow a client to be registered for callbacks on
   interesting changes such as resize of the magnified region, etc. This part servers
   as a mediator between magnification controllers and the window manager.

   The second half is a controller that is responsible to drive the magnification
   state based on touch interactions. It also presents a highlight when magnified to
   suggest the magnified potion of the screen. The controller is responsible for auto
   zooming out in case the user context changes - rotation, new actitivity. The controller
   also auto pans if a dialog appears and it does not interesect the magnified frame.

bug:7410464

2. By design screen magnification and touch exploration work separately and together. If
   magnification is enabled the user sees a larger version of the widgets and a sub section
   of the screen content. Accessibility services use the introspection APIs to "see" what
   is on the screen so they can speak it, navigate to the next item in response to a
   gesture, etc. Hence, the information returned to accessibility services has to reflect
   what a sighted user would see on the screen. Therefore, if the screen is magnified
   we need to adjust the bounds and position of the infos describing views in a magnified
   window such that the info bounds are equivalent to what the user sees.

   To improve performance we keep accessibility node info caches in the client process.
   However, when magnification state changes we have to clear these caches since the
   bounds of the cached infos no longer reflect the screen content which just got smaller
   or larger.

   This patch propagates not only the window scale as before but also the X/Y pan and the
   bounds of the magnified portion of the screen to the introspected app. This information
   is used to adjust the bounds of the node infos coming from this window such that the
   reported bounds are the same as the user sees not as the app thinks they are. Note that
   if magnification is enabled we zoom the content and pan it along the X and Y axis. Also
   recomputed is the isVisibleToUser property of the reported info since in a magnified
   state the user sees a subset of the window content and the views not in the magnified
   viewport should be reported as not visible to the user.

bug:7344059

Change-Id: I6f7832c7a6a65c5368b390eb1f1518d0c7afd7d2

It was used in the cupcake era for docomo.  Is not used anymore.

Bug 7633569

Change-Id: I2ec826fc9a70d261a340957a937ed4c9f8e67c5c

Change-Id: Ic7ecbc8cf582460112d63d365c0cfb824478fff1