I am running Espresso tests in the Travis CI. When I run my tests in my device, I normally disable all my animations so I don't have to use Thread.sleep all the time.
But I really don't know how to do this in the Travis CI, so my tests fail without the Thread.sleep. I looked over the internet... but I didn't find any tutorial about how to do disable the animations in the emulator
I could use idling resource in Espresso, I know. But some times I would prefer not to.
If you try #azizbekian's path, I wrote about this here, created new test rules here and tested it here
I confirm #Testujaca Malpeczka path works on Travis-ci for Android APIs 17-22 as discussed here
If you are looking for a solution for latest Android APIs and tools, work in progress here and here
before_script:
# Wait for emulator fully-booted and disable animations
- android-wait-for-emulator
- adb shell settings put global window_animation_scale 0 &
- adb shell settings put global transition_animation_scale 0 &
- adb shell settings put global animator_duration_scale 0 &
- adb shell input keyevent 82 &
It also works in Circle-ci and probably any continuous integration build server, see broken link here
test:
pre:
- ...
- circle-android wait-for-boot
- adb shell input keyevent 82
- adb shell settings put global window_animation_scale 0
- adb shell settings put global transition_animation_scale 0
- adb shell settings put global animator_duration_scale 0
My extended test rules work for Android APIs 15-22, and there was a bug in Android 23 emulator.
I'll try it for later versions 24+ using android-topeka sample another day, probably it works.
Any help, improvement or effective alternative using sdkmanager would be much appreciated.
If it possible use adb shell command:
adb shell settings put global window_animation_scale 0.0
adb shell settings put global transition_animation_scale 0.0
adb shell settings put global animator_duration_scale 0.0
tested on jenkins ci
Related
The command to change UE mode preference that seemed to work on Nougat & Marshmallow isn't working for Android O (Oreo). Does anyone know the correct command?
I tried the old commands:
adb root && wait-for-device
adb remount && timeout 3
adb shell settings put global preferred_network_mode 11
adb shell sync
adb reboot
timeout 5
exit
Can you help?
I found out that the commands are the same but there is a small change.
Mode Pref needs to know which SUB ID is the active SUB in order to change the UE mode preference.
So the command:
adb logcat -b radio |grep -I subid
would indicate the current SUB ID.
Once you find out the SUB, then the command to change mode pref is :
adb shell settings put global preferred_network_mode3 11
where _mode3 was the active SUB in my case.
I tried to get the multi-user support for my Android 7.1.1 AOSP emulator build on Ubuntu 16.04 64bit. The build gets run with lunch aosp_x86-eng and following the emulator with emulator64-x86.
I tried this solution but with no success:
adb shell
su
setprop fw.max_users 5
The Icon is visible for the first time when I wipe down the status bar, but disappears on releasing it:
Same like here:
adb shell setprop fw.show_multiuserui 1
adb shell setprop fw.max_users 4
I also tried to add an user by adb but without success.
After executing the commands I test it by using:
su
pm get-max-users
result is:
Maximum supported users: 4
Is there a barrier or something like that? Or do I need to edit the build? If I need to root the system, why is the property set to 4 users? And why is the icon shown on the first wipe and disappears after releasing?
Thanks!
I am trying to get calabash-android running within travis. calabash-android works fine within my machine without any problems. I have the following travis.yml:
language: android
jdk: oraclejdk8
before_cache:
- rm -f $HOME/.gradle/caches/modules-2/modules-2.lock
cache:
directories:
- $HOME/.gradle/caches/
- $HOME/.gradle/wrapper/
- $HOME/.gradle/daemon
- $HOME/.gradle/native
env:
global:
# wait up to 10 minutes for adb to connect to emulator
- ADB_INSTALL_TIMEOUT=20
- SLAVE_AAPT_TIMEOUT=40
android:
components:
- platform-tools
- tools
- build-tools-23.0.3
- android-23
- extra-android-support
- extra-android-m2repository
- extra-google-m2repository
- sys-img-armeabi-v7a-android-23
before_install:
# install ruby 2.0.0
- rvm install 2.0.0
# install calabash-android
- gem install calabash-android
before_script:
- echo no | android create avd --force --name test --target android-23 --abi armeabi-v7a
- emulator -avd test -no-skin -no-audio -no-window -no-boot-anim &
- android-wait-for-emulator
- adb shell settings put global window_animation_scale 0 &
- adb shell settings put global transition_animation_scale 0 &
- adb shell settings put global animator_duration_scale 0 &
- adb shell input keyevent 82 & #for unlocking as "powerkey"
- sleep 3 # give screen some time to become unlocked
- ./gradlew clean assembleDebug -PdisablePreDex --continue --stacktrace
script:
- calabash-android resign /home/travis/build/app/build/outputs/apk/app-debug.apk
- calabash-android run /home/travis/build/app/build/outputs/apk/app-debug.apk
It works with the 1st scenario of the feature and then once it starts 2nd scenario, it shows this error:
App did not start (RuntimeError)
./features/support/app_life_cycle_hooks.rb:5:in `Before'
Any ideas? or suggestion?
Delete -no-boot-anim option, android-wait-for-emulator script depends on boot animation to detect when the emulator is ready.
This is a great explanation I recommend: Detecting when emulator is ready to be used
The second step is to wait for emulator to fully boot, so it can be
used to run some code. This turned out to be the most tricky part.
Especially for emulators with API Level 11+ (11-14 at the time of
writing).
First, emulator should connect to adb and will be listed as “offline”.
In this state emulator does not accept any shell commands. And nothing
can be done in this state. This part is usually very stable and I
haven’t seen the case when emulator was started but never connected to
adb. Of course if some error occurs, it won’t connect to adb. So
timeout should be used here to detect abnormal delays or hangs.
Next state device goes to called “device” state. This is when device
is booting. As soon as it had booted, device goes to “online” state.
This is when system starts booting and normal operation of emulator
goes in.
From the moment device goes to “device” state, adb shell can be used
to execute different commands on device and query some useful
information about its state.
I’ve found several properties that should be tracked in order to
reliably detect when device is ready. The first property is called
dev.bootcompleted. As soon as device completes booting this property
will be set to 1.
After dev.bootcompleted is 1, next property called sys.boot_completed
should be tracked. It will be set to 1 as soon as system completed
booting (this is usually when BOOT_COMPLETED broadcast is sent). This
property is only set on emulators with API Level 9 or higher. On 8 and
lower this property is never used (and shouldn’t be tracked).
But emulator is still not ready, even when sys.boot_completed is set
to 1. You’ll notice that boot animation will still run for some
(significant) period of time. And only then UI will appear. But
luckily there is a way to detect this event too. For this we need to
track value of init.svc.bootanim property. This property keeps state
of boot animation service, that will be stopped as soon as UI appears.
In other words, as soon as init.svc.bootanim has value stopped, its
safe to assume that emulator is running and ready to be used.
Using -no-boot-anim the value is stopped before your emulator is fully-booted:
# Originally written by Ralf Kistner <ralf#embarkmobile.com>, but placed in the public domain
set +e
bootanim=""
failcounter=0
timeout_in_sec=360
until [[ "$bootanim" =~ "stopped" ]]; do
bootanim=`adb -e shell getprop init.svc.bootanim 2>&1 &`
if [[ "$bootanim" =~ "device not found" || "$bootanim" =~ "device offline"
|| "$bootanim" =~ "running" ]]; then
let "failcounter += 1"
echo "Waiting for emulator to start"
if [[ $failcounter -gt timeout_in_sec ]]; then
echo "Timeout ($timeout_in_sec seconds) reached; failed to start emulator"
exit 1
fi
fi
sleep 1
done
echo "Emulator is ready"
Now I was doubting due to the first scenario works (I never used calabash-android) but I see that it doesn't depend on the emulator being ready:
calabash-android - What does resign do?
The resign is used if you need to sign the app to match your keystore.
Copied from GitHub docs
https://github.com/calabash/calabash-android/wiki/Running-Calabash-Android
Instead of resigning you could also consider copying your debug
keystore to your folder.
The apk calabash android runs must be signed with the same keystore as
the test-server.
Use the command: calabash-android resign <apk> to resign your application.
Building the test-server using calabash-android build will build the
test-server and sign it with the same key as the application you are
testing.
The second scenario does it:
Running test
To run your test: calabash-android run <apk>
Calabash-android will install an instrumentation along with your app
when executing the app. We call this instrumentation for "test
server". The "test server" has special permission that allows it to
interact very closely with your app during test. Everytime you test a
new binary or use an upgraded version of calabash a new test server
will be build. The test server is an intrumentation that will run
along with your app on the device to execute the test.
Perhaps exist other issues in this case but fixed the same issue here deleting -no-boot-anim.
I want to set the SELinux (Security Enhanced Linux) mode to Permissive or (0) on android 4.4.4 (and above if possible). I use the following command: setenforce 0, setenforce permissive and setenforce Permissive under root (my device is rooted). But the output of getenforce is always Enforcing. Now I am exhausted with this problem.
Can any one give me a solution? Thanks in advance.
Depending on how your device was rooted and what Android ROM your running will determine how you can disable it. The first thing to try is:
adb shell su 0 setenforce 0
This is NOT the same as:
adb shell setenforce 0
The execute on su causes a domain transition from shell (which cannot setenforce) into the su domain (which can call setenforce). For instance, run:
$ adb shell id -Z
context=u:r:shell:s0
compared to:
$ adb shell su 0 id -Z
context=u:r:su:s0
This may fail for three reasons:
You do not have the su executable
The su executable has the wrong label
The su domain rules were not compiled into the bootimage
To correct issue 2, you can (assuming adb is root):
adb remount
adb shell chcon /system/xbin/su u:object_r:su_exec:s0
This might fail, which will likely indicate issue 3. To fix issue 3, you need to recompile a boot.img that contains the su policy files. If you're compiling AOSP, just lunch a userdebug or eng variant of your device.
Another approach, would be to remove the functionality from init.c, and like issue 3, requires a recompile of the boot.img. Go into system/core/init/init.c (or .cpp) and remove all calls to security_setenforce().
Additionally, XDA has an application that may help automate this process and make it easier, however, I cannot speak to the quality of the application:
http://www.xda-developers.com/easily-change-your-android-selinux-mode/
Apparently Google has removed the CONFIG_SECURITY_SELINUX_DEVELOP kernel flag from many of their Stock kernels. Thus the standard trick mentioned by William (below) probably doesn't work. An example of these devices is the Samsung Note 4 (SM-N910F) running AOS 4.4.4.
The link above states:
CONFIG_SECURITY_SELINUX_DEVELOP aka global permissive mode, is useful for
when you are first developing device-specific policy for a board (add
'androidboot.selinux=permissive' to BOARD_KERNEL_CMDLINE). It also
permits transient setenforce 0 in -userdebug or -eng builds, which can
be helpful for developers.
If the bootloader is locked, then you can't modify the kernel cmdline
"Also, the code in the init program for processing the
androidboot.selinux= option is only compiled in -userdebug and -eng builds, so even aside from bootloader locking, you cannot use
androidboot.selinux=permissive on a -user build."
The way to check what build type you have is:
$ getprop ro.build.type
user
MUST BE ROOTED! Not sure if this works on KitKat (it should) but I use this on my Nexus 6. Run following in terminal or ADB Shell:
su
mount -o remount,rw /system
mkdir /system/su.d
echo "#!/system/bin/sh" > /system/su.d/permissive.sh
echo "echo 0 > /sys/fs/selinux/enforce" >> /system/su.d/permissive.sh
chmod 755 /system/su.d/permissive.sh
And check it after reboot by this:
su
/system/bin/getenforce
I want to set the screenlock mode to None in KitKat so I can run CTS.
I'm using the DragonBoard APQ8074 for development from Intrinsyc, and they just released their BSP for Android KitKat 4.4.2. Trouble is, it's unstable and the Security menu in Settings crashes. So I can't use adb shell to input keyevents 19, 20, 21, 22, 23 to navigate.
adb shell settings command seems like it should work for this, but it's not. I tried these commands against 4.2, 4.3 and 4.4, and they seem to assign the values, but they don't visually result in any changes.
shell#msm8974:/ $ settings get system lockscreen_disabled
null
shell#msm8974:/ $ settings put system lockscreen_disabled true
shell#msm8974:/ $ settings get system lockscreen_disabled
true
shell#msm8974:/ $ settings get system screen_brightness
102
shell#msm8974:/ $ settings put system screen_brightness 255
shell#msm8974:/ $ settings get system screen_brightness
255
Now I dunno if lockscreen_disabled is what I want, here, but Settings.java doesn't seem to provide a call to any sort of unlock_mode, so I dunno what else to do. I don't want to write an app to do this, I just want to set screen lock mode to None so I can run CTS. If I need to modify source, then make & flash a new image, I'm willing to do that, but I don't know what to modify. Thanks for any guidance.
Got it figured out.
1. Update settings.db using adb shell
shell#msm8974:/ $ su
shell#msm8974:/ # sqlite3 /data/data/com.android.providers.settings/databases/settings.db
sqlite3> update secure set value=1 where name='lockscreen.disabled';
sqlite3> .quit
2. Move or delete locksettings files
shell#msm8974:/ # mkdir /data/system/lock
shell#msm8974:/ # mv /data/system/locksettings* lock
adb reboot and good to go.
If there is no sqlite installed on the device use the following
1. Set Settings
adb shell settings put secure lockscreen.disabled 1
2. reboot to recovery
adb reboot recovery
3. remove locksettings db files
adb shell rm /data/system/locksettings.db
adb shell rm /data/system/locksettings.db-shm
adb shell rm /data/system/locksettings.db-wal
You should use lockscreen.disabled as the variable name in the setting command, and secure as the name space:
shell#msm8974:/ $ settings put secure lockscreen.disabled 1