ACTION_TAG_DISCOVERED is a start activity intent, not a broadcast intent, so
its presence in this list is redundant.
Change-Id: I05419ec9c4471b7b11c9ae50a02e5ac3d9e572d2
We are leaving enough API so that you can see when any Tag is discovered,
get its ID, and get its NDEF messages.
But for advanced use - creating tag connections and writing messages - we have
2 problems. Firstly a lot of the code is untested
(RawTagConnection.transceive()), or in some cases known not to work
(NdefTagConnection.write()). Secondly, there is still debate about how to
best expose information about Tags.
The set of data/methods exposed for a Tag changes completely depending on the
tag technology. There may be multiple sets of technology implemented in a
single tag. Tag A may have technology X and Y, Tag B may have technology Y
and Z. Furthermore, some NFC controllers will be not be able to use all
technologies, and so Android Device 1 may see technology X and Y on Tag A but
Android device 2 may only see technology X. So we have a pretty challenging
set of constraints to work under, and we are not convinced the current Tag and
NdefTag class is the best approach going forwards.
The Tag application should be able to remain unbundled, since it just needs to
get incoming NDEF Messages.
Change-Id: Ic09f094f33794e10f8d730fffe011c9a5957e0ac
Signed-off-by: Nick Pelly <npelly@google.com>
The initial (vendor) implementation had 4 perms, replace with 1.
Requires no permissions:
- Viewing UID, type of discovered tags and cards.
- Viewing the NDEF message contents of NDEF formatted tags and cards.
Requires android.permission.NFC
- Get/Set the local tag "MyTag"
- Creating or using a RawTagConnection (transceive())
- Creating or using a NdefTagConnection (write()/read())
Change-Id: I1b585c7d91738bed6261277061a48cf7c939482a
Signed-off-by: Nick Pelly <npelly@google.com>
3094621: add "wipe sd card" option to factory data reset
3094609: collapse unmount/format into one command
Also since we have decided that it is important to consider
the Crespo storage as internal storage, DevicePolicyManager
gets a new API to be able to wipe it. (No big deal, since
all of the work for this is now done in the implementation
of the new UI.)
Change-Id: I32a77c410f710a87dcdcbf6586c09bd2e48a8807
- Add the second half of the new NFC API: NfcAdapter, Tag, NdefTag,
RawTagConnection, NdefTagConnection.
- Add implementations for all of the new NFC API.
Change-Id: I8da9fd1d2971ed2c8b76f2a93f207fa9e305b0f6
Signed-off-by: Nick Pelly <npelly@google.com>
The new class provides static variables for creating an intent to broadcast to
applications implementing the alarm clock. A new permission has been added and
applications are recommended to require this permission if accepting the set
alarm broadcast.
Change-Id: I7b1014acdc54371cbda19bcf9b5c395b647aa413
The logs inevitably contain PII, so now we are making that clear in user
strings and developer docs. Moving DUMP and READ_LOGS into the PERSONAL_INFO
group.
Note that this means we need string translations.
Change-Id: I1b5bf9d2d827ab1a31dedbdb30d0906a87c26a32
This permission isn't needed right now, since there aren't actually any
public APIs that require it. (There are a few calls in the ITelephony
interface that do, but they're all hidden.)
Since there's no good reason for 3rd party apps to declare it, let's
mark it signatureOrSystem for now. We can bring it back -- and probably
split it apart into multiple finer-grained permissions -- once we
finally expose full telephony APIs to 3rd party apps (see bug 1043005).
Bug: 2989096
Change-Id: Idf898d5e12d648a959f622cd815e75597195aa82
This fixes a problem where applications could ask the location
manager to do very heavy-weight things (like... say... update
location every minute), which would get accounted against the
system instead of the application because ultimately it is the
system making the heavy calls (wake locks, etc).
To solve this, we introduce a new class WorkSource representing
the source of some work. Wake locks and Wifi locks allow you
to set the source to use (but only if you are system code and thus
can get the permission to do so), which is what will be reported
to the battery stats until the actual caller.
For the initial implementation, the location manager keeps track
of all clients requesting periodic updates, and tells its providers
about them as a WorkSource param when setting their min update time.
The network location provider uses this to set the source on the
wake and wifi locks it acquires, when doing work because of the
update period.
This should also be used elsewhere, such as in the GPS provider,
but this is a good start.
Change-Id: I2b6ffafad9e90ecf15d7c502e2db675fd52ae3cf
Fix for bug 2382830: new incoming SMS should not be rejected when
running low on internal phone storage.
Testing revealed that the /data partition should have at least 256 KiB
available in order to prevent random app crashes (including system apps)
due to SQLite transaction failures. With 256 KiB free, the device should
safely boot without storage full errors. This takes into account the
36-40 KiB that the YAFFS2 filesystem reports as available even after
the partition has been completely filled. I've set the default full
threshold to 1 MiB to provide a generous safety margin.
For this bug, I changed the DeviceStorageMonitorService demon to send
two new hidden notifications for device storage "full" and "not full",
when the free space falls below the full threshold (default 1 MiB,
but configurable as a system setting), in addition to the existing
storage low/okay notifications sent when the storage crosses the threshold
of 90% full (also configurable).
The SMS code was changed to use these new notifications so that it can
accept messages until the data partition has been filled to the maximum
safe capacity rather than stopping when it hits 90% full. There should
be no negative impact on battery life because the additional check in
the storage polling service should be offset by an optimization to cache
the free threshold values which were previously being computed every time
through the loop.
While testing this change, I discovered that SMSDispatcher was being
instantiated twice, the first time in GSMPhone/CDMAPhone, and the second
time in SimSmsInterfaceManager / RuimSmsInterfaceManager. Changed the code
to pass the original SMSDispatcher to the Sim/RuimSmsInterfaceManager
constructor.
Change-Id: Ie0c6d05294778ab6ee42e0fa01313af96d824c77
Note that WRITE_OWNER_DATA and READ_OWNER_DATA don't actually appear
to be associated with anything or used by anyone, so they are just
deleted.
Also deprecate the activity API to go in the foreground. I didn't
realize that was released in the SDK. It needs to go away.
Change-Id: I96f53702c2c79e4999b6b2c498abb770bd27e03a
We now broadcast Usb.ACTION_USB_CONNECTED and Usb.ACTION_USB_DISCONNECTED
when USB is connected or disconnected.
The ACTION_USB_CONNECTED extras indicate the enabled/disabled state of
all USB functions.
Change-Id: I11495d039429dbe22bd738067296e39ae415befa
Signed-off-by: Mike Lockwood <lockwood@android.com>
Adds permission android.permission.ACCESS_USB.
This is a partial cherry pick of a change from master.
It adds the permission, but not the support for associating it
the AID_USB group.
Change-Id: If5816721a4fc88bf444141a7b717da65ea37d5f4
Signed-off-by: Mike Lockwood <lockwood@android.com>
Only one can be running at a time, their process can not be killed,
and a notification is posted while it is running.
Change-Id: I843015723947e0c934ae63a1aeee139327c0bc01
I can't believe I let this slip through. And in the SDK no less. :(
The APIs for setting preferred activities will now throw a security
exception when used. This may break some apps, we'll see how it
goes. If it is too bad we can just make these log and not throw
anything, but I would much prefer they throw an exception.
Change-Id: I3aed434750eef8b202aa9d5bd774a0121be521c6
Extract all UI behavior from dock observer and ACTION_DOCK_EVENT.
Also introduce a desk type to go along with the car type all through
the resource system, since we now need to have corresponding high-level
broadcasts for desk dock mode. As part of that I also reworked some
of the logic for switching modes to all funnel through a single
update() call that looks all of the current state to decide what to
do next, and fixed various locking issues.
In addition I found there were bugs in the configuration change
handling causing us to only switch into the car mode config and
then never get out of it. Unfortunately now that we are actually
changing the configuration for each mode change, the transitions
between them are really crummy as we restart all kinds of
activities. :(
Any package can now participate in backup/restore, without requiring any
manifest-declared permission. *Control* of the backup manager is still
guarded by the BACKUP permission, which is signatureOrSystem.
Change-Id: I116fcfcd4cd255e3c976330da1c4dea7d4faae9d
The device mode is now called ui mode. Furthermore is the order of
precedence for the resources now in such a way that the ui mode needs
to be specified after the orientation and before the density.
The ui mode can be set, like it is done for the locale, as follows:
IActivityManager am = ActivityManagerNative.getDefault();
Configuration config = am.getConfiguration();
config.uiMode = Configuration.UI_MODE_TYPE_CAR | Configuration.UI_MODE_NIGHT_ANY;
am.updateConfiguration(config);
To allow users to disable the car mode and set the night mode the IUiModeManager
interface is used.
The automatic night mode switching will be added in a separate change.
events (and in one case, a DropBox entry).
Add a simple intent that triggers master-clear (and toggle EFS), given the
right permissions.
Bug: 2264596
Bug: 2350452
Bug: 2264596
Still TODO: patch into forthcoming callbacks from
MountService so the USB storage activity always shows the
correct state of the device. (Right now it only refreshes
its display onResume.)
Bug: 2299129
Add new remote interface to do temporary copies. The new
remote stub handling is done on mHandler thread and doesn't need locking
for now.
Add new InstallArgs class and subclasses to isolate cases for installation.
Move resource deletion for failed installs/upgrades to later on in installation
cycle.
Fix code path for forward locked apps when using scanPackageLI
TODO's
Fix installation paths to completely use InstallArgs based design later on.
Get rid of using flags in various install/uninstall code paths.
Ideally InstallArgs should be created using these flags and used in the
rest of the code.
Function renames.
Revisit mount api's.
This adds new DevicAdmin, DevicePolicyManager, and DeviceAdminInfo classes.
See the java docs for each on documentation on them. Basically: a DeviceAdmin
is what you derive from to administer a device; DevicePolicyManager is what you
use to apply and check your policy requirements and perform other administration
tasks.
All of the permissions in data/etc/platform.xml are defined in
core/res/AndroidManifest.xml, except for ACCESS_CACHE_FILESYSTEM. Add
it.
Change-Id: If7906bc0007484cc21196fb1c0593b967fd79920
The ActivityManager.restartPackage() API is now deprecated, and no longer
allows applications to mess up the state of other applications. This was
being abused by task killers, causing users to think their other applications
had bugs.
A new API is introduced for task killers,
ActivityManager.killBackgroundProcesses(), which allows these applications
to kill processes but only the same amount that the out of memory
killer does, thus causing no permanent damage. The old restartPackage()
API is now a wrapper for calling this new API.
There is also a new private forceStopPackage() API that is used for the
system's force stop UI which does what the old restartPackage() API did.
and add a note to the CAMERA permission stating that it enables
the <uses-feature> for camera.
This is an incrimental update for the 2.0.1 docs. More changes
to come for the 2.1 docs to include more features
