Ask questions about Android VTS - android

I ask questions about Android VTS.
I am currently working on ubuntu 18.04, and target device is working on AVD.
First of all, the environment I set is as follows.
$ sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig
$ mkdir android && cd android
$ repo init -u https://android.googlesource.com/platform/manifest -b android-11.0.0_r28
$ repo sync -c -j $(($(nproc) - 2)) --no-tags --no-clone-bundle
$ repo start android-11.0.0_r28 --all
$ . build/envsetup.sh
$ lunch sdk_phone_x86_64-userdebug
$ m
I have successfully built and confirmed that the emulator works well.
$ emulator -no-window -writable-system
$ adb root remount
$ adb device
List of devices attached
emulator-5554 device
After that, I built the following vts to analyze the behavior of Android keymaster.
$ cd hardware\interfaces\keymaster\3.0\vts\functional
$ mm
After successful module build, I ran the emulator and pushed the binary as follows.
$ emulator -no-window -writable-system
$ adb root remount
$ adb push out\soong\.intermediates\hardware\interfaces\keymaster\3.0\vts\functional\VtsHalKeymasterV3_0TargetTest\android_x86_64\VtsHalKeymasterV3_0TargetTest /data/tmp
I did the above successfully, and I ran the binary and it looks like this:
$ adb shell /data/tmp/VtsHalKeymasterV3_0TargetTest
[==========] Running 12 tests from 1 test suite.
[----------] Global test environment set-up.
[----------] 12 tests from GoogleTestVerification
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<KeymasterVersionTest>
Paramaterized test suite KeymasterVersionTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<KeymasterVersionTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<NewKeyGenerationTest>
Paramaterized test suite NewKeyGenerationTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<NewKeyGenerationTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<GetKeyCharacteristicsTest>
Paramaterized test suite GetKeyCharacteristicsTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<GetKeyCharacteristicsTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<SigningOperationsTest>
Paramaterized test suite SigningOperationsTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<SigningOperationsTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<VerificationOperationsTest>
Paramaterized test suite VerificationOperationsTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<VerificationOperationsTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<ExportKeyTest>
Paramaterized test suite ExportKeyTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<ExportKeyTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<ImportKeyTest>
Paramaterized test suite ImportKeyTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<ImportKeyTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<EncryptionOperationsTest>
Paramaterized test suite EncryptionOperationsTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<EncryptionOperationsTest> (1 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<MaxOperationsTest>
Paramaterized test suite MaxOperationsTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<MaxOperationsTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<AddEntropyTest>
Paramaterized test suite AddEntropyTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<AddEntropyTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<AttestationTest>
Paramaterized test suite AttestationTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<AttestationTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<KeyDeletionTest>
Paramaterized test suite KeyDeletionTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<KeyDeletionTest> (0 ms)
[----------] 12 tests from GoogleTestVerification (2 ms total)
[----------] Global test environment tear-down
[==========] 12 tests from 1 test suite ran. (3 ms total)
[ PASSED ] 12 tests.
It only took 3ms to complete the following.
When I check it closely, the test itself does not seem to proceed.
I have not made any additional changes to the source or other details.
Anyone who knows what else I need to do to run the keymaster vts would be appreciated.

Related

Getting a custom ramdisk to boot on Android

I am working on a "GNU/Linux on Android" type of project that is based on Mikael Q. Kuisma's work here .
I built a tool that downloads a toolchain, compiles the kernel, archives the custom ramdisk, and finally bundles them into a boot image.
Expected result:
Kernel boots.
Ramdisk gets loaded and /init is executed using /sbin/busybox.
Actual result:
Kernel does boot.
The kernel never seems to reach /init, and hangs without panicking.
I've tried adding calls to /sbin/busybox poweroff in the /init script to see if it was actually reaching execution, nothing changed.
I identified a few points that seemed problematic, one being this:
[ 3.880314] Warning: unable to open an initial console.
[ 3.880429] Waiting for root device ... # Might be the problem.
[ 4.882304] lct will vote for sdp current
[ 4.882437] pmi632_charger: smblib_update_usb_type: lct v02 battery charge APSD=SDP PD=0
[ 4.889933] msm-dwc3 7000000.ssusb: DWC3 exited from low power mode
[ 5.520181] of_batterydata_get_best_profile: light_4000mAh found
[ 8.760236] cfg_timer_func enter
[ 8.760267] cfg_work_routine enter
# Nothing appears after this point...
I have included the source code for my build tool with the kernel log buffer in this git repository. You can find the defconfig I used for the kernel build here.
Any help would be appreciated. :)

`java.lang.NoClassDefFoundError: android/view/View` while trying to build 'HelloWorld' project from android-kawa in Termux

I've been trying to employ Kawa Scheme for developing Android project. I've found two repositories on GitHub: one called 'android-kawa', and another called 'KawaDroid'. They're both a bit dated (last updates were around 2012). In the case of 'android-kawa' I was able to reach the author, but he said he did't remeber enough to help me.
In the 'android-kawa' repo there's a bunch of scripts for setting up and working with the project. One of the scripts downloads the Kawa 1.13 tarball, applies some patches and then attempts to build it.
However, the build isn't supported in Termux, bevaise the config.guess script doesn't recognize the system. This issue can be easily resolved by downloading the latest versions of config.guess and config.sub.
Another problem is the format of the JVM bytecode. When I use the latest Java compiler, the generated bytecode contains (I believe) instructions for JVM8+, which aren't supported by the dx command. This isn't a problem if I run Java inside of Termux, because it installs the regular JVM, but if I want to include the Kawa jar in my APK (which is something that I want), then it becomes an obstacle.
This, again, can be resolved by forcing the Java version to 7 in javac. (But then, the compiler complsins that Java 1.7 is deprecated. I guess this is why the buildAPKs project uses ecj instead of javac)
Also, when I ./configure Kawa, I can pass it the path to the android.jar file (./configure --with-android=...). I have two android.jar files on my system:
~ $ locate android.jar
/data/data/com.termux/files/usr/share/aapt/android.jar
/data/data/com.termux/files/usr/share/java/android.jar
I don't know where they came from or how they differ between one another, but I've been prefering the second one.
So, when I have the kawa.jar available - and when I try to compile it with the command
~/android-kawa $ java -cp $(dirname $(locate android.jar |tail -n 1)) -jar kawa/kawa-1.13.jar -C KawaHello/src/kawa/android/hello.scm
I get the following error:
internal error while compiling KawaHello/src/kawa/android/hello.scm
java.lang.NoClassDefFoundError: android/view/View
at gnu.kawa.android.defs.<clinit>(defs.scm)
at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method)
at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1155)
at java.base/jdk.internal.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:42)
at java.base/jdk.internal.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:185)
at java.base/java.lang.reflect.Field.acquireFieldAccessor(Field.java:1132)
at java.base/java.lang.reflect.Field.getFieldAccessor(Field.java:1113)
at java.base/java.lang.reflect.Field.get(Field.java:425)
at gnu.expr.ModuleInfo.setupModuleExp(ModuleInfo.java:195)
at kawa.standard.require.importDefinitions(require.java:308)
at kawa.standard.require.scanForDefinitions(require.java:219)
at kawa.lang.Syntax.scanForm(Syntax.java:65)
at kawa.lang.Translator.scanForm(Translator.java:1120)
at gnu.kawa.lispexpr.LispLanguage.parse(LispLanguage.java:64)
at gnu.expr.Compilation.process(Compilation.java:1908)
at gnu.expr.ModuleInfo.loadByStages(ModuleInfo.java:305)
at gnu.expr.ModuleInfo.loadByStages(ModuleInfo.java:290)
at gnu.expr.ModuleInfo.loadByStages(ModuleInfo.java:290)
at gnu.expr.ModuleInfo.loadByStages(ModuleInfo.java:290)
at gnu.expr.ModuleInfo.loadByStages(ModuleInfo.java:290)
at gnu.expr.ModuleInfo.loadByStages(ModuleInfo.java:290)
at kawa.repl.compileFiles(repl.java:823)
at kawa.repl.processArgs(repl.java:444)
at kawa.repl.main(repl.java:869)
Caused by: java.lang.ClassNotFoundException: android.view.View
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520) ... 24 more
I have obviously tried it without the -cp argument (with the same effect). The android/view/View.class entry is present in the list returned by jar -tf android.jar.
How can I further investigate in the root cause of the problem, and most importantly, how can I solve it?
It turned out that I have invoked Java incorrectly, and that it didn't see the android.jar file. It helped to invoke the compiler in the following way:
~/android-kawa $ java -cp $(locate android.jar |tail -n 1):kawa/kawa-1.13.jar kawa.repl -C KawaHello/src/kawa/android/hello.scm
(the difference is that I only have one -cp argument with jar files separated by :, and that I explicitly give the kawa.repl class name)

Android insmod kernel object on boot

I am currently trying to insmod a kernel module during the end of the boot process, and so I've created the following entries in init.rc:
on post_late_start
start myscript
on nonencrypted
class_start late_start
trigger post_late_start
on property:void.decrypt=trigger_restart_framework
class_start main
class_start late_start
trigger post_late_start
service myscript /data/my_sh.sh
disabled
oneshot
Then in my /data directory my_sh.sh has the following:
#!/system/bin/sh
log -t mytag -p V "Hello World!"
insmod mymodule.ko mod_parameter=arg
But when I run -- sometimes I do not see the "Hello World" tag when I logcat -s "mytag" and of course, the insmodded module is not installed either.
What is the proper way of late-inserting a kernel module (it needs to go in after network is up and /data is mounted). And further -- how do I get the output of insmod into the log so that I can debug? Any help is appreciated and I can post more details if necessary.
At least since Froyo and still in Lollipop, Android init implements insmod in system/core/init/buildin.c. It is supposed to work directly in an init*.rc file:
on boot
insmod /system/lib/modules/your-module.ko.
However, at least in Lollipop 5.1, it no longer works, as SELinux rules are enforced. init does not have the required sys_module permission. Therefore the underlying init_module system call returns EPERM. This is never reported to anywhere. The only symptom is that insmod commands now fail to load the module, always.
I opened an AOSP issue on this. According to Google, this works as intended. If you want to use kernel modules when SELinux is enforced (which they strongly advice against), you must yourself add the required SELinux permission to init.
I am not sure about your log, but to insmod you need to give the exact path to the module, because I dont think you will be having mymodule.ko residing in the same place as init.rc is there. So try to give the full path of your ko file.
Generally it resides in /lib/modules/youdrivername.ko
so check it here first.

Android: debug shared library

I'd like to debug android NDK application, more precisely - I want to check what arguments (r4 - r8 r1 - r4 registers) are passed to function from shared library in apk.
What I have tried:
I've run gdbserver :1234 --attach on the device
I've run arm-linux-androideabi-gdb from ndk package by Google on the PC
I've set solib-search-path and written target remote :1234
So far, so good. Now I try to set breakpoint (break <function name>) (function name from
objdump), but I get repond: Cannot access memory at address <...>. info shared says the library is loaded, Does it mean I can't set breakpoint there? Or am I doing something wrong?
The ndk-build skript does much more then you would expect.
One of the things it to copy both the gdbserver, a file called gbd.setup and the generated .so into a hidden folder called .obj/armei/
There you will have to add the libraries you would like to debug because the symbols are referencing them.
The libraries are copied from the device to your PC by some adb shell pull - commands.
I wrote an article about the topic at: http://www.professional-android-development.com/articles/android-ndk-large-c-projects
When placing the libraries into the right folder, you can set your breakpoints.
Still, for some internal reasons, they can fail.
In this case run ndk-gdb --start (the first try will also fail), enforce the application to close and rerun ndk-gdb --start (this time not forcing the application to close).
"Cannot access memory at address <...>" usually means there is a mismatch between the .so file on your PC and the .so file that is on Android. Did you recompile and reinstall?
Btw, what is the reason you're not using "ndk-gdb"? That's a script (part of the NDK) that takes care of all the gory details for you.

executing static program from android init.rc

I want to start a custom program in the init process. I compiled this program statically that run fine from my booted up android stock ROM.
From the android init.rc docs I read that the exec command is what I need.
BTW all I can see in dmesg is that my program exit with code -1 (I can't return that).
init.rc snippet:
on post-fs-data
write /dev/kmsg "launching test"
exec /data/test
All I see in dmesg is this:
<4>[ 6.336816] launching test
<6>[ 6.336902] init: command 'write' r=0
<6>[ 6.337115] init: command 'exec' r=-1
Here you are the executable source code: http://pastebin.com/Hym1APWx
UPDATE
I tried to statically compile and run this program:
int main(){return 0; }
But the result is always command 'exec' r=-1. Maybe user uselen are right, maybe I cannot run executables from /data in the early-boot phase.
As christian said, it looks like exec isn't even implemented. I'm beginning to think that a lot of features documented for init.rc aren't implemented. Here's a way you can get your program to launch however.
Instead of running this as an "exec" command, set this up as a service instead.
In your init.rc, or another file included by it:
service my_service /data/test
class main
oneshot
If it's in class main, and not disabled, it should run after /data is mounted.
I had the same issue today. In my case the solution was simple: The exec function wasn't implemented yet and contained just a return -1. You should take a look at builtin.c and search for do_exec(). This code is executed when init.rc contains an exec statement.

Categories

Resources