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.
Clients can check the property to determine lock/unlock status and thus
unlock the modem before trying to connect if required.
Bits of the patch by dcbw (see the bug).
Like UMTS vs. GSM, EVDO and 1x are separate networks and technologies
and have separate registration state. You can even be roaming on
EVDO while in your home 1x network. Handle that.
Previously, a few operations (like disable) could trigger a modem
flash in parallel with another flash. That's wrong, don't allow
that. At the same time, add in finer-grained error checking on
serial port speed operations, and fix a GSM generic bug that would
send the POWER_UP string on disable.
