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++! :)
Related
I have a Visual Studio 2010 Professional.I've installed NVIDIA AndroidWorks.I have a tablet with Android 4.1.1 also.I`ve been tried to debug simple android NDK application in Visual Studio 2010 Professional on my device, but I received some error 'Failed to attach: Android 4.1(API level 16) devices are not currently supported'.
Сan I somehow solve this problem or debugger really currently does not support Android 4.1 device?If not supported, are there plans for this in future versions NVIDIA AndroidWorks?I do not have the ability to upgrade the operating system on my tablet.
In General, wrote on the NVIDIA forum and got the answer, maybe someone will be useful:"There is a bug pertaining to API level 16 devices that makes debugging native code on them impossible. We've decided to fail earlier with an error message instead of letting people get to the buggy behavior.
So, unfortunately, you can't debug on a Android 4.1 device. As a workaround, you could try downgrading the device to API level 15 or installing a custom firmware (such as CyanogenMod) that is based on a later API level than 16."
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.
I've developed an android app, and the client insist that I will test and debug it on old android versions (3.0,2.3).
I've tried using the SDK emulator but I was not able to get the older version actually running.
i.e. they start (extremely slow) and crash before any thing meaning-full happened.
I was considering buying a device but where can I find devices with older android versions?
I guess I could try downloading an older android img and burn it to my device but that seems too cumbersome...
Any ideas?
For 2.3, use the x86-based system image and hardware acceleration rather than the ARM image. It's quite fast.
For 3.x, you may want to inform your client that as of the latest numbers Honeycomb 3.2 only makes up 0.1% of devices running Google Play and 3.0-3.1 aren't even mentioned! If they still insist, you'll have to troubleshoot the computer you're trying this on. I've had varying success running those old emulators on mac vs. windows. Try lowering the ram that the emulator requires.
I am trying to switch my android development environment to a scala-based one, but the turn-around times (caused by stripping down the scala libraries to the used parts only using ProGuard) are killing me.
There are some tutorials available regarding a process of pre-installing the scala libraries in the emulator by creating a new ramdisk image and adding the libraries to the so called BOOTCLASSPATH. The result should be, that I do not need to integrate the scala libs into my debug build anymore and thus can dramatically decrease the turn around times (one such tutorial is available here).
I've followed these tutorials and it is working fine for android 2.3.x (API level 10) but when applying it to an ICS emulator (API level 14/15) or the Jelly Bean emulator (API level 16) they get stuck in a boot loop after the modification. The ICS emulator is especially important to me as I am using the x86 image with hardware accelerated emulation as it is so much faster than the ARM images.
Any ideas on how to pre-install the scala libraries on an ICS emulator or above?
After searching around a little bit longer I stumbled across the Android-Scala-Installer which allows to pre-install the scala libraries on a rooted android device. It uses another mechanism: Instead of adjusting the BOOTCLASSPATH it defines additional permissions which can then be referenced in your AndroidManifest.xml using a <uses-library /> statement.
Unfortunately the installer isn't working on an emulator, but I've applied the general mechanism and created a scala script which completely automates the whole installation process for the emulator of your choice and works fine for x86 and ARM images -- simply call the script and it will start the emulator and do all the installation stuff and you are done. Currently the script only runs on Windows.
The script currently brings the scala 2.9.2 and 2.10.0-M7 libs bundled and can be found at github.
Tip: To save myself from adjusting the AndroidManifest.xml when switching between debug and release builds I've split my app up into an android library project which contains all code of the app and two application projects -- both referencing the library project. One of the app projects is for the debug builds and contains the relevant <uses-library /> statements and the other project is for release builds and includes the scala libraries into the build process, so that they are part of the delivered APK.
Hope this will be useful for someone else too.
Just wondering I have searched but I have not found an answer. My question is I installed the latest sdk 4.0 platform. I am testing with a Samsung Captivate which runs on 2.2. When I debug I get the error about them being on different platforms. My question I quess is probably stupid, But can I ever use the captivate to test my apps I build in platform 4.0 or must I stay at the 2.2 level? New to this....Can I update my phone or just test using the 2.2 platform.
You will only be able to test apps that your phone supports. You are able to target different versions of Android (in Eclipse, right mouse click on your project then edit the Project properties - target a lower version of the OS).
Bottom line, if you are writing apps that target a specific version (in your case you wrote something for 4.0) the device you use must support that version of the OS.
You can set the version you target, which will allow you to debug on your device.