A usecase is to use hipri to keep alive 3g connections when wifi
is about to be brought up. They are the same network, so don't
reset unless both are down.
Change-Id: I8dabc42f315943b28ea34721793b0ee330c07bf6
Adding DownloadManager.ERROR_CANNOT_RESUME for when we can't resume an
interrupted download (because the server didn't provide an ETag or
doesn't support range requests), as well as the necessary private
status code in Downloads.Impl.
Change-Id: I5a66f1e1964198552ab2216aa6d3cc0db2254e21
Must clean up default route if a default 3g connection is replaced
by a non-default (ie, mms) connection on teh same interface.
Also stop mucking with all connections dns and routes - do it only
for the connection that has changed.
bug:2865974
Change-Id: Ifdf49080fa0413a4d826813706c809975a562dfa
* Additions to DownloadManager to support control of broadcast intents, allowed network types, and roaming control. This includes new constants and added implementation.
* New DB columns to hold connectivity flags and one to indicate whether the download was initiated through the public API; this is used to change behavior related to broadcast intents and connectivity controls.
Change-Id: I2e8e4ce92cde7889a0f24dc43b86c596c73c0eaa
* constants for new DB table, keys for including headers in a
DownloadProvider.insert() call, and new URIs for retrieving headers
* support in DownloadManager to pass headers to the provider
Merge commit '468c82e4be0630de04a50d88602cd8c6bc745962' into gingerbread
* commit '468c82e4be0630de04a50d88602cd8c6bc745962':
Skip hostname verification when using insecure factory
First, in the download manager public API, I'm changing
COLUMN_REQUESTED_TIMESTAMP to COLUMN_LAST_MODIFIED_TIMESTAMP, a field
that already exists in the download manager. Upon inspection of
existing users of this field, it looks like there are some good use
cases -- for instance, looking at when a download completed. And if
I'm exposing that timestamp, there's no need to also expose the
requested timestamp.
Second, this change includes support for file URI destinations:
* add DESTINATION_FILE_URI for use by the DownloadManager wrapper
* make DownloadManager use it appropriately
The backend support is in a separate change (since it's in a separate
project).
Also fixing a bug with file URI construction when DownloadManager
fills in COLUMN_LOCAL_URI.
Change-Id: I5bb93a222cd23215c2a03ed9f68d7f140454f7f2
The implementation is in android.net.DownloadManager, which is
obtained through Context.getSystemService(). Right now this class
acts as a simple wrapper on top of the existing DownloadProvider,
exposing a simple interface to a subset of DownloadProvider's
functionality. There are several TODOs for features that require
changes to the underlying download manager implementation.
Change-Id: I2f26e51b60b6e82af8478ac7ccd895667df095b6
If the factory was obtained by calling getInsecure(), calls to
createSocket() should skip hostname verification (along with all of the
other skipped safety checks.)
This change slightly relaxes the too-strict checking that was introduced
in change 7fc93c36ae.
Bug: 2834174
Change-Id: Iab7ef861ad0ca727f82ee8cdb78b89b9e835740d
Merge commit 'd581484ef8fac80c15ebf652e66f918374df5109' into gingerbread
* commit 'd581484ef8fac80c15ebf652e66f918374df5109':
Verify hostname where possible, and clarify where not.
we can continue the interrupted request to support
streaming the content even with a brief disconnection.
Note: we don't update the headers for partial content
as the headers we care should not be updated. See
a list in chromium/net/http/http_response_headers.cc.
We currently also don't support cache for partial content.
Fix http://b/issue?id=2616477
Old calc was off by 2x and was affected by the user-settable system clock. The error
came because it was calculating the offset between our clock and the NTP clock and the algebra
had two factors of the offset instead of the desired 1.
bug:2600010
Change-Id: I0856091d32b50e6909e4889fb98df819e0aeabbe
Added ContentObserver to watch relevant Secure Settings.
Also added new policy-change broadcast to let settings know.
Lastly reorged things a bit so that all of our broadcasts are sent at boot so the sticky ones
are populated.
bug:2576057
Change-Id: Ie11ffb057de9c801a5088612cd464ea062f3a666
Also change phone's ConnectionStateTrackers to use it directly,
rather than through the INetStat binder interface.
Bug: 2578938
Change-Id: I8858e2609cbec3be845a0ce5178cb03f67e01b41
A key bit of code was lost in change 38/25338/5 (2009/09/17 change
of RequestQueue.java) which caused us to not pick up proxy settings.
Putting it back.
bug:2364475
Change-Id: I1e79858f64d8e793a966ef8e6f7a0d3f2a02251f
It's the base class for some public classes, so it needs to be public
as well according to the CTS rules.
Bug: 2537352
Change-Id: Ie2f8141d56907e1d0f4a3a040204b7b14d1fd79a
buffer is full. In that case, WebCore instructs the laoder to pause loading to give the plugin a chance to clear it's buffer and
continue.
Requires an external/webkit change.
Change-Id: Iec96a6325d92e979cbdc53289c2a20cad940ded2
Two more cases of "View certificate" problems like b/2511635
One problem is that if there are multiple resources downloaded for a
page. In that case the mCertificate shown ends up being from the last
loaded resource instead of the main resource of the page. The solution
is to only set the certificate if the LoadListener is the
mIsMainResourceLoader as well as the mIsMainPageLoader.
A larger problem was the fact that the EventHandler.certificate
interface method (in this case the LoadListener.certificate
implementation) once per https connection instead of once per request
as was documented. That meant if an https connection was reused (which
happens frequently on login pages such as
https://www.google.com/accounts which use the POST -> redirect -> GET
idiom to avoid POST data page refresh warnings) then later pages never
were associated with an SslCertificate.
The solution was to change EventHandler.certificate to be called once
per request, specifcally before the request. This means we no longer
call the certificate method in the handleSslErrorRequest case, which
is okay because it includes the SslCertificate within the SslError and
that is what the BrowserActivity expects.
Change-Id: Icbd9bd98c89db82762d1d06de85e1cde2470300d
If the phone comes up in airplane mode you and you turn it off,
you can currently end with both mobile and wifi turned on.
bug:2524413
Change-Id: I7a841c955be9038109d0b220070406a3fbd3e8e9
Bug shows we lost contact with the phone service. We used to leave the notion of enabled alone
in this case, but that can lead to being out of sync (the mobile data connection may be
alive or come alive but if we think it is dead we ignore it). Changing our
notion of its enabled-ness to 'enabled' means we'll pay attention to its messages going forward,
and since after a reboot it starts enabled we'll actually be in sync.
bug:2323057
Change-Id: Ie080b50d764e6879e712507aceb68f585f12f94e
A recent change made the HiPri MobileDataStateTracker listen for notifications
about the default connection (which HiPri shadows). Local code was sending
itself a notification using the old HiPri badging instead of the new Default
badging and those notifications where therefore ignored.
Manifested itself on HiPri connections when we were already on 3g.
See change 42422 on master platform/frameworks/base for the change this is completing.
Change-Id: I375026048724d0035297287c61c6c2f58d4e0294
