Add alphabetic shortcuts to the menu in ActionBarUsage. This mirrors
what is already present in a similar support lib demo.
Bug: 31045453
Test: run com.example.android.apis.app.ActionBarUsage on a device
with keyboard shortcuts enabled (such as Chromebook). Action menu
items should display keyboard shortcuts.
Change-Id: I9e6b04df8e2a6cbc728cb60b3706d054521da7cb
In particular, we have an example of a foreground-service PendingIntent
triggered by a 15-second delayed alarm following a button click. This
is enough time to exercise use cases like swiping the app out of recents
before the alarm fires, therefore entering the "starting a fg service
when the app is not in a fg state" flows.
Bug: 73559697
Test: this is it
Change-Id: If57908ab852c7a0bfab7bb1da8eda0a47493fc6b
Bug: 72696928
Test: Install and open ApiDemos > App > Activity > Max Aspect Ratio > 1:1 / 16:9 / Any
Change-Id: Ie76c8c4babd6b4c281eec8ff977a0c02a868ee0e
ApiDemos has been using private APIs from telephony-common to
demonstrate the Mms feature. However, this is causing link-type check
warning because ApiDemos itself is built with SDK (LOCAL_SDK_VERSION is
set) but telephony-common isn't. As we are working on to promote the
warnings into errors, this warnings must be fixed.
Fixing the warning by copying the PDU classes from telephony-common, so
that there is no need to link to the library. Also the package name for
the copied classes are all changed in order to prevent the collision
with the same classes in telephony-common which is in the boot class
path.
Test: m -j ApiDemos is successful and does not show any link-type check
warning.
Change-Id: Ica508cd4daf3640e4f90fa26dd11dfd03867d717
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: I371bd0b43e66bcc4be1e26decb95c70519ac3342
The lib hasn't been built using SDK and thus has been causing link-type
check warning from SimpleJNI which is built using SDK. Since the warning
will turn into error soon, fixing the warning by correctly building the
lib with SDK.
Bug: 69899800
Test: m -j SimpleJNI is successful and does not show any link-type check
warning
Change-Id: I51edfe296c70ac99ac7698b5e06ec0e0c678945c
android.test.base/runner/mock libraries are shared libraries that are
built without SDK, but with framework interanl libraries (framework.jar,
etc). Apps or libs that are built with SDK (LOCAL_SDK_VERSION is set)
shouldn't use them, but instead the stubs version of the test framework
libraries, which are built using SDK.
This is because, the build system does not allow a module built with SDK
to depend on another module built without SDK. This has been
exceptionally allowed with warnings, but will soon be errors.
In order to prevent the expected build breakage, direct reference to the
shared libraries are all changed to the stubs libraries.
Note: no one has been using these shared libs statically. So, it is
guaranteed that they won't encounter a problem due to missing
<uses-library name="android.test.runner"/> even after this change.
Bug: 69899800
Test: m -j checkbuild
Change-Id: I7f25e0127c52c56adf288163a760f3dc9aee6586
The documentation for android.app.Service includes an example from
LocalServiceActivities.java. This example now better shows and
explains the distinction between binding and connecting. It also
shows the set of conditions that require the client to call
unbindService().
Test: make ds-docs -j16
Bug: 63118511
Change-Id: I1276de3f9421e13e1964039d37db9adc87f3039f
The documentation for android.app.Service includes an example from
LocalServiceActivities.java. This example now better shows and
explains the distinction between binding and connecting. It also
shows the set of conditions that require the client to call
unbindService().
Test: make ds-docs -j16
Bug: 63118511
Change-Id: I1276de3f9421e13e1964039d37db9adc87f3039f
The documentation for android.app.Service includes an example from
LocalServiceActivities.java. This example now better shows and
explains the distinction between binding and connecting. It also
shows the set of conditions that require the client to call
unbindService().
Test: make ds-docs -j16
Bug: 63118511
Change-Id: I1276de3f9421e13e1964039d37db9adc87f3039f
This CL adds a sample IME that demonstrates how an IME can now control
the appearance of bottom navigation bar like typical Activities can
do.
This sample IME covers the following 3 use cases to control the
appearance of bottom navigation bar.
A. (Bottom) navigation bar has solid background color.
Like typical Activities, IMEs can
- call Window#setNavigationBarColor() to change the background
color. (Bug 25706186)
- set SYSTEM_UI_FLAG_LIGHT_NAVIGATION_BAR to tell the SysUI to
optimize the navigation bar button colors. (Bug 69002467)
B. (Bottom) navigation background is seamlessly extended from the main
InputView of the IME, like typical Activities can do with
SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION. Note that essentially this
is a super set of the mode A, because IMEs (and apps) can also fill
the navigation bar region with a solid color in this mode.
C. The appearance of (bottom) navigation bar is controlled by the
target application, not by the IME.
- This is useful for floating IME (Bug 22564251).
Bug: 25706186
Bug: 69002467
Test: Build and manually test as follows.
1. make -j ThemedNavBarKeyboard
2. adb install -r $OUT/system/app/ThemedNavBarKeyboard/ThemedNavBarKeyboard.apk
3. adb shell ime enable com.example.android.themednavbarkeyboard/.ThemedNavBarKeyboard
4. adb shell ime set com.example.android.themednavbarkeyboard/.ThemedNavBarKeyboard
Change-Id: I4b10a19641bd3ce6c43e7629404b6f202d4186e8
In preparation for the removal of the non-junit classes in the
android.test.base library from the android.jar this adds a dependency
on android.test.base/stubs to ensure this code will continue to
compile.
The following change descriptions were generated automatically and so
may be a little repetitive. They are provided to give the reviewer
enough information to check the comments match what has actually been
changed and check the reasoning behind the changes.
* samples/ApiDemos/tests/Android.mk
Added 'android.test.base.stubs' to LOCAL_JAVA_LIBRARIES because
ApiDemosTests's will need them in order to compile once its classes
are removed from the current SDK on which it currently depends.
* samples/BrokenKeyDerivation/tests/Android.mk
Added 'android.test.base.stubs' to LOCAL_JAVA_LIBRARIES because
BrokenKeyDerivationTests's will need them in order to compile once
its classes are removed from the current SDK on which it currently
depends.
* samples/HelloActivity/tests/Android.mk
Added 'android.test.base.stubs' to LOCAL_JAVA_LIBRARIES because
HelloActivityTests's will need them in order to compile once its
classes are removed from the current SDK on which it currently
depends.
* samples/LunarLander/tests/Android.mk
Added 'android.test.base.stubs' to LOCAL_JAVA_LIBRARIES because
LunarLanderTests's will need them in order to compile once its
classes are removed from the current SDK on which it currently
depends.
* samples/SkeletonApp/tests/Android.mk
Added 'android.test.base.stubs' to LOCAL_JAVA_LIBRARIES because
SkeletonAppTests's will need them in order to compile once its
classes are removed from the current SDK on which it currently
depends.
* samples/Snake/tests/Android.mk
Added 'android.test.base.stubs' to LOCAL_JAVA_LIBRARIES because
SnakeTests's will need them in order to compile once its classes
are removed from the current SDK on which it currently depends.
* samples/Vault/Android.mk
Added 'android.test.base.stubs' to LOCAL_JAVA_LIBRARIES because
Vault's will need them in order to compile once its classes are
removed from the current SDK on which it currently depends.
Bug: 30188076
Test: make dist
Change-Id: Id7fb558504706668a85bf840529f6cd075499d6a
Statically including legacy-android-test leads to duplicate classes
which causes build time problems (with Proguard) and runtime problems on
older SDK versions. This change:
* Stops statically including legacy-android-test.
* Adds compile time dependencies on andoid.test.base, android.test.mock
and android.test.runner where necessary.
* Adds <uses-library android:name="android.test.runner"/> to any
affected package to ensure that the classes that were included by
legacy-android-test are still available at runtime. That also adds a
dependency on android.test.base and android.test.mock.
The following change descriptions were generated automatically and so
may be a little repetitive. They are provided to give the reviewer
enough information to check the comments match what has actually been
changed and check the reasoning behind the changes.
* samples/ApiDemos/tests/Android.mk
Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
because statically including the classes in ApiDemosTests results
in duplicate classes which leads to build time and compile time
issues.
* samples/BrokenKeyDerivation/tests/Android.mk
Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
because statically including the classes in
BrokenKeyDerivationTests results in duplicate classes which leads
to build time and compile time issues.
* samples/HelloActivity/tests/Android.mk
Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
because statically including the classes in HelloActivityTests
results in duplicate classes which leads to build time and compile
time issues.
* samples/LunarLander/tests/Android.mk
Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
because statically including the classes in LunarLanderTests
results in duplicate classes which leads to build time and compile
time issues.
* samples/SkeletonApp/tests/Android.mk
Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
because statically including the classes in SkeletonAppTests
results in duplicate classes which leads to build time and compile
time issues.
* samples/Snake/tests/Android.mk
Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
because statically including the classes in SnakeTests results in
duplicate classes which leads to build time and compile time
issues.
* samples/Vault/Android.mk
Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
because statically including the classes in Vault results in
duplicate classes which leads to build time and compile time
issues.
Added 'android.test.runner.stubs' to LOCAL_JAVA_LIBRARIES because
Vault's source depends on its classes and because of these changes
they are no longer present on the compilation path.
* samples/Vault/AndroidManifest.xml
Add uses-library for android.test.runner because otherwise this
change would change the set of files available to Vault at runtime.
Bug: 30188076
Test: make checkbuild
Change-Id: I9f42f9216b7a40f1f139699e9c4df04325d577a1
Previous changes statically included legacy-android-test in preparation
for removing android.test.* and junit.* classes from the android.jar.
Unfortunately, that lead to duplicate classes between APKs and the
bootclasspath which caused build problems (Proguard) and also runtime
problems (when targeting and running on older releases).
Switching from statically including the classes to using the runtime
libraries cannot be done in one step because legacy-android-test is
statically included in libraries which are used in many APKs and so
removing it from those libraries requires that all APKs be updated at
once. Doing that atomically across dozens of projects is not practical.
This change modifies APKS that statically include the
legacy-android-test library indirectly.
* If the APK manifest uses the android.test.runner library then the APK
is modified to stop statically including legacy-android-test and
instead build against android.test.base/mock/runner libraries instead.
* Otherwise, the APK statically includes legacy-android-test.
Also, any libraries that statically include are modified to stop
statically including it and if it has source dependencies on the classes
is changed to build against the android.test.base/mock/runner libraries.
The following change descriptions were generated automatically and so
may be a little repetitive. They are provided to give the reviewer
enough information to check the comments match what has actually been
changed and check the reasoning behind the changes.
* samples/UiAutomator/Android.mk
Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
uiautomator.samples has a source dependency on its classes
Bug: 30188076
Test: make checkbuild
Change-Id: I07b9638373eae0e36c365b604748b1279793620b
1) Remove the "Refresh package" demo. This was using Intent.EXTRA_ALLOW_REPLACE, which was deprecated in API 16.
2) Java code cleanup.
Test: Manually.
Change-Id: I0cbff934ca223a3fe73a1044ed68f3e079be8237
The current APK was built to target the ICS SDK, and cannot be installed on newer versions:
"Failure [INSTALL_FAILED_OLDER_SDK: Failed parse during installPackageLI: /data/app/vmdl1087711068.tmp/base.apk (at Binary XML file line #0): Requires development platform IceCreamSandwich (current platform is any of [P])]"
The APK I'm checking in was built from development/samples/HelloActivity, with this added to the manifest:
<uses-sdk android:minSdkVersion="23" android:targetSdkVersion="23" />
This is the same as the ApiDemos app's minSdk and targetSdk.
Test: Manually rebuilt ApiDemos, and installed the package using the InstallApk activity.
Change-Id: I337200234662277b0253fd7fdfa96e1ee229e912
