There are now some new trim memory levels that are sent to
non-background applications as RAM becomes low.
There is a new API for an application to retrieve information
about memory trimming and such on demand.
Fixed various checks against the memory trim level to be
robust (not compare against exact values).
Change-Id: Ifd1c6151124350168aef20a94e517166fd2e03eb
Add Closeable to ParcelFileDescriptor, and always close any incoming
PFDs when dumping.
Bug: 6106309
Change-Id: I25b465692d5e1da0a5980a307cb48a058bc2bca7
When tearing down any leaked BroadcastReceiver or ServiceConnection
Context registrations, report through StrictMode.
Bug: 6084353
Change-Id: I5e78039299e2c9c1440cd1fd09317da78ffee82a
Add SQLiteDatabase.deleteDatabase to delete a database and all
of its auxiliary files.
This method is also used by Context.deleteDatabase and resolves issues
where auxiliary files would get left behind.
Bug: 5972489
Change-Id: I3633b9b4978972a1d240ac0a9861420ecf989149
Allow disk access during application and provider setup. This could
block processing ordered broadcasts, but later processing would
probably end up doing the same disk access.
Bug: 6083825
Change-Id: I80f383063cedba2b099c78465134faa811e898d8
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
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
Some changes in AppWidgetService were interfering with widget permissions.
Added some hidden methods in Context to communicate the requesting user
information instead of using the calling uid.
Bug: 6019296
Change-Id: I5e519fd3fbbfa5b3fcc5c297b729c671dac8e7c7
1. Added methods to the ActivityManagerService remote interface
that allow accessing content providers outside of an application.
These methods are guarded by an internal signature protected
permission which is given to the shell user. This enables a
shell program to access content providers.
2. Implemented a shell command that takes as input as standart
fagls with values and manipulates content via the content provider
mechanism.
Change-Id: I2943f8b59fbab33eb623458fa01ea61a077b9845
- Allow each user to have their own wallpaper (live or static).
- Migrate old wallpaper on upgrade.
- Update SystemBackupAgent to backup/restore from primary user's
new wallpaper directory.
Reduce dependency on Binder.getOrigCallingUser() by passing the
userId for bindService.
Change-Id: I19c8c3296d3d2efa7f28f951d4b84407489e2166
SerialManager: provides access to serial ports
SerialPort: for reading and writing data to and from serial ports
IO with both array based and direct ByteBuffers is supported.
Accessing serial ports requires android.permission.SERIAL_PORT permission
Each platform must configure list of supported serial ports in the
config_serialPorts resource overlay
(this is needed to prevent apps from accidentally accessing the bluetooth
or other system UARTs).
In addition, the platform uevent.rc file must set the owner to the
/dev/tty* files to "system" so the framework can access the port.
Signed-off-by: Mike Lockwood <lockwood@android.com>
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
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
Deleted a bunch of dead / useless code.
Raised number of logged operations in dumpsys dbinfo to 20.
Change-Id: I88344ff57a978f200c1f0172141d91e430caa1a9
The documentation is now consistent with the current UI guidelines
for handling notifications, and includes complete sample code showing
the correct way to do this.
Change-Id: I68f0afc62c2af164c3205535e62093679e2a256a
