...mismatched uid: X on disk, Y in settings" errors on Froyo and Gingerbread
Deal more gracefully with the uid changing in three ways:
1. If the uid on disk has become root, then have installd change it to
the application's uid. This is to correct a potential case where
installd was interrupted while linking or unlinking the libs dir,
during which it temporarily changes the owner of the dir to root
so that a malicious app can not get in its way. So if the uid on
disk has become root, we assume we can safely just change it back
to the correct uid.
2. When scaning packages at boot, use the same "delete and rebuild data
directory" code for third party applications as we have for system
applications. This allows us to at least end up in a state where the
app will run, even if its data is lost.
3. But we really don't want to get in to case 2, so if an application
update is being installed and we find that the uid we now have for
the app is different than the one on disk, fail the update. This will
protect against for example a developer changing the sharedUserId of
their app and getting into this bad state.
Bug: 6295373
Change-Id: Ic802fdd818ac62449ff3c61d1fff1aa4d4942f39
- Toast will resolve its gravity (when START / END) from the System locale
- see bug #5429822 UI should be mirrored for RTL locales (Arabic, Hebrew, farsi)
Change-Id: I3fe810b87d708f2ee80ca6258ad25ab32ae85d82
Adding extras to identify the:
- URL from which the APK originated
- the HTTP referrer associate with the URL
Bug: 6544677
Change-Id: Ie3d2244d9befa7161eeceb458573d6b0f8206cc7
Bug: 6628376
The issue here is that contentX & contentY can both be 0 if we are scrolling
slowly enough as they are adjusted by the page's scale and can thus round down.
However, this would result in us falling out of layer drag mode even though
we haven't tried to scroll past the edge of the layer. Detect this case, and
stay in layer scroll mode.
Change-Id: I3c655d0d03e8f89887abbe718bd24699c133ee1a
Bug: 6569073
Only nativeDestroy and nativeStopGL need to be called on the UI thread,
so split up destroyImpl into 3 functions, and only have the native
destroy be pushed to the UI thread if necessary. Also make the work that
is delayed be static without references to the finalizing WebView to allow
it to be fully deleted immediately after finalization.
Change-Id: I4e424051e69df0bc409af95ca3f3d2b9e58a6b75
1. If the last touch explored location is within the active window we
used to click on exact location if it is within the accessibility
focus otherwise in the accessibility focus center. If the last touch
explored location is not within the active window we used to just
click there. This breaks in the case were one has touch explored
at a given place in the current window and now a dialog opens *not*
covering the touch explored location. If one uses swipes to move
accessibility focus i.e. to traverse the dialog without touching
it one cannot activate anything because the touch explorer is using
the last touch explored location that is outside of the active
window e.g the dialog.
The solution is to clear the last touch explored location when a
window opens or accessibility focus moves. If the last touch
explored location is null we are clicking in the accessibility
focus location.
bug:6620911
2. There is a bug in the window manager that does not notify a
window that its location has changed (bug:6623031). This breaks
accessibility interaction with dialogs that have input because
when the IME is up the dialog is moved but not notified. Now
the accessibility layer gets incorrect location for the
accessibility focus and the window bounds.
The soluion is when the accessibility manager service calls
into the remove thress to obtain some accessibility node infos
it passes the window left and top which it gets from the
window manager. These values are used to update the attach info
window left and top so all accessibility node infos emitted
from that window had correct bounds in screen coordinates.
bug:6620796
Change-Id: I18914f2095c55cfc826acf5277bd94b776bda0c8
Bug 6550358
The EditText constructor now calls setTextIsSelectable, which uses
getText where the cast exception happens because the EditText is not
yet fully built and its text does not have the right type.
Fixed by using mText directly instead of getText().
Change-Id: I52a2720ae99475881f210ac74464728cab92147e