Telephony: Add support for NETWORK_TYPE_GSM

Add support for NETWORK_TYPE_GSM in TelephonyManager and
corresponding mapping in ServicState.java so that when
application queries getVoiceNetworkType() and currently
camped rat is GSM, they get network mode as GSM instead
of network mode unknown.

Change-Id: I5e971c625532696776b9555ad8cfd85eba4fc423
CRs-Fixed: 526435
(cherry picked from commit 3e01fcec13725955f0ca3fb20730ff21f4edc128)
(cherry picked from commit c70f5687965908cd585e52901cf6cd88bd405140)
(cherry picked from commit 8e3c2300729ecb3cd3e6b640b0174f49e2189f0c)
Skip broadcasting to a receiver if the receiver seems to be dead

If an application that has a broadcast receiver is killed
during broadcasting, thread variable of ProcessRecord becomes null
so that IIntentReceiver#performReceive() is called
in BroadcastQueue#performReceiveLocked(). But if binder driver has not
noticed the death of the application yet, it can't throw
DeadObjectException. After that, binder driver notices. But it can't
notify DeadObjectException to the caller because performReceive() is
async call. So broadcasting keeps on waiting for finishing
performReceive() until timeout.

This change checks the death of the application before calling
performReceive() and skips broadcasting to the receiver
if the application has already died.

Change-Id: Ifa02b8b1a7e7b6fd314de90fedff5b7a5326825d
Perform NTP lookup at Mobile data connections

If NITZ isn't supported by the current carrier the Android framework
relies instead on a remote NTP server to set the system clock. The
NetworkTimeUpdateService class polls for NTP time during the first 4
minutes after boot, failing to get NTP time within these minutes will
increase the polling interval to 24 hours. Hence, if a data connection
isn't activated directly after boot it can take a long time for the
system clock to be updated. To prevent this situation, NTP lookup is
scheduled as soon as a Mobile data connection has been established.

Change-Id: I046e0330147e7ace4b720a7e70f9d5047d42cfe6
Insufficient ProcessRecord cleanup when persistent process is killed

When persistent process with Service restarts, ActivityManagerService
does not reset ProcessRecord#hasClientActivites to false
(because ProcessRecord of persistent process is continued using
after killing).

It disturbs updating LRU list in ActivityManagerService, and then,
when new process calls ActivityManagerProxy#publishContentProviders,
SecurityException happens because of no entry in the list.

Bug: 13517358

Change-Id: I46b064f71a4f7025ade1bf117801352a7ab22e6a
Smoother Upload and Download Animation

renamed stuff version ps2: renamed download_done drawable
renamed stuff version ps3: renamed upload done to match

Change-Id: I6e6409cc85ad951019dbac10156d4aed92f4c5bc
Signed-off-by: DHOMD <DHO@dho.im>
Speed up transitions by lowering durations