I'm guessing everybody who does Android programming has on their own created multiple AVDs for various devices for testing purposes. I didn't really want to add to the "reinvent the wheel" club, and was hoping someone could point me to an article that lists out various AVD configurations, or a site/link to download already created AVDs to copy into my Eclipse environment, or scripts to create the AVDs via the command line, etc.?
The only thing I've been able to find so far via Googling is this blog article...
http://mobile.tutsplus.com/tutorials/android/common-android-virtual-device-configurations/
Be nice if a bunch of already-created AVD configurations shipped with the Android SDK, for the various popular Android devices.
Thanks in advance for any advice/info.
What you are looking for (namely a list of AVD configurations that will model different physical devices) does not exist. It doesn't exist because the options available in the emulator are very general, and do not model what you will find on an actual device. As the blog article states:
If you own one of these devices, you may immediately notice that the
screen doesn’t look the same (software-wise). The emulator does not
provide third-party add-ons, such as the HTC Sense UI.
That is huge. Third-party software changes the visual look and feel of the application significantly.
It is currently quite difficult to have a consistent look and feel in Android between different phones and providers, but the solution to the problem does not lie in an AVD configuration. The primary problems are related to different hardware, strange things that different providers stick in to the views, and differences in the images that are included for button backgrounds and things of that nature. The two biggest and most important emulator settings are screen size and version. Beyond that there isn't much. No one is going to create detailed emulator setting for each phone because those emulator settings have little to do with how the phone is going to work. From my own experience, every phone is different, and there almost certainly will be bugs specific to each model of phone. The emulator will show you almost none of that, which is why no one is coming up with lists of emulator settings for all the devices--they're testing on the devices themselves.
Related
I want to modify the system apps running on my specific phone. I am stumped about some important steps on how to do that - see my questions further below.
N.B.: I am not interested in deploying these modifications to other phones. Instead I want to play with the original code and improve it. Hence "create your own system app" is no sufficient answer.
Background
I am just starting to get into Android development (have sufficient Java knowledge, though). There are plenty of great tutorials out there (e.g. here and here) but they all seem to cover user application development. I'm more interested in getting (a little) "closer to the metal". Unfortunately I am unable to find good sources teaching how to do that.
Example
As an example let's say I want to modify how the built-in brightness control works (e.g. changing the minimum) or want to add features to the call screen (e.g. "Send SMS instead" when the line is busy).
Specific Questions
I obviously need these things to get started...
Sources
The sources for (parts of?) the OS running on my phone. This is the part that confuses me the most. Can I just download the official sources or is it likely that my vendor made modifications?
In my specific scenario (I use a Fairphone), could those modifications be contained in any of these sources:
some core apps deployed by the vendor
the image binaries (some way down the page)
sources for the Linux kernel and some other libraries
Tools
I really hope to stay in Java-land. But either case I need a development (I hope to use Android Studio or Eclipse ADT) and a debugging environment (I hope the Android Virtual Devices suffice).
Is it a valid assumption that I can use those tools for system apps or are they usually implemented in C?
Process
Assuming I can download the official sources and get started with, e.g. Android Studio. As opposed to developing a user app, do I have to do anything special to emulate the modified system app on AVD?
I'm asking because I assume that AVD already runs an unmodified version of that very app.
I am just starting to get into Android development (have sufficient Java knowledge, though). ... I'm more interested in getting (a little) "closer to the metal".
You can of course follow your own bliss, but you may find it pretty frustrating to learn Android development by hacking on the OS itself. You'll find yourself doing a lot of OS debugging and working with harder-to-use tools than normal.
Example
As an example let's say I want to modify how the built-in brightness control works (e.g. changing the minimum)
I realize this is just an example, but this could be a tough one, because there are a lot of things that contribute to brightness control -- there's the app with the UI that sets it, but that talks to the framework and ultimately the driver for the hardware that actually deals with brightness curves for the display, in coordination with the ambient light sensor.
or want to add features to the call screen (e.g. "Send SMS instead" when the line is busy).
There's a dialer app, but implementing a feature like that will be...difficult, provided it's even feasible. I don't know offhand whether that sort of call state is available to the API.
Specific Questions
I obviously need these things to get started...
Sources
The sources for (parts of?) the OS running on my phone. This is the part that confuses me the most. Can I just download the official sources or is it likely that my vendor made modifications?
If you're replacing system apps, you'll need to run an OS signed with debug keys; you don't have access to the signing keys for the installed system apps on a retail build of the OS that would enable you to replace them. That will mean either getting a debug-keys installation or building it yourself from source, and flashing it to your phone. I would most strongly discourage you from using your daily phone for this sort of work -- you don't want it to be bricked when you need to receive an important call.
If you're not running a Nexus phone, then yes, your vendor has made modifications. The system apps are probably modified, and you almost certainly won't have access to the closed source of those apps. Also, there will be closed-source device drivers that are essential to the operation of the OS that you won't have access to. If you're trying to get AOSP Android up and running on such a device, as an individual hacker it's at best very, very difficult. If you're willing to use something like CyanogenMod, you could look to see if (and to what extent) they support your hardware.
If you are running a Nexus phone, then it's a goal of the AOSP project to try to have the OS bootable on select Nexus devices, though you won't necessarily enjoy the fullest functionality of the retail OS build, depending on the state of drivers -- even Nexus phones can have closed-source drivers and bits that make life more, um, exciting for building with AOSP.
In my specific scenario (I use a Fairphone), could those modifications be contained in any of these sources:
some core apps deployed by the vendor
Almost certainly
the image binaries (some way down the page)
Not sure what you mean by that
sources for the Linux kernel and some other libraries
It's unlikely there are significant modifications to the kernel itself, though vendors sometimes do...interesting...things with system configuration. I already mentioned device drivers. Vendors also have custom implementations/modifications of some framework APIs.
Tools
Vendor-specific tools are rare.
I really hope to stay in Java-land. But either case I need a development (I hope to use Android Studio or Eclipse ADT) and a debugging environment (I hope the Android Virtual Devices suffice).
Much of what you want to do can probably be implemented in Java, though it depends on how close you're getting to the hardware which can be difficult to know.
Is it a valid assumption that I can use those tools for system apps or are they usually implemented in C?
The "system apps" are implemented in Java, but again, you sort of have to know where the dividing line is.
Process
Assuming I can download the official sources and get started with, e.g. Android Studio. As opposed to developing a user app, do I have to do anything special to emulate the modified system app on AVD?
That's actually different, because you're dealing with an emulator system image instead of a phone image. The emulator system images are completely open source, and you can build them from AOSP.
I'm asking because I assume that AVD already runs an unmodified version of that very app.
That's correct.
To come back to my initial point, if you read between the lines of what I'm saying, I won't tell you it's impossible, but the difficulty ranges from freakin' tough on the easy end to spend-years-of-your-life on the hard end. If you really want to proceed, your best bet may be to buy the phone that's best supported by CyanogenMod and work that angle; there's a more active developer community there to help you. I know you're more excited about trying to customize the OS than you are in making a user-space app, but you'll experience less frustration with the latter than the former.
I have about had it with Eclipses emulator and its bugs/lack of power.
are there any emulators you guys suggest?
I would prefer one I could install on my PC (In a VM or on a USB stick or something) on a separate partition or whatever needs to happen.
I would prefer one that can go online but really, anything but the default I would love.
I have also tried Blue Stacks, I don't really like it.
You asked a lot of questions, and the answer is complicated based on your specific needs.
If you have an Intel Processor (and don't play to use Google services - like location, or GCM) - the HAXM emulator is great. It is included in the standard SDK, and works well.
There are many ways to optimize the standard emulator, so don't necessarily dismiss it. There are a variety of ways to configure it to be more powerful. It may not be perfect, but it works well (if you take the time to learn how to set it up optimally - most people do not).
Another alternative is Genymotion. This is a 3rd party, and they basically have optimized the emulator experience already, and done a lot of the dirty work for you. They also provide some of their own emulator management tools. I used it in early days, and found it buggy, but it is being constantly updated (recently updated, to remove the ability to use Play Services, like GMail, or Play Market - I am sure Google forced this, and is a bummer). Overall, this is a good tool, and probably a good suggestion.
Lastly, a lot of people use a physical device for development, which is generally pretty good. It supports Google, and Play services already, performs like a real device, and interfaces with the SDK tools well.
Every Android emulator will be able to connect to the Internet, so that is not a differentiator.
You can do what you want, but the documentations specifically states that you shouldn't try to run an emulator from Network attached storage (I would guess USB would not work well). You could create a separate partition, won't make a difference for any of these choices.
Bottom line, there are lots of options, learn a bit about the standard tools before abandoning them. They work well (if you learn how to use them properly).
You could consider moving over to android studio. It's based around the intellij Idea IDE and has a fantastic emulator compared to eclipse. It emulates in real time in the xml editor which saves a lot of time running the program.
Alternatively you could buy a cheap android phone over ebay or something similar and use it as an emulator. This is what I tend to do as I prefer to see it working on a multitude of devices.
I need to test web apps on a representative selection of Android phones and tablets. I don't have the budget necessary to purchase a large selection of physical devices. I'm looking for a collection of AVD files to use with the Android SDK emulator to accomplish this. Does anyone know of an existing repository or collection of these? Or do I have to make each one individually figuring out their specific resolutions, memory, Android versions, etc for each? I've created one based on the Nexus S definition provided in the SDK's AVD Manager, but I need Samsung, HTC, etc ones too and am not sure where to get them. Each phone manufacturers dev portal is a little different and I haven't found anything as straight forward as "Here's the link to our AVDs" on them. Thanks.
If you aren't required to use the AVD from the SDK, you should checkout genymotion. They use a dedicated virtual machine to emulate real devices, so it's really really fast. They've also custom made a bunch of real devices (phones and tablets) such as the Nexus 4, Galaxy S4, HTC One, and Xperia Z. It looks like they mostly support API 16+, but there's a preview for API 9 at the time of writing this.
Yes, there is this one, thanks to https://github.com/j5at and other guys:
https://github.com/j5at/AndroidAVDRepo
Or do I have to make each one individually figuring out their specific resolutions, memory, Android versions, etc for each?
You will need to define whatever emulator images you want yourself. The norm is to define some emulators with a mix of resolutions and OS levels, not necessarily specifically trying to hit any particular device model.
Bear in mind that there are plenty of virtual test services that you are welcome to take advantage of as well. You should already be familiar with these, as they are commonly used in Web development for testing browser/OS combinations that you do not have at your disposal.
Each phone manufacturers dev portal is a little different and I haven't found anything as straight forward as "Here's the link to our AVDs" on them.
There are no dedicated emulator images for the vast majority of Android devices on the market.
I own a Samsung Galaxy 3 and want to port kernels available for other Android Devices. I have all building environment ready. I have C knowledge also. What exactly I dont understand is how and what all things porting involves, which codes should be modified in what way?
If someone could help me. It would be great.
Thanks in advance.
Ok I got it. But the real problem is I dont understand one thing.
What needs to be changed in the source code so that to make it compatible in other device? Can someone explain me that?
Idolon gives a good suggestion. In theory what is written there is true. In practice, it's a little more involving. I've been porting Android Kernel for months now. My goal was to have a custom S5PV210 processor module on my custom board with my custom I/O. I have the source code for Samsung's galaxy tab and several Samsung's android smartphone as well as a few versions (Froyo, Gingerbread) for the Samsung's Evaluation board (SMDKV210 for S5PV210 CPU). FYI, S5PC110 is a close derivative. Here is what I found out.
Eventhough all the device drivers are supposed to be built in a very modular way and independent from each other and you should be able to replace them with similar devices, the way Samsung did it is not exactly that. To give you one example is about power management. In many low level drivers dealing with hardware devices, it calls some specific routine for other hardware devices like power management chip. So, When you change the choice of drivers in the "make xconfig" or "make menuconfig" it will remove the source code of what you don't want and add the one you want but, there are still other modules that are calling the low level function you removed. When building, you will get tons of unresolved external because you removed a power management chip that your hardware doesn't have but is used in the source you started with. I looked through several Samsung's device source code and they have branched very early on. They have been adapted by different teams and it would be a major amount of work to go from one device to the other from one source kit.
Here is how I succeeded: I bought an S5PV210 evaluation board with an already ported Android Kernel (Gingerbread). All the power management and inter dependant issues where already cleaned-up. Then, form a working kit, I could change the device I needed (the one you can't buy without a 100K unit/yr commitment) without getting stuck with the interdependancy. Then I could even change LCD resolution (from 800x480 to 1024x768), touchscreen, Cell modem etc etc. The whole thing takes about a month worth of work with only one guy (me).
Starting with a Galaxytab or other commercial device made me waste months of headakes with no useful results but the thing I've learned.
There is one requirement to succeed on my approach. You have to know the hardware you are working on. As an example, you need to know what touch screen your hardware has (chipset) to select the driver and were is it connected to hook it up to the right device (USB, Serial etc). That the same thing for all other devices (power managemnt chip, keypad, backlight, LCD etc etc)
Hope that is useful to give you an idea of the work involved and how you can do it.
You should take a look at the cached copy of Android Platform Developer's Guide and at android-porting google group.
There is also an old but useful article about porting Android to Nokia N810, which will give you some hints about Android Linux kernel porting.
I am also into android porting stuff for quite some time I suggest the following route :
Read
You need to have basic knowledge of android porting and AOSP source code, directory stucture hierarchy.
I suggest you to start reading https://books.google.co.in/books/about/Embedded_Android.html?id=plHsngEACAAJ&hl=en
and also refer https://source.android.com/devices/index.html as good guys pointed out you can also google android porting related groups and become a member there, if you are stuck on a issue there are chances similar issue might have been faced by someone else previously.
Observe
AOSP code :
Parallely you need to dive in to the android source e.g from links like https://android.googlesource.com/ observe which components are placed where in the source code, what are the updates from previous android release (like ART replaced dalvik in LL), at top level there would be generic code, code specific to your hardware called HAL in hardware/ and device/ folder.
Kernel code :
In the kernel also you need to observe the directory structure and know which things lie where like SoC specific code will be in arch/ directory defconfigs (used for selecting kernel configuration) will be arch//configs/ directory.
Also there are good books available for linux kernel, you can google them and start reading them also.
While porting kernel you need to take care of following
1.If in the new kernel there is already support of SoC which is used in hardware to be ported then you need to add only device specific changes like suppose you want to port new kernel version to samsung galaxy s3, you can take a reference android kernel having exynos support and then you need to make changes only for adding support for samsung galaxy s3.
For that you need to have reference of some old kernel having support of s3, from there you can study patches which have been added to add support for s3 and port those patches to newer kernel.
Experiment
First you can only port the bare minimum changes required to up the platform, compile and flash it on your platform, then observe the output, if everything looks fine than go on for next changes otherwise try to solve the issue.
Thanks,
Devarsh
I've recently purchased Samsung Galaxy Android phone after using Openmoko phone for 2 years.
One of the reasons for choosing Android was is that it's open sourced.
I don't want to depend on phone maker to provide updates for my phone. I'd like to do it myself.
Right now I'm in research stage if it's worth the time or not. So here are the questions:
I found some tutorials for building ROM images from source. They tell that Android build script will ask for make of the phone before building kernel. Does it mean that all the phone specific stuff is handled by the script or I will have to do some voodoo before I can flash it onto my phone?
Drivers. How are they handled? Are they included in the source as binaries and added automatically (question 1) or will I have to dissect old firmware to get them and put in my build? I realize that would mean some problems with module/kernel versions compatibility.
Is there is something I'm not aware of that would prevent me from building my custom firmware or make it very time-consuming?
I'm not afraid of installing SDK's and toolchains, after all I'm an Openmoko owner.
It's gonna be a little more complicated than that.
On any consumer Android phones I've seen, the user doesn't have root access to the OS. So step one, would be finding an exploit to get root.
Even after you get root, all consumer Android phones "lock" the bootloader to prevent unauthorized OS images from being booted.
The Android OpenSource project only contains device drivers for a small number of phones (Google dev phones, possibly the Nexus One?). For other phones, the drivers are proprietary binaries that the manufacturer loads on the phone. They generally aren't available separately.
Even with all of those obstacles, some enterprising smart guys have managed to create custom "ROM's" that blend the OpenSource release with drivers ripped OEM install on the phone, etc. CyanogenMod is one of the best known and is available for several different Android devices, but unfortunately the Samsung Galaxy does not currently appear to be one of the device supported by Cyanogen.
I found an old link here to a guide to getting root on the Galaxy and loading a custom ROM on it, but unfortunately the ROM they link to doesn't seem to be actively maintained anymore. It might be worth doing some more exhaustive google searches to see if you can find anyone doing active development on the Galaxy.