how to choose the correct version of android CTS - android

i work for a phone vendor, our phone was based on Android 2.3.4_r1 GRJ22 , but when i ran the CTS , the OsVersionTest fails for the reason of not supporting 2.3.4 in test case.
how to choose the version of CTS?

Probably way too late for what you need (I only really started serious use of CTS recently), but figured I give what bit of an answer I had anyway.
As I understand it (and I could be wrong), you can download CTS for a bunch of versions of Android at
http://source.android.com/compatibility/downloads.html
I would think that the 2.3 build should work for you as I don't think minor versions prevent it from running (and that seems true in my tests).
From 4.0 on, CTS is in the Android Open Source code so you can build it yourself although I've had issues there (see https://stackoverflow.com/questions/10400938/building-working-cts-for-user-build for example) and since you are on 2.3 you can't build it anyway.

Related

Emulate Android 1.6 Donut with ARM ABI

Is it possible somehow - anyhow, even in another virtual machine - to emulate an ARM-based Android device running Android 1.6 Donut OS?
Android Studio does offer creating a hardware device with this version of Android, but nothing happens when I'm trying to start the emulator. I cannot start neither 1.6 Donut nor 2.3 Gingerbread. I can run 7.0 Nougat, however.
Gingerbread and Donut fail silently, the console that runs Android Studio does not output anything.
Background
I'm doing experiments on how these old devices could be reused and I have discovered that I can compile at least some rudimentary C++ using NDK (along with older versions of Java, but right now I'm interested in running native code).
The ancient old Android NDK that supports API Level 4 can only compile binary for ARM processors, but right now I'm only able to run Android 1.6 x86 in VirtualBox, which, of course, won't run that code.
As an alternative I would be happy with an NDK that compiles for the x86 port of Android.
I have successfully compiled some rudimentary binaries for recent versions of Android using NDK, now I wish I could do the same for older versions without a physical hardware, as my oldest device runs 2.3 Gingerbread. At the time I got that phone, it used to run version 1.6, but I have upgraded it long since and there is no way to go back.
I'm targeting specifically those devices that nobody uses anymore, but are not thrown into the garbage yet. (even if it remains only a hobby project, thereof)
Thank you for your hints in advance!
Micheal guided me to the right direction, thank you!
Solution
Silly enough, I did not found on my own where can I download an older release of the sdk.
I also forgot that tools/android is the executable for the graphical AVD manager (meanwhile it also features a very friendly text interface).
I could run Android, and also a hello world compiled with the old NDK.
I'm now very excited to see what is possible with these old Droids using C++! :)

Multi-platform development: use recent Visual Studio with older version of Android

[update] I finally was able to deploy our app on 4.2 using the latest toolchain. I get an error. See below after the original text.
We are looking for a long term solution to keep using recent version of Visual Studio (2019 at the time of this post) while keeping developping for old Android platforms (prior to 4.4).
Xamarin#Microsoft dropped support for Android previous to 4.4 in the Xamarin.Android release 9.2, but we cannot drop the support for our product.
Until now we keep using VS2017 for our specific android development, but the gap between VS2019 and VS2017 development environment is increasing and this is adding an increasing overhead on our day-to-day development.
Our projects are developped using a mostly common code base for a software deployed on PC, but part of this code is also part of an Android application that can run on specific devices.
For PC development which is our main activity, we want as much as possible to be able to code using the latest .NET standard and latest tools.
The Android version is an industrial software very specific to the hardware it is used on, and we cannot expect the Android OS to be updated, so we are stuck with a minimal Android version support of 4.2.2.
I already searched on SO and other forums, but didn't find any "good" long-term solution.
For information here are some of the good information I found related to this topic:
https://learn.microsoft.com/en-us/xamarin/android/release-notes/9/9.2
https://learn.microsoft.com/en-us/xamarin/android/app-fundamentals/android-api-levels?tabs=windows
Which .Net Standard version supports which Android versions?
https://github.com/xamarin/xamarin-android/blob/master/Documentation/guides/messages/xa4216.md
https://learn.microsoft.com/en-us/dotnet/standard/net-standard
Currently I think what we can do is:
1) Mainly use .NET standard libraries for the common parts of our code
2) Having very few assemblies directly using Xamarin.Android, typically only for the UI part.
Note that this is close to what we are already doing now (except that we could port more of our assemblies to .NET Standard I think).
However since we target API level 4.4 and use the application on 4.2, we may call some APIs that are not supported in 4.2, or even worse, APIs that are supported but buggy because the new Xamarin/Mono runtime does not support old Android versions. This is especially true since there is the warning XA4216: even if we can deploy and run on an older android because the manifest allows it, we cannot ensure that the OS provides all the necessary features used by the mono runtime.
At the moment the warning XA4216 is for version 4.0.3, but we see the day coming when we update VS2019 and get this warning for Android 4.2.
So is there a better solution than:
1) Keep the old VS2017/old Xamarin.Android build environment and block our day-to-day productivity to keep ensuring full compatibility with Android 4.2
2) Update our build and development environment fully to VS2019 with latest Xamarin and pray that the implementation is not bugged on older OS.
I would like to be able to go with 2 and have some insurance that everything will work fine, without having to retest the whole application each time there is an update of visual studio.
What do you think?
To ensure application stability, are we stuck with the old build system (VS2017 + old Xamarin.Android), or is it a "safe" risk to upgrade to VS2019 with latest Xamarin?
Thanks in advance for any good advice on this topic.
PS:
I pushed with solution 2: "Update our build and development environment fully to VS2019 with latest Xamarin and pray that the implementation is not bugged on older OS." to do the test locally on my PC at first.
After making necessary changes in our app so that it builds with VS2019 & latest Xamarin, I deployed to test on our Android 4.2.2 device (took me 1 whole day to fix the build errors...). I get the following error and app freezes:
W/libc ( 9196): protoent* getprotobyname(char const*)(3) is not implemented on Android.
Maybe praying was not enough... any ideas?
Go with option 2 & update your build and development environment fully to VS2019 with latest Xamarin! The implementation should not bug any older OS.
Even if it does add bugs, just test your code in QA. As for production, you can place good crash analytics on your app, and you ll be able to catch, report and fix any bugs.
For the most part, on Android the number of users using below Android 4.4 is less than 0.001% of all users. At that point, it makes more sense to implement Accessibility in your app, since that affects 1000x more users.

Android "optimizing" my app (libgdx game, actually) on every reboot, still app runs very slow when launched

EDIT: it really was a bug in AS 3.1.1 related to D8 compiler as stated here. It's said to be fixed by now in AS 3.1.3, although I didn't check that myself.
I know it means it performing AOT compilation.
The thing is that I get a lot of reviews saying "everything was fine before the latest update, but the game is extremely slow now" from users on Android 6.0 and above. Some users report that sometimes the game can not respond to their actions for literally minutes.
Also, a few reviews said that the game is a cause their phones reboot takes a very long time saying it's "optimizing apps 1/1" and that the issue goes away when they uninstall my game from the device.
I cannot reproduce the issues on any devices I have on hand (I have no Android 6.0 unfortunately, only 5.1 phone and 7.1 tablet - the game runs smoothly on those)
I need help to figure out the cause of the problem.
What I did before the latest update (that caused the problem):
switched from AS 3.0 to 3.1 (and updated project to use a newer version of gradle - 4.4)
updated android support libraries to 26.0.1
updated Appodeal libraries to 2.1.11
updated libgdx version from 1.9.5 to 1.9.6
Also, I made a few minor changes in the game's core code, but I see no way of them causing system-wide issues, it has to be something of the above. Are there any knows issues with these versions of libraries?

Is android-5.0-lollipop runtime [ART] compatible with earlier JNI code which works in Dalvik+Kitkat?

I have 6 Android apps in production, available at the Google Store, which apparently all fail on Nexus tablets running Android 5.x variants. All my current tablets are Android Kitkat (4.4.2) or earlier, so for now, I cannot even run a logcat from adb to see what is happening. Users are reporting none of my apps run on Android 5.0.1 and 5.0.2, and I confirmed it today, with a Nexus 9, at a carrier's retail outlet. My code uses java and JNI (the native interface). Java stuff starts ok, but JNI fails. It looks like others have this problem. Is there any obvious and elegant way to restore Android 4.4 (Kitkat) operational functionality within the unstable/altered Android 5.0-lollipop? Specifically: I need to disable the "checkJNI" feature, which is a Dalvik VM feature. This is done by having a low Android API number in the AndroidManifest.xml file. I use Android-8 API, but code is built using Android-19 API, and apps work on all 4.x series tablets/phones. Can I disable "checkJNI" in ART/Lollipop explicitly, as is possible implicitly using Dalvik/Kitcat? Or am I barking up the wrong tree? Based on the number of reports of broken/failing apps on Android 5.x, there are clearly significant issues. The current workaround seems to be a direct downgrade back to Android 4.4.x.
But if there are some specific show-stopping issues (such as I am apparently dealing with...) re. JNI code migration from Kitkat to Lollipop, a short comment would be most appreciated. Thanx.

Running Android Applications on Smartphone with Lower Versions

Hello I am new to Android Programming, I have a doubt, can I run and test all android applications that I am going to create on my HTC phone with ice cream sandwich. I am using android studio and I prefer to test apps on my HTC connecting via USB. My system is very slow while using an emulator it is very difficult to test on emulator
Also 'compile with' API means what, I understand minimum and target sdk in Eclipse..
Yes, you can use your physical device.
But the good practice is to create a range on AVDs from minimal to max Android versions, and to test your app (run tests if you have wrote them) in those AVDs.
Skipping this point will lead to some users dissatisfaction because your app can fail\crash on untested versions. Different Android versions do have some minor differencies in the API and libs behaviour.

Categories

Resources