See build/soong/README.md for more information.
Note: tests/ImfTest/Android.mk causes conflict as it hasn't been yet
ported to internal master. Do it later.
Note: the conversion in the following directories has to be done in the
internal master first because of the conflicts:
* tests/ActivityManagerPerfTests
* tests/AppLaunch
* tests/AppLaunchWear
* tests/BackgroundDexOptServiceIntegrationTests
* tests/Camera2Tests/CameraToo
* tests/Camera2Tests/SmartCamera/SimpleCamera
* tests/Compatibility
* tests/Internal
* tests/RcsTests
* tests/ServiceCrashTest
* tests/UsbTests
Bug: 122332340
Test: treehugger
Change-Id: Ie17590c6a96aee5caa80d38092a3de5c1b6efe8d
This change sets LOCAL_SDK_VERSION for all packages where
this is possible without breaking the build, and
LOCAL_PRIVATE_PLATFORM_APIS := true otherwise.
Setting one of these two will be made required soon, and this
is a change in preparation for that. Not setting LOCAL_SDK_VERSION
makes the app implicitly depend on the bootclasspath, which is
often not required. This change effectively makes depending on
private apis opt-in rather than opt-out.
Test: make relevant packages
Bug: 73535841
Change-Id: Ibcffec873a693d1c792ca210fb597d2bf37e9068
Merged-In: I4233b9091d9066c4fa69f3d24aaf367ea500f760
Replace usages where the Long is immediately unboxed or thrown
away with Long.parseLong().
In TaskRecord.java, I also fixed up similar uses of
{Boolean,Integer}.valueOf()
Tested: built frameworks/base successfully.
Bug: 28289401
(cherry picked from commit 4bd017d6a5)
Change-Id: Icfa4708946e774f4a1bacf185c3fd11a7087017e
BUG: 17424511
Introduce an "isOverrideDeadlineExpired" which will allow clients
to know when they are being run due to an expiry.
Nb that we check deadline expiry by checking that the constraints on
the job are not satisfied at execution time. Really this is the same
thing, as a job will not be run without its constraints being met,
unless the job has expired.
Change-Id: I4b91e5b5eadccabd91296d5a5ca66b859dbfaf5c
Client can jobFinished() before getting a cancel msg.
1) Do better clean up of JobServiceContext after client jobFinished()
to remove superfluous MSG_CANCELs
2) When processing MSG_CANCEL check whether the context is still active
3) Do JobServiceContext cleanup before calling back to JobSchedulerService
Client can get a cancel msg even after calling jobFinished() (opposite to above)
1) explicitly check whether there are any MSG_CALLBACKs in the queue before
processing a MSG_CANCEL. If there are we can throw away the cancel.
Bug: 16547638
Change-Id: I90644586c7895a9ce97de752a5d657faf7f74b78
