Modify test so that rotation animation is entered one final time after rotation completes. This last time causes mUpdateRotation to be set true forcing a test for orientation change.
Fixes bug 6109189.
Change-Id: I25475f336a3439a56b1c540205d09ee48c1d2b7c
- Add a cancel API
- Add more error reporting on WPS
- Fix network status reporting that showed up with new implementation
Change-Id: I499796c80d16d18df95fb702d029aa7e7283b603
writePidDns() does not increase the index in case first given dns
already exist in the property.
Change-Id: I1129d0042929b3ee119160e53cae0e4143c7ea88
Signed-off-by: yoonsung.nam <yoonsung.nam@samsung.com>
This fixes a crash on tablets introduced by Change Ifad76fb2. It was caused
by calling nativeStartSurfaceFlingerAnimation() on devices that previously
didn't call it and apparently don't support some feature it uses.
Change-Id: Ia4c04e7e611f45cde0fbeb861aec3435d1719552
Fix the current asynchronous API to use callback like the way
was done with p2p API.
In the process, fix the use of WPS
Change-Id: Ib6f8714cf51b3525b655948268804e7eaaf17587
When Wi-fi connects at L2 layer, the beacons reach and the device
can maintain a connection to the access point, but the application
connectivity can be flaky (due to bigger packet size exchange).
We now use Watchdog to monitor the quality of the last hop on
Wi-Fi using signal strength and ARP connectivity as indicators
to decide if the link is good enough to switch to Wi-Fi as the uplink.
ARP pings are useful for link validation but can still get through
when the application traffic fails to go through and thus not best indicator
real packet loss since they are tiny packets (28 bytes) and have
much low chance of packet corruption than the regular data
packets.
Signal strength and ARP used together ends up working well in tests.
The goal is to switch to Wi-Fi after validating ARP transfer
and RSSI and then switching out of Wi-Fi when we hit a low
signal strength threshold and waiting until the signal strength
improves and validating ARP transfer.
Change-Id: Ica593291ec7772da892f03cf45b649635b730c47
Still possible for netd to get wedged but system won't die because of it.
Leads the way to having forking netd - then only individual commands would
wedge, promoting stability.
bug:5864209
bug:6019952
Change-Id: I43e4c5072863b8b812d4fe24d30d92eb1a11651a
An "UpdateLock" works similarly to a wake lock in API: the caller is
providing a hint to the OS that now is not a good time to interrupt
the user/device in order to do intrusive work like applying OTAs.
This is particularly important for headless or kiosk-like products
where ordinarily the update process will be automatically scheduled
and proceed without user or administrator intervention.
UpdateLocks require that the caller hold the new signatureOrSystem
permission android.permission.UPDATE_LOCK. acquire() and release()
will throw security exceptions if this is not the case.
The "is now convenient?" state is expressed to interested parties
by way of a sticky broadcast sent only to registered listeners. The
broadcast is protected; only the system can send it, so listeners
can trust it to be accurate. The broadcast intent also includes a
timestamp (System.currentTimeMillis()) to help inform listeners that
wish to implement scheduling policies based on when the device became
idle.
The API change here is a tiny one: a dump(PrintWriter) method has been
added to the TokenWatcher class to facilitate getting information out
of it for dumpsys purposes. UpdateLock itself is still @hide.
Bug 5543442
Change-Id: I3709c831fc1883d7cb753cd2d3ee8e10a61e7e48
When we find a higher priority match for tethering traffic we should turn off
whatever we were trying before.
bug:6083611
Change-Id: I06ee41336df107353bf1a979150345e461574a48
The code for this was fairly conservative since the components of the
apps could change, leaving junk in the preferred app list. Now we
don't pro-actively clear them, but try to catch missing components
later.
Change-Id: I793063449dcc577fd3d56bb56495b308f0c95ea8
* changes:
Detect animation completions like we used to. Previous approximations weren't indicating completion and windows weren't being layered correctly as a result.
debug
Previous approximations weren't indicating completion and windows weren't being layered correctly as a result.
Change-Id: I08fcd278485bb87dc10bca257b9f8073108753f3
...if the process is killed and restarted
Try to ensure that in all cases we deliver an activity result if one
was requested.
Change-Id: Id43e830d2ee782f98ed1e3b68e5e16f3258d4ad8
This fixes a bug where the device could see a priority inversion when
updating display brightness. The problem occurs because the code that
manages screen brightness holds the master lock while waiting for the
native method to complete. On some devices, each call can amount to
tens to hundreds of ms, which meant clients using PowerManager APIs
could block for the duration of the call. In some cases, the animation
could block for many seconds because the unfairness of Java locks.
The solution is to handle all brightness updates in a separate thread that
does not hold the master lock while calling native methods.
This also makes the animation more consistent by animating by actual
wall clock time rather than depending on the round-trip from the driver.
Change-Id: Ifad76fb2fb77e7b2a72dd9150440d87e22581b40
Useful especially for last kmsg (e.g. IMG/DSS logs truncate
and loose useful info). Since this is a max, won't affect files
that are already shorter than 64kb.
Change-Id: Ia5bb178678067e69384285e8c338dc8cb6ad071b
My previous change to speed up the time the IME is dismissed was
fundamentally flawed. That change basically switched the order
the application called the input method manager service from doing
startInput() and then windowGainedFocus(), to first windowGainedFocus()
and then startInput().
The problem is that the service relies on startInput() being done
first, since this is the mechanism to set up the new input focus,
and windowGainedFocus() is just updating the IME visibility state
after that is done. However, by doing the startInput() first, that
means in the case where we are going to hide the IME we must first
wait for the IME to re-initialize editing on whatever input has
focus in the new window.
To address this, the change here tries to find a half-way point
between the two. We now do startInput() after windowGainedFocus()
only when this will result in the window being hidden.
It is not as easy as that, though, because these are calls on to
the system service from the application. So being able to do that
meant a fair amount of re-arranging of this part of the protocol
with the service. Now windowGainedFocus() is called with all of
the information also needed for startInput(), and takes care of
performing both operations. The client-side code is correspondingly
rearranged so that the guts of it where startInput() is called can
instead call the windowGainedFocus() entry if appropriate.
So... in theory this is safer than the previous change, since it
should not be impacting the behavior as much. In practice, however,
we are touching and re-arranging a lot more code, and "should" is
not a promise.
Change-Id: Icb58bef75ef4bf9979f3e2ba88cea20db2e2c3fb
This change introduces a few new bits of data on
Notification that will help the Notification Manager and
System UI route and display them more intelligently:
-> priority: an integer in a predefined range that
indicates the app's best guess as to the relative
importance (to the user, right now) of that information
-> kind: a tag (really, set of tags) indicating the general
type of notification (realtime, asynchronous, etc)
-> extras: a Bundle of additional key/value pairs
associated with this notification (currently @hidden)
The notification manager takes these data into account when
assigning to each notification a score which is passed with
the notification on to the system UI, where it can be used to
affect presentation. For example:
- Spammy apps (identified explicitly by the user or by
some other means) will have their notifications scored
very negatively by the notification manager, allowing
the UI to suppress them
- Notifications of higher score might be shown larger
or in a different way
- Very important notifications (indicated by a very high
score) might interrupt the user during an otherwise
important task (videochat, game, etc)
Implementation note: This replaces/extends the old internal
notion of "priority", which was mostly used to organize
ongoings and system notifications at the top of the panel.
Change-Id: Ie063dc75f198a68e2b5734a3aa0cacb5aba1ac39
1. Before there were two caches one in the app process that
kept track only the ids of infos that were given to a
querying client and one in the querying client that
holds the infos. This design requires precise sync
between the caches. Doing that is somehow complicated
since the app has cache for each window and it has
to intercept all accessibility events from that window
to manage the cache. Each app has to have a cache for
each querying client. This approach would guarantee that
no infos are fetched twice but due to its stateful nature
and the two caches is tricky to implement and adds
unnecessary complexity. Now there is only one cache in
the client and the apps are stateless. The client is
passing flags to the app that are a clue what nodes to
prefetch. This approach may occasionally fetch a node
twice but it is considerably simpler and stateless
from the app perspective - there is only one cache.
Fetching a node more than once does not cause much
overhead compared to the IPC.
Change-Id: Ia02f6fe4f82cff9a9c2e21f4a36747de0f414c6f
These are permissions that an application can request, but won't
normally be granted. To have the permission granted, the user
must explicitly do so through a new "adb shell pm grant" command.
I put these permissions in the "development tools" permission
group. Looking at the stuff there, I think all of the permissions
we already had in that group should be turned to development
permissions; I don't think any of them are protecting public APIs,
and they are really not things normal applications should use.
The support this, the protectionLevel of a permission has been
modified to consist of a base protection type with additional
flags. The signatureOrSystem permission has thus been converted
to a signature base type with a new "system" flag; you can use
"system" and/or "dangerous" flags with signature permissions as
desired.
The permissions UI has been updated to understand these new types
of permissions and know when to display them. Along with doing
that, it also now shows you which permissions are new when updating
an existing application.
This also starts laying the ground-work for "optional" permissions
(which development permissions are a certain specialized form of).
Completing that work requires some more features in the package
manager to understand generic optional permissions (having a
facility to not apply them when installing), along with the
appropriate UI for the app and user to manage those permissions.
Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
1. UiTestAutomationBridge was accessing the root node in the
active window by tracking the accessibility event stream
and keeping the last active window changing event. Now
the bridge is stateless and the root node is fetched by
passing special window and view id with the request to
the system.
2. AccessibilityNodeInfos that are cached were not finished,
i.e. not sealed, causing exception when trying to access
their children or rpedecessors.
3. AccessibilityManagerService was not properly restoring its
state after the UI automation bridge disconnects from it.
I particular the devices was still in explore by touch mode
event if no services are enabled and the sutomation bridge
is disconnected.
4. ViewRootImpl for the focused window now fires accessibility
events when accessibility is enabled to allow accessibility
services to determine the current user location.
5. Several missing null checks in ViewRootImpl are fixed since
there were scenraios in which a NPE can occur.
6. Update the internal window content querying tests.
7. ViewRootImpl was firing one extra focus event.
bug:6009813
bug:6026952
Change-Id: Ib2e058d64538ecc268f9ef7a8f36ead047868a05
Two things: (1) make sure the boot message is always positioned within
the entire unrestricted display, and (2) allow the dim background to go
on top of the nav bar when being used for the boot message (this latter
is really a hack that should be more generally fixed in the future).
Change-Id: I7261b044eb802a39cadff931b50a679ff18781d6
- Move mPolicy.startAnimationLw and mPolicy.finishAnimationLw into same method as mPolicy.animatingWindowLw.
- Fix first parameter of performLayoutLockedInner(initial, ...) to pass true on initial pass.
Change-Id: If1b47bb8a7e03cf427769c657e371abc0910b3e3
