| e56b3f63e8235ab45e081fc9d3476a3e5248ddde |
|
06-Jun-2015 |
Dmitriy Ivanov <dimitry@google.com> |
Add path to native libraries inside apk
If an application has native code (and primary abi)
include path to corresponding folder inside apk-file
to ldLibraryPath when constructing PathClassLoader
Bug: 21647354
Bug: 21667767
Bug: 21726698
Bug: 8076853
Change-Id: Ib0a2f01ee69019d3206a00c542bd7d0f58d0c481
/frameworks/base/core/java/android/app/LoadedApk.java
|
| b9f3674c11ed9c89b80a69f728cbc5f540b2ecde |
|
09-Apr-2015 |
Jeff Sharkey <jsharkey@android.com> |
Support moving apps to expanded storage.
Start deriving the data path for apps based on the volume UUID where
the app lives. This path is used for all higher-level APIs, giving
us a clean place to switch app storage.
When parsing a package, keep track of the volume UUID where it lives
and update PackageSetting once installed. For now continue treating
moves as installs, but we'll eventually clean this up to avoid the
additional dexopt pass. Wire up move to use the new installd command
to move private data between devices.
Cache LoadedApk only for the current user, since otherwise the data
dir points at the wrong path.
Bug: 19993667
Change-Id: I53336e3b147d5fd3130e6800869af172b628da37
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 16df82d7ace0dbe625211561ccec9b6faf81debb |
|
10-Feb-2015 |
Calin Juravle <calin@google.com> |
am fd523efc: Merge "Get the instruction set that the libraries of secondary Abi is supported."
automerge: d1e074a
* commit 'd1e074a72452c909c7ed2a4baf220d9d2f306b20':
Get the instruction set that the libraries of secondary Abi is supported.
|
| fd523efcde98e97cd8c088f95198e6e13f4f8b64 |
|
10-Feb-2015 |
Calin Juravle <calin@google.com> |
Merge "Get the instruction set that the libraries of secondary Abi is supported."
|
| 0f8ecc84c8b86054bfd3275f942c3a705df01fbb |
|
12-Jan-2015 |
Olawale Ogunwale <ogunwale@google.com> |
am 9d293911: am ebdfb6e8: Merge "[ActivityManager] Distinguish FG or BG receiver finished"
* commit '9d293911221cac930eb8edfef01362ea083eeaab':
[ActivityManager] Distinguish FG or BG receiver finished
|
| 1f5ac4d322d76ca76fdf5dee40fe9549aad7437e |
|
03-Jan-2015 |
riddle_hsu <riddle_hsu@htc.com> |
[ActivityManager] Distinguish FG or BG receiver finished
Symptom:
Assume a foreground broadcast FG and a background BG.
If a recevier registers both FG and BG. When sending
BG and FG to the receiver, and the receiver BG receiver
completes first, its finishReceiver will trigger next FG
receiver rather than BG, and also deliver wrong result
code/data to the next.
More detail and sample:
https://code.google.com/p/android/issues/detail?id=92917
Root cause:
Due to BroadcastQueue:getMatchingOrderedReceiver will match
by receiver(IBinder), so the caller ActivityManagerService:
broadcastRecordForReceiverLocked will always match the first
queue(fg) if a receiver is both receiving fg and bg.
Solution:
Add a parameter flags to finishReceiver, then server side
could know the finished receiver should belong to which queue.
Another general solution but with bigger scope:
I60dce4a48e20c1002a61a979e4d78b9b0a8b94a0
Change-Id: I913ca6f101ac8ec6c7a8e42754e6781f80247b7f
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 4741cd92d1a34d5e7a86b645498df00865f6c651 |
|
17-Dec-2014 |
jgu21 <jinghui.gu@intel.com> |
Get the instruction set that the libraries of secondary Abi is supported.
The secondary Abi is for the apps which support the mulitArch feature.
In presence of a native bridge the instruction set supported by
secondary Abi might be different than the one secondary Abi used.
Change-Id: I318fb21e45c34de6cf1bf8ff63519aaa2b1e2520
Signed-off-by: jgu21 <jinghui.gu@intel.com>
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 23d40c40aa70866e12ccba640a71bbbf8d492a87 |
|
20-Nov-2014 |
Adam Lesinski <adamlesinski@google.com> |
Fix race when cleaning up receivers/services in Context
Bug:18135575
Change-Id: I2c69c8189d9ebd297c8a83fe84658b26cbb0528f
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 8091edbffbacbf80eebe0ed646e6ec9f6aafe5be |
|
15-Oct-2014 |
Narayan Kamath <narayan@google.com> |
Set threads' contextClassLoader during LoadedApk.makeApplication.
We used to set this from LoadedApk.getClassLoader. This had
the unfortunate side effect of clobbering the threads default
classloader when Context.createPackageContext().getClassLoader()
was called. This happens, for example, to every app that uses
a updatable webview.
bug: 17986934
Change-Id: If2b5938a19f836ea5fe60c94ea53a7125c2098c0
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 1e466385d4a4f1acee080fa0fdf16cc8fd8ce7ca |
|
15-Aug-2014 |
Adam Lesinski <adamlesinski@google.com> |
Have R classes generate their own reference rewrite logic
Change-Id: I0e5b8311fc3479d966a49f9acf0d4c32a6a024d3
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 2cb761e3ddb9d68ab430013e9cd15ecaab9fbc62 |
|
15-Aug-2014 |
Adam Lesinski <adamlesinski@google.com> |
Fix assumption about DynamicRefTable in aapt
Packages without any resources should not expect to have
a DynamicRefTable.
Bug:16895517
Bug:17056720
Change-Id: Id006f6bdbf08f30505f6ba5982bc9d1b09db0f0a
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 29564cd24589867f653cd22cabbaac6493cfc530 |
|
07-Aug-2014 |
Narayan Kamath <narayan@google.com> |
Remove system_server classes from the boot image.
We set the system_server classpath in the environment
(like we do with BOOTCLASSPATH). After the zygote forks
the system_server, we dexopt the classpath (if needed)
and then launch the system server with the correct
PathClassLoader. This needed several small / medium
refactorings :
- The logic for connecting to installd is now in a separate
class and belongs in the system_server.
- SystemService / SystemServiceManager have now moved to
classes.jar. They are only used from there, and since they
use Class.forName, we want them to be loaded by the
system_server classloader, and not the bootclassloader.
- BootReceiver now moves to frameworks.jar, because it is
used by ActivityThread and friends.
bug: 16555230
Change-Id: Ic84f0b2baf611eeedff6d123cb7191bb0259e600
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 6c4b9de8f1fd594038793c3924b52a44138c319e |
|
08-Aug-2014 |
Narayan Kamath <narayan@google.com> |
Validate instruction sets passed to installd.
We don't want folks passing down arbitrary strings.
bug: 16837404
Change-Id: I73ac66b376f1401f9f95f3c6323da6242ac8ed3d
/frameworks/base/core/java/android/app/LoadedApk.java
|
| fee756ff91ab4d8f0e09ddb050d22d88ebb66ae7 |
|
17-Jul-2014 |
Dianne Hackborn <hackbod@google.com> |
Implement issue #16330060: Inform ActivityManager about WebView...
...state changes.
Add a new API to tell the activity manager about a new dependency
one process has on another package. Start using it already for
when apps is Context.createPackageContext() to load code from another
app.
Also do some work on getting the monitoring of proc/uid states
in shape so it can be used by unundled code, along with an
AppImportanceMonitor class for doing so.
Some small fixes and additions to VoiceInteractionService.
Improve handling of unaccounted/overcounted battery use so that
they aren't shown to the user unless they are significant.
Change-Id: I22dd79a73f4e70103d3f8964494aebc8a31f971c
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 2053168eb4506e2f8795afdbe9731c6451e1589c |
|
14-Jul-2014 |
Narayan Kamath <narayan@google.com> |
Dexopt for Context.createPackageContext when code is included.
The package manager now keeps track of per ISA dex-opt state.
There are two important things to keep in mind here :
- dexopt can potentially be very slow. In cases where the target
package hasn't been dexopted yet, this can take multiple seconds
and may cause an ANR in the caller if the context is being
created from the main thread.
- We will need to remove the constraint that dexopt can only be
requested by the system (or root). Apps will implicitly be
requesting dexopt by asking for package contexts with code included.
It's important to note that unlike dalvik, the dexopt stage in ART
isn't optional. ART cannot load classes directly from dex files.
bug: 15313272
Change-Id: I0bd6c323a9c1f62f1c08f6292b7f0f7f08942726
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 7dba6eb3ac4fd6c8195cb0d0425866de50a9e114 |
|
16-Jul-2014 |
Narayan Kamath <narayan@google.com> |
Adjust nativeLibraryDir for package contexts of multiArch installs.
When we're creating a package context for a multi-arch app,
adjust the native library directory to match the bitness of
the process creating the context.
This change also removes apkRoot (which wasn't really being used)
and replaces it with a fully constructed secondary library path.
The secondary library path is a transitional measure until we
can reorganize the system image so that we can use nativeLibraryRoot
for system paths as well (nativeLibraryRootRequiresIsa will then
be true for all packages except for legacy installs).
bug: 16013931
Change-Id: I5ae090334b377b9e087aecf40075fab81b20b132
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 8a4c9721a9e09d20c63381c13fa29bd9f7cbc3e3 |
|
16-Jun-2014 |
Jeff Sharkey <jsharkey@android.com> |
Plumb split APKs into public API.
Introduces new ApplicationInfo fields to surface zero or more split
APKs for an application. Splice these APKs into both the class
loader and resource system. Cleaner building of these paths.
Run dexopt() on all split APKs found after a parse, and populate
into ApplicationInfo.
Change-Id: I4a376bf4492d84ea95aafa866e106ea43a43e492
/frameworks/base/core/java/android/app/LoadedApk.java
|
| de898ff42912bd7ca1bfb099cd439562496765a4 |
|
30-Jan-2014 |
Adam Lesinski <adamlesinski@google.com> |
Shared library resource support
Shared libraries can now export resources for applications
to use.
Exporting resources works the same way the framework exports
resources, by defining the public symbols in res/values/public.xml.
Building a shared library requires aapt to be invoked with the
--shared-lib option. Shared libraries will be assigned a package
ID of 0x00 at build-time. At runtime, all loaded shared libraries
will be assigned a new package ID.
Currently, shared libraries should not import other shared libraries,
as those dependencies will not be loaded at runtime.
At runtime, reflection is used to update the package ID of resource
symbols in the shared library's R class file. The package name of
the R class file is assumed to be the same as the shared library's
package name declared in its manifest. This will be customizable in
a future commit.
See /tests/SharedLibrary/ for examples of a shared library and its
client.
Bug:12724178
Change-Id: I60c0cb8ab87849f8f8a1a13431562fe8603020a7
/frameworks/base/core/java/android/app/LoadedApk.java
|
| defd4a6b0448bf13606695eb086c77aa099684a2 |
|
11-Mar-2014 |
Jeff Brown <jeffbrown@google.com> |
Retain display when creating specialized contexts.
Fixed a bug that cause Context.createPackageContext() to discard
display information. Likewise also fixes issues where the
activity token, override configuration, user handle, and
restriction state might be discarded.
As part of this change, reworked how Contexts are created to make
initialization easier to understand and less error-prone.
The init() methods have been removed and most of the state is
now stored in final variables.
Bug: 12015587
Change-Id: If795851f1cd078bef889b76a52e00d9b3c06ab11
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 48d22323ce39f9aab003dce74456889b6414af55 |
|
31-Jan-2014 |
Mårten Kongstad <marten.kongstad@sonymobile.com> |
Runtime resource overlay, iteration 2
Support any number of overlay packages. Support any target package.
UPDATED PACKAGE MATCHING
------------------------
In Runtime resource overlay, iteration 1, only a single overlay package
was considered. Package matching was based on file paths:
/vendor/overlay/system/framework-res.apk corresponded to
/system/framework-res.apk. Introduce a more flexible matching scheme
where any package is an overlay package if its manifest includes
<overlay targetPackage="com.target.package"/>
For security reasons, an overlay package must fulfill certain criteria
to take effect: see below.
THE IDMAP TOOL AND IDMAP FILES
------------------------------
Idmap files are created by the 'idmap' binary; idmap files must be
present when loading packages. For the Android system, Zygote calls
'idmap' as part of the resource pre-loading. For application packages,
'idmap' is invoked via 'installd' during package installation (similar
to 'dexopt').
UPDATED FLOW
------------
The following is an outline of the start-up sequences for the Android
system and Android apps. Steps marked with '+' are introduced by this
commit.
Zygote initialization
Initial AssetManager object created
+ idmap --scan creates idmaps for overlays targeting 'android', \
stores list of overlays in /data/resource-cache/overlays.list
AssetManager caches framework-res.apk
+ AssetManager caches overlay packages listed in overlays.list
Android boot
New AssetManager's ResTable acquired
AssetManager re-uses cached framework-res.apk
+ AssetManager re-uses cached 'android' overlays (if any)
App boot
ActivityThread prepares AssetManager to load app.apk
+ ActivityThread prepares AssetManager to load app overlays (if any)
New AssetManager's ResTable acquired as per Android boot
SECURITY
--------
Overlay packages are required to be pre-loaded (in /vendor/overlay).
These packages are trusted by definition. A future iteration of runtime
resource overlay may add support for downloaded overlays, which would
likely require target and overlay signatures match for the overlay to
be trusted.
LOOKUP PRIORITY
---------------
During resource lookup, packages are sequentially queried to provide a
best match, given the constraints of the current configuration. If any
package provide a better match than what has been found so far, it
replaces the previous match. The target package is always queried last.
When loading a package with more than one overlay, the order in which
the overlays are added become significant if several packages overlay
the same resource.
Had downloaded overlays been supported, the install time could have been
used to determine the load order. Regardless, for pre-installed
overlays, the install time is randomly determined by the order in which
the Package Manager locates the packages during initial boot. To support
a well-defined order, pre-installed overlay packages are expected to
define an additional 'priority' attribute in their <overlay> tags:
<overlay targetPackage="com.target.package" priority="1234"/>
Pre-installed overlays are loaded in order of their priority attributes,
sorted in ascending order.
Assigning the same priority to several overlays targeting the same base
package leads to undefined behaviour. It is the responsibility of the
vendor to avoid this.
The following example shows the ResTable and PackageGroups after loading
an application and two overlays. The resource lookup framework will
query the packages in the order C, B, A.
+------+------+- -+------+------+
| 0x01 | | ... | | 0x7f |
+------+------+- -+------+------+
| |
"android" Target package A
|
Pre-installed overlay B (priority 1)
|
Pre-installed overlay C (priority 2)
Change-Id: If49c963149369b1957f7d2303b3dd27f669ed24e
/frameworks/base/core/java/android/app/LoadedApk.java
|
| add005cf94dcc815d29b54588c76fd87929075b3 |
|
18-Jul-2013 |
Dianne Hackborn <hackbod@google.com> |
Mmmmmmm... lovely, lovely ArrayMap.
And ArraySet, too.
Change-Id: I72ea28cbb2286b01b6e1be082f8e7ec17e99074e
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 88c0589969b17e66559cd2f132094cdaa0ee351d |
|
28-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Refactor ActivityThread cache - Baby step 1.
Introduce ResourcesManager and ResourcesKey as standalone classes.
Move DisplayMetrics and Resources HashMaps from ActivityThread to
ResourcesManager.
Change-Id: I20cc6c0dd1b74667354839e5ac9a660f4ee2d00d
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 48d0d1886731ff19ed3fb47a5997be5df0d1bba8 |
|
11-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Add activity token to display system.
First step in adding activity specific information to displays.
Replace CompatibilityInfoHolder with DisplayAdjustmentsHolder that
holds an activity token in addition to the CompatibilityInfo.
Change-Id: Ie113cd8dd9c62e0b5311204e039a4829096bea68
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 208d937b613a49ad136a0eb182de5bcd73b48def |
|
25-Feb-2013 |
Dianne Hackborn <hackbod@google.com> |
Better exceptions when LoadedApk fails.
Change-Id: Iba578c3872c6aeba3bf468735f06bd486d661454
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 20e809870d8ac1e5b848f2daf51b2272ef89bdfc |
|
01-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Add registering for explicit users.
New API to register as an explicit user, which allows you to
also select ALL to see broadcasts for all users.
New BroadcastReceiver API to find out which user the broadcast
was sent to.
Use this in app widget service to handle per-user package broadcasts
and boot completed broadcasts correctly.
Change-Id: Ibbe28993bd4aa93900c79e412026c27863019eb8
/frameworks/base/core/java/android/app/LoadedApk.java
|
| a492c3a7b2c18426fd0cb4d017eacbc368195dc5 |
|
24-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Initial draft of high-level multi-display APIs.
This patch introduces the ability to create a Context that
is bound to a Display. The context gets its configuration and
metrics from that display and is able to provide a WindowManager
that is bound to the display.
To make it easier to use, we also add a new kind of Dialog
called a Presentation. Presentation takes care of setting
up the context as needed and watches for significant changes
in the display configuration. If the display is removed,
then the presentation simply dismisses itself.
Change-Id: Idc54b4ec84b1ff91505cfb78910cf8cd09696d7d
/frameworks/base/core/java/android/app/LoadedApk.java
|
| f02b60aa4f367516f40cf3d60fffae0c6fe3e1b8 |
|
16-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Rename UserId to UserHandle.
This is the start of turning this into a formal public API.
Change-Id: I5786d2c320f1de41a06ed5d0f65adb68967287a0
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 756220bd1912535840388a6743830d2e59ad4964 |
|
15-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Add API to create new contexts with custom configurations.
This allows you to, say, make a Context whose configuration
is set to a different density than the actual density of the device.
The main API is Context.createConfigurationContext(). There is
also a new API on ContextThemeWrapper that allows you to apply
an override context before its resources are retrieved, which
addresses some feature requests from developers to be able to
customize the context their app is running in.
Change-Id: I88364986660088521e24b567e2fda22fb7042819
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 1ded0b1f6af65c2f95f8327f7f3df4cee1bf2346 |
|
26-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
Add traces for window manager and activity manager.
Change-Id: I525d762db328e4c597da27b6b56d9a808e199756
/frameworks/base/core/java/android/app/LoadedApk.java
|
| d893a890c92e174c1a4bf0075b0acc4749a0eaa8 |
|
02-Apr-2012 |
Brian Carlstrom <bdc@google.com> |
Add support for native library paths with instrumentation
(cherry picked from commit 8e658fd0415b3d6f44223c39a7e59a00cb0954aa)
Change-Id: Idb1e031d5deeea9305af8aacc17ae2d0d064dfc6
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 483f3b06ea84440a082e21b68ec2c2e54046f5a6 |
|
14-Mar-2012 |
Amith Yamasani <yamasani@google.com> |
Package restrictions per user
Packages can be enabled/disabled per user.
This requires maintaining stopped/launched states and
enabled / disabled components and packages per user.
Refactored pm.Settings and PackageSettingsBase to keep
track of states per user.
Migrated the stopped-packages.xml to users/<u>/package-restrictions.xml
Changed intent resolution to handle individual user restrictions.
Bunch of IPackageManager calls now have a userId argument.
Make AppWidgetService handle removals of packages.
Added some tests for pm.Settings and PackageManager.
Change-Id: Ia83b529e1df88dbcb3bd55ebfc952a6e9b20e861
/frameworks/base/core/java/android/app/LoadedApk.java
|
| d7026f1612a7c1e8cc9b484038fa99b7fc29cfd7 |
|
02-Mar-2012 |
Jeff Sharkey <jsharkey@android.com> |
Report leaked Context registrations to StrictMode.
When tearing down any leaked BroadcastReceiver or ServiceConnection
Context registrations, report through StrictMode.
Bug: 6084353
Change-Id: I5e78039299e2c9c1440cd1fd09317da78ffee82a
/frameworks/base/core/java/android/app/LoadedApk.java
|
| a0c283eac33dd2da72235751bbfa4f2d9898d5ea |
|
09-Feb-2012 |
Dianne Hackborn <hackbod@google.com> |
Add new feature for running services in "isolated" sandbox processes.
This reserves a range of uids (for each user) in which these processes
run. These uids are not associated with an application, so they
effectively run with no permissions. When a Service requests to
run in such a process through android:isolatedProcess="true", each
time it is brought up a new isolated process is started with its
own unique uid.
What we have so far gives us the basic infrastructure; more work
remains to further lock down what these uids have access to.
Change-Id: Ibfd27c75619cba61f528f46ede9113f98dc5f45b
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 742a67127366c376fdf188ff99ba30b27d3bf90c |
|
04-May-2011 |
Amith Yamasani <yamasani@google.com> |
Multi-user - 1st major checkin
Switching activity stacks
Cache ContentProvider per user
Long-press power to switch users (on phone)
Added ServiceMap for separating services by user
Launch PendingIntents on the correct user's uid
Fix task switching from Recents list
AppWidgetService is mostly working.
Commands added to pm and am to allow creating and switching profiles.
Change-Id: I15810e8cfbe50a04bd3323a7ef5a8ff4230870ed
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 5a6ef737edbf57577443ac056613afe6cb121519 |
|
11-Nov-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5595933: GREF leak due to race condition in...
...LoadedApk.ServiceDispatcher.connected , LoadedApk.forgetServiceDispatcher
Don't be stupid if we receive a new binding to a ServiceConnection after it
has already been unbound.
Change-Id: I85a49de97372bf9af55542a89031f0b7a2ac8fbb
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 9ecebbfbf768fd63e9a6c9a09c86d81c7737ee2d |
|
29-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Add mechanism for Parcel to not allow FDs to be written to it.
This is to help implement issue #5224703.
Change-Id: I026a5890495537d15b57fe61227a640aac806d46
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 5fd2169eabd77e6bfafaf456e58051a3bafb2bca |
|
07-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #4518815: Compatibility mode introduces compatibility regression...
...for Market App iRunner
There were a lot of serious issues with how we updated (or often didn't update)
the display and resource state when switching compatibility mode in conjunction
with restarting and updating application components. This addresses everything
I could find.
Unfortunately it does *not* fix this particular app. I am starting to think this
is just an issue in the app. This change does fix a number of other problems
I could repro, such as switching the compatibility mode of an IME.
Also a few changes here and there to get rid of $#*&^!! debug logs.
Change-Id: Ib15572eac9ec93b4b9966ddcbbc830ce9dec1317
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 2f0b17573d4324832f7a20402a3d2b5920bc4866 |
|
01-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #4502672: Wrong xml resources used for homescreen widgets.
There was a race in the system process between applying the initial
configuration and executing code in higher-level system services
like the app widget service that relies on the config. For some
reason it starting showing up more after my code changes; it should
now be completely fixed.
Also fix the activity starting window to run in compatibility mode
if its application is going to be in compatibility mode.
And some various cleanup and small fixes.
Change-Id: I0566933bf1bbb4259c1d99a60c0a3c19af1542e5
/frameworks/base/core/java/android/app/LoadedApk.java
|
| e2515eebf42c763c0a2d9f873a153711778cfc17 |
|
28-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
Better compat mode part one: start scaling windows.
First step of improving app screen size compatibility mode. When
running in compat mode, an application's windows are scaled up on
the screen rather than being small with 1:1 pixels.
Currently we scale the application to fill the entire screen, so
don't use an even pixel scaling. Though this may have some
negative impact on the appearance (it looks okay to me), it has a
big benefit of allowing us to now treat these apps as normal
full-screens apps and do the normal transition animations as you
move in and out and around in them.
This introduces fun stuff in the input system to take care of
modifying pointer coordinates to account for the app window
surface scaling. The input dispatcher is told about the scale
that is being applied to each window and, when there is one,
adjusts pointer events appropriately as they are being sent
to the transport.
Also modified is CompatibilityInfo, which has been greatly
simplified to not be so insane and incomprehendible. It is
now simple -- when constructed it determines if the given app
is compatible with the current screen size and density, and
that is that.
There are new APIs on ActivityManagerService to put applications
that we would traditionally consider compatible with larger screens
in compatibility mode. This is the start of a facility to have
a UI affordance for a user to switch apps in and out of
compatibility.
To test switching of modes, there is a new variation of the "am"
command to do this: am screen-compat [on|off] [package]
This mode switching has the fundamentals of restarting activities
when it is changed, though the state still needs to be persisted
and the overall mode switch cleaned up.
For the few small apps I have tested, things mostly seem to be
working well. I know of one problem with the text selection
handles being drawn at the wrong position because at some point
the window offset is being scaled incorrectly. There are
probably other similar issues around the interaction between
two windows because the different window coordinate spaces are
done in a hacky way instead of being formally integrated into
the window manager layout process.
Change-Id: Ie038e3746b448135117bd860859d74e360938557
/frameworks/base/core/java/android/app/LoadedApk.java
|
| c2d9c8e20bea92bd8c1bd0954b0a393c1bb8fec0 |
|
25-Jan-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3385054: HRI24 never enters suspend (LP0) - IKXEVEREST-3439
Um. My fix for calling onReceive() even after a receiver is
unregistered actually made it so onReceive() is never called for
the result receiver of a broadcast.
Change-Id: I30efe05d8fdec6fee4222b7d797f2b303073dbcc
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 89ba6750e5310c4da51786bd7eb559a43cab3982 |
|
24-Jan-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3215261: NPE in WiFi Settings
And also fix #3343369: EGL_BAD_DISPLAY and/or broadcast intent
TIME_SET before boot completion
And a few more tweaks to animations to keep the wallpaper displayed
when needed.
And make more use of the drag and drop "rotation disabled" thing to
also use it while animating the screen rotation, since if we try to
start a new rotation while doing the animation we end up with a mess.
Change-Id: I373af305a6e23a92835abed96229a83e173f67ce
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 624d50f00dc3d672d676a2fbb405c61dfc875b28 |
|
09-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Don't warn on reading from disk during initial class loading.
I'm going through the stacks that I filter out from the StrictMode
reports and making sure the devices don't upload them to begin with
when they're obviously legit and unavoidable.
Change-Id: If87b3182b12140f5ddbe52fed059b592b2cc178c
/frameworks/base/core/java/android/app/LoadedApk.java
|
| e829fef63957a23b61cdb01bb692a17a041ff2dc |
|
27-Oct-2010 |
Dianne Hackborn <hackbod@google.com> |
Add facility for broadcasts receives to do work asynchronously.
You can now call goAsync() and move your work to a background thread.
If you are that kind of receiver. You weirdo.
Also allows SharedPreferences.apply() to be committed off the main
thread after returning from onReceive().
Change-Id: I27f975910e28f230ababcaeb551eb9a78ec4fc76
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 85387d7ba36e56b291cbde87acb5a5b2200fe01c |
|
26-Aug-2010 |
Kenny Root <kroot@google.com> |
Allow native shared libraries in ASEC containers
This change moves the native library handling earlier in the package
installation process so that it may be inserted into ASEC containers
before they are finalized in the DefaultContainerService.
Note that native libraries on SD card requires that vold mount ASEC
containers without the "noexec" flag on the mount point.
Change-Id: Ib34b1886bf6f94b99bb7b3781db6e9b5a58807ba
/frameworks/base/core/java/android/app/LoadedApk.java
|
| 01e4cfc47d0a2c7e7ab383d2fb23224ec52c0301 |
|
25-Jun-2010 |
Dianne Hackborn <hackbod@google.com> |
Some ActivityThread/ActivityManager cleanup.
- Move PackageInfo out of ActivityThread, renaming to LoadedApk.
- Rename some of the other PacakgeInfo inner classes to better
represent what they are.
- Rename HistoryRecord to ActivityRecord.
- Introduce AppGlobals, to eventually let ActivityThread become
package scoped.
Change-Id: Ib714c54ceb3cdbb525dce3db9505f31042e88cf0
/frameworks/base/core/java/android/app/LoadedApk.java
|