This can be used by a connection manager to decide to respond in a different way
to certain kinds of disconnects (e.g. intentional versus unintentional versus
suspension).
TEST=None
This change introduces no additional code, so testing it in isolation is not
possible.
BUG=chromium-os:6744
Change-Id: Ie371e20ec7a003333eba013af3ad61c0e494a4ad
Signed-Off-By: Elly Jones <ellyjones@chromium.org>
Review URL: http://codereview.chromium.org/3413011
(cherry picked from commit 29a9674b818fd64c19bad84f526f6fa68edec174)
BUG=6885
TEST=inspect mm-modem.h, build cromo et al against new mm-modem.h
Change-Id: Id8c849b6cffbadb9d5d2aa4109257eb747cf9bb5
Review URL: http://codereview.chromium.org/3616004
(cherry picked from commit 3a50b8c28d155060ce035a1c6d5eadf3d91297a5)
Which requires that we turn it into a GInterface that MMModemBase
can implement, because dbus-glib does not allow attaching more
than one introspection glue structure to an object at a time.
Also implement the standard D-Bus properties changed signal.
An obfuscated SimIdentifier that may be available before the PIN has
been entered, for use in auto-unlocking a device. If this value is
present, it should be used in preference to DeviceIdentifier as it
is SIM-specific like the PIN code.
This is computed before any PIN is entered, and thus before we can
usually get IMEI or MEID/ESN out of the device in many cases. It's
therefore not the same as EquipmentIdentifier.
This is intended to be used by UI programs for matching devices with
PIN numbers for automatic unlocking. While the PIN number is actually
*SIM* specific, no modems allow access to the IMSI before the PIN is
entered, and thus we cannot actually match the PIN with the SIM. The
device ID is the next best thing we can use and should allow auto
unlocking in most cases.
Instead of trying to stuff everything into the mode bitfield it
turns out it's just easier, clearer, and simpler to use different
values for each of the following:
1) the device's supported access technologies and allowed modes
2) the device's current access technology
3) the device's allowed mode preference
Since none of the AccessTechnology or AllowedMode stuff has hit a
release yet, let's make sure we're doing it the right way early on.
It's just easier this way. It makes little sense to allow
selecting mode combinations for anything other than
(HSDPA | HSUPA). Most radios don't allow fine-grained control
of the different technologies within each 2G or 3G class anyway
thus combinations like (GPRS | UMTS) are pointless since the
device wouldn't be able to use GPRS but not use EDGE.
This adds split properties and functions for the allowed modes and the
current access technology used by the device when connected to the
mobile network.
MM hadn't implemented it yet, but Wader already implemented an earlier
version that didn't use a bitfield but an enum. Unfortunately the
network mode stuff doesn't allow for distinguishing between the device's
mode preference and the current access technology. So deprecate the
current network mode stuff in the API in preparation for improved API.
Since D-Bus signals cannot by nature be restricted to authenticated
clients (unless using private D-Bus connections) we can handle the
security a bit differently here. Since the Enable() call can be
authenticated, we'll trust the client to say whether higher
security should be used by disallowing location update signals. This
does mean the client will have to poll for location updates, but at
least then clients requesting location information can be
authenticated.
