Move operation - no functional tests. Only editorial changes:
- Remove (no longer) necessary import statements
- Removed reference to a constant sitting on the service side.
Replaced with locally defined constant.
(cherry pick of commit 7ba5ad3c53dac62e56cd12dbe2054ce8374b6b92)
Bug: 32954930
Test: unit-tests pass
Change-Id: Ibe463fa73c27fc67996460eb91ea0222437927a6
- Extract common part of MDNSFilterPlugin to common utils, MDNSFilteredDiscovery.java (other vendors can use it too)
- Refactor Samsung Print Recomendation Plugin to use MDNSFilteredDiscovery.java
- Add Mopria devices detection to Samsung Print Recomendation Plugin
*Samsung Print Service Plugin supports Mopria printers since v3.00.161011.
Test: Tested manually. Test app was developed to make sure that Samsung Print Recommendation plugin can find both Samsung and Mopria devices. Additionally MDNSFilterPlugin was tested on HP printers.
Change-Id: Idc0d311171495f879564336370a86f7a8890378b
setDataEnabled requires MODIFY_PHONE_STATE or carrier privileges.
getDataEnabled will work with any of the above or
ACCESS_NETWORK_STATE.
Merged-In: I2d5a9df2e55f3f7be1729abefe137c00ae1d6c4e
Test: Exercised APIs from test app, updated and executed CTS tests
Change-Id: I2d5a9df2e55f3f7be1729abefe137c00ae1d6c4e
Fixes: 32644451
When advertiser is not started because too many advertisers are
registered, return proper error code.
Bug: 30622771
Test: sl4a ConcurrentBleAdvertisingTest
Change-Id: I57384ff30132e9a7ee17dcf191ff89baa7abf1ef
Checked that android.test.runner had the same classes in as
before the change.
These classes are legacy 3.8.1 classes, they are not in 4.10 at
all. They appear to have been left here by accident. Looking at
the history it appears that at one time there were copies of
JUnit 3.8.1 junit.runner classes in frameworks and
external/junit. The classes here were upgraded to 4.10 but even
though these classes had been deleted immediately after 3.8.2
was released they were not removed, instead they appear to have
been reformatted as part of the upgrade. The external/junit
source was upgraded to 4.10 about two weeks later which seems to
have been done correctly. About three months after that the
classes here that were duplicates of those in external/junit
were removed from here leaving the legacy classes from 3.8.1.
I could not find any usages of these classes and they are not in
the public API so they can probably be removed altogether.
However, for now I will simply move them into external/junit as
described and remove them when upgrading JUnit there to 4.12.
Bug: 30188076
Test: Built android.test.runner and checkapi
Change-Id: I88687889315c041d999fe7e61b9652ac8406165c
Define some constants for early use in AOSP code.
Test: builds, boots, all common traffic tagged
Bug: 30943431
Change-Id: Ia58a8933bccfddbc027afb78c63ae65bd71ce562
- Move Handler to last position
- Peer ID changed from 'Object' -> opaque class
- Rename onMessageSent -> onMessageSendSucceeded
(cherry pick of commit 1fef08507aeb49bb2e4e7be4804a378ba2cf7770)
Bug: 31470256
Test: unit tests & integration (sl4a) tests pass
Change-Id: I5530d310e982ea16a63a5af1f704625fd24e436c
We want to create the classloader for the WebView in advance in the
zygote so that it can preload Java and native code for its children, but
the zygote can't talk to the package manager (so doesn't have a
PackageInfo for the APK) and also doesn't have an ActivityThread, so
constructing a LoadedApk is difficult.
Instead, we use the fact that ApplicationLoaders contains a
process-global cache of classloaders for APKs, and prepopulate a cache
entry without constructing a LoadedApk. This requires making
ApplicationLoaders public. To calculate the correct library paths from
the information the zygote has, we reuse the logic in LoadedApk (which
is already public, and just needs a small change to allow a null
ActivityThread when checking for instrumentation).
The other parameters for classloader creation (target SDK, bundled app,
etc) are hardcoded to usable values for the WebView's case. WebView
never needs to use any system libraries that aren't public so claiming
it's not bundled is fine even when that isn't actually true, and WebView
will always target the current platform API level.
Once the classloader is created, look up the factory class and call
preloadInZygote on it to give it a chance to preload the native library
and do other shared initialisation.
Bug: 21643067
Test: enable multiprocess WebView, examine librank output to see sharing
Change-Id: I696ead637e3f7382bcc58cfaf61eac5921862015