Changes in this patch include
[x] Long is used to store native pointers as they can
be 64-bit.
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
[x] AssetAtlasManager is not completely 64-bit compatible
yet. Specifically mAtlasMap member has to be converted
to hold native pointer using long. Added a TODO to
AssetAtlasManager.java to indicate the change required.
Change-Id: I940433f601c6db998c1a8ffff338f5361200d5ed
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Symptom:
When press Home key to home screen, user is able to see the activity's window shown on top of wallpaper and below launcher(widgets).
Root Cause:
The ensureActivitiesVisibleLocked() is called pretty often (for example when a new process bound).
If the top activity "B" was finishing, then the previous activity "A" should be visible.
Therefore, the activity "A" window will be set to visible and then launched activity "A", but it does not updates the visible state in ActivityRecord for "A".
There has a timing issue that if a new activity "C" is started, "C" becomes the new top activity and be resumed.
In that case, Activity "A" window will remain visible even if it is behind a full screen activity "C" because the ActivityRecord.visble of "A" is still false, so the window visibility won't be update.
So when user press home key and back to launcher, the surface of activity "A" will be composed on top of wallpaper.
Solution:
Updates ActivityRecord.visible to true for "A". After "C" is started, the "A" will be called WindowManagerService.setAppVisibility() to set invisible, then called onStop() when execute ensureActivitiesVisibleLocked() again.
Change-Id: I536ba04b95d8d274fea6d679a6493e620bc981e2
Since Kitkat, an app pre-loaded under /system/priv-app/ has
FLAG_PRIVILEGED. However, if the app updated and the device
rebooted, privileged flag is unset from pkgFlags. This patch
fix issue to assign privileged flag when scanning the updated
packages.
Bug: 12640283
Change-Id: Ic24b5882f65dabdfae9cc39da3d68661bed4fc31
It is not possible to send a broadcast before the system
boot is completed. If you do it anyway you will get an
IllegalStateException: Cannot broadcast before boot completed.
If a memory card is inserted or removed while the phone is
booting up, there is a risk that the MountService will try to
broadcast a storage intent too early, and cause the device
to crash.
Use FLAG_RECEIVER_REGISTERED_ONLY_BEFORE_BOOT to avoid
problems with too early broadcasts.
Change-Id: Ied36a13d235df37c9788e45a35de40d919ae0cd0
Issue detail:
Assume X, Y are non-fullscreen activities.
a.Home starts an activity X in task A in application stack.
b.X starts an activity Y in <task A> or <new task B>
c.Activity X will be invisible.
How to fix:
Because the function "isActivityOverHome" means an activity is able to see home.
But there may have many non-fullscreen activities between the top non-fullscreen activity and home.
If flag "behindFullscreen" is set, those middle activities will be invisible.
So it should only take care from who is adjacent to home.
Then check two flags frontOfTask(task root) and mOnTopOfHome for constraining the condition.
Change-Id: I60bcea304976414e44835a0a38675aae365e9e19
For storing pointers, long is used, as native pointers
can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: Ib4435f0794740d545c1e640087849215e6844802
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Code that expected a single top level element in an XML file
was doing something like :
while (type != START_TAG) { next(); }
This would loop forever when the XML being parsed was empty,
where each call to XmlPullParser.next() would return END_DOCUMENT.
bug: https://code.google.com/p/android/issues/detail?id=64173
Change-Id: I7543203e976a8999ae471a6c2d629249a87011bb
If there is input to be handled during finish activity we can get a
keydispatching timeout ANR. The reason is that finish activity is some
times not possible, and the activity is instead put on a finish queue.
The activity will then be finished sometime in the future. When we add
the activity to the finish queue, key dispatching is paused, and there
is an ANR timer waiting for it to be resumed again. Since it can take a
long time before the activity is actually finished, we need to resume
the key dispatching to avoid the ANR.
Change-Id: Icea4ab3b5ad05c8bfbadf8f5cece1a59ec621469
When unregistering MountService listeners, their Binder proxy
objects were compared to registered listeners instead of their
backing objects.
Change-Id: Ie98a686b1d17544f1eda59fb3eb0dc02d836c1b2
In ActivityTask.moveTaskToBackLocked NullPointerException may occur
when moving back with only current Activity in stack. This due to a
condition that may trigger despite a TaskRecord being null and then
attempt accessing the TaskRecord.mOnTopOfHome variable.
TaskRecord task may be set to null when no resumed activity remain.
Resolved by assuring that flag mOnTopOfHome is instead set to false
for current TaskRecord in case where there are no remaining activities
above home.
The above bug has already been corrected in the following commit,
ada62fca51d314cefe2c5da4e007df5b9abf320d, but it does not set the
cottect value to mTopOfHome for the current taks, see below.
Variable mOnTopOfHome will not be set to false in situations where
stack is of size 1 or less and task is null, perhaps from already
having finished current activity.
To avoid current TaskRecord maintaining value mOnTopOfHome to true
after launching Home this variable is set to false.
Impact should not be major due to correction earlier that makes sure
that there is always a TaskRecord.mOnTopOfHome set to true above Home
activity but if not correctly set for current task still gives a
possibility of bad behavior.
Change-Id: Ie86ad99c188aaa05b0de9d58eaa16c42b6fc4341
On devices without /dev/alarm, use a new backend based on timerfd.
timerfd has near-equivalent syscalls for the /dev/alarm ioctls we care
about, with two key differences:
1) /dev/alarm uses one fd for all clocks, while timerfd needs one fd per
clock type.
AlarmManagerService addresses this by replacing the fd (int) with an
opaque pointer (long) to the backend-specific state.
2) When the RTC changes, the /dev/alarm WAIT ioctl always returns, while
timerfd cancels (and signals events) only on specially-flagged RTC
timerfds.
The timerfd backend masks this by creating an extraneous RTC timerfd,
specifically so there's always something to signal on RTC changes.
Change-Id: I5aef867748298610347f6e1479dd8bf569495832
Signed-off-by: Greg Hackmann <ghackmann@google.com>
* No longer support a package name stanza outside of
a signature tag. Package names, by themselves, have
no security associated with them in Android and thus we
should not be allowing or encouraging this
type of policy.
* Allow for nested package name stanzas inside
signature stanzas. There are cases where a finer
distinction needs to be made among apps signed with
the same cert. New code allows a different seinfo
tag to be assigned to the listed package names
signed by the parent cert. When a determination needs
to be made concerning seinfo assignments, the inner
seinfo tag takes precedence over the outer seinfo
labels which are assigned to just the signature.
* Temp structures are now used to parse new policy files
until the entire xml file is parsed and deemed correct,
at which time the temp structures are copied over to the
permanent class structures. This ensures that any structural
errors with the policy will not result in partial loads.
* Valid stanzas look like the following with the inner
package piece being optional.
<signer signature="">
<seinfo value=""/>
<package name="">
<seinfo value=""/>
</package>
<signer>
<default>
<seinfo value=""/>
</default>
Change-Id: Ia204d71211776dcf9b2dcc86ad6d77c4ad39dc25
This is necessary so that the framework can know whether an IPv6
address is likely to be usable (i.e., if it's global scope and
preferred). Also, it will simplify the address notification
methods in INetworkManagementEventObserver, which currently take
the address, the flags, and the scope as separate arguments.
1. Add flags and scope to the class and update the unit test.
Use the IFA_F_* and RT_SCOPE_* constants defined by libcore.
Since most callers don't know about flags and scope, provide
constructors that default the flags to zero and determine the
scope from the address. Addresses notified by the kernel will
have these properly set. Make multicast addresses invalid.
Update the class documentation.
2. Provide an isSameAddressAs() method that compares only the
address and prefix information between two LinkAddress
objects. This is necessary because an interface can't have
two addresses with the same address/prefix but different
flags.
3. Update LinkProperties's addLinkAddress and removeLinkAddress
to identify existing addresses to add/remove using
isSameAddressAs instead of implicit equals(). Specifically:
- If addLinkAddress is called with an address that is already
present, the existing address's flags and scope are updated.
This allows, for example, an address on an interface to go
from preferred to deprecated when it expires, without it
having to be removed and re-added.
- If removeLinkAddress is called with an address that is
present but with different flags, it deletes that address
instead of failing to find a match.
4. Update the INetworkManagementEventObserver address
notification methods to take just a LinkAddress instead of
LinkAddress, flags, and scope. While I'm at it, change the
order of the arguments for consistency with the other
functions in the interface.
Change-Id: Id8fe0f09a7e8f6bee1ea3b52102178b689a9336e
It never worked anyhow, at least in AOSP, as nothing checks that property,
and is pointless now that enforcing mode is set by init.
Change-Id: If05dd49963c5d7081e00039b5e378032bea0939b
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Currently address{Updated,Removed} pass in the address as a
string such as "fe80::1/64". Use LinkAddresses instead, since
that's what it is.
This makes the code more robust in the unlikely case that netd
passes in an invalid string. In the future we can move flags and
scope into the LinkAddress itself and simplify the code further.
Bug: 9180552
Change-Id: I66599f9529cf421caa7676fdd0141bb110b8589e
These are sent if the device receives IPv6 Router Advertisements
with DNS server configuration options. Currently, nothing listens
to them; in a future change we will use them as IPv6 DNS servers.
[Cherry-pick of 416740ad4d9132005a71dc0883334e852235a18a]
Bug: 9180552
Change-Id: I05000c0cd3867a68ab390102e8470b6912a9d3aa
Tethering currently inherits from the AIDL interface
INetworkManagementEventObserver, so it has to provide no-op
implementations of all the interface's methods. Inherit from
BaseNetworkObserver and get rid of the no-ops.
[Cherry-pick of f4e90eac87bc31611ddd80c46fc924d35ce66c1c]
Bug: 9180552
Change-Id: I74859b0d77951005651aaaa418185857e40eeedb
Since SurfaceView layers are located below application layers,
SurfaceView is not captured by screenshotApplications()
when the application is running in fullscreen.
Moreover, ws.isFullscreen(dw, dh) returns mostly true
on the devices which do not use the navigation bar.
Change-Id: Ia1036c79054950384a97504714929fd85c8147de
Signed-off-by: Sangkyu Lee <sk82.lee@lge.com>
BatteryStatsImpl can reset its collected data, including
removing a BatteryStatsImpl$Uid$Proc object. If a ProcessRecord
has a direct reference, then the battery stats for a process
will be recorded in an old Proc object and prevent GC, causing
a memory leak.
bug:11087238
Change-Id: I19a9cd9d8361c10446a8ebdd5c0860b56c442209
There is still a flash of black when going to a non-wallpaper activity
from keyguard. This is not a regression from jb-mr2 and any fixes to
clean it up are too risky at this late date.
Fixes (partially) bug 11570753.
Change-Id: I17aaae4ab8be570f7e28276a7b8ac4b8685e7551
Only allow the system ui and settings to connect to a remote display.
To do this, we essentially hide the remote displays from applications
by using the ROUTE_TYPE_REMOTE_DISPLAY then add permission checks
around the operations that connect to them.
As a bonus, this may actually save power on devices since applications
that use MediaRouter will not longer be performing discover on
remote display routes at all.
Bug: 11257292
Change-Id: I9ea8c568df4df5a0f0cf3d0f11b39c87e2110795
