I have the following problem: I need to run an android app in an emulator, get to a certain state in it, after which I want to fork the process into two and do different actions in the app starting from that state.
Example: I want to open Yelp in the emulator, after which I want to search for "Coffee", then fork the process into 10, and in each child process open different coffee place.
The particular problem is how to perform the fork.
I've been trying to explore solutions to this problem, and found no easy way to do it. The options I explored the possibility of so far are:
Actually fork the app process within the emulator. This appears to be completely impossible.
Somehow fork the emulator process with an app running in it. There's no easy way to fork an external process, so I guess I would have to change the emulator code to fork from within when certain external event happens.
Put the emulator in some sort of a VM, which supports hot cloning. I haven't found any VM that actually supports it without serious downtime.
Ideally I want a solution that doesn't double the memory (similar to how fork in Linux works), and that is not associated with a significant downtime, though any solution that doesn't have the above two properties would also be acceptable.
Okay, that's quite the task. Intuitively, I would expect option 2 to be the most promising.
Alternatively, have you considered writing an UIAutomator script and having it run in parallel or consecutively across a few devices? The bonus criteria would definitely not be met, but after sufficient runtime you might get what you're looking for.
Bring emulator into the state at which you want to fork
Save snapshot
Spawn emulator, specifying snapshot
Run UIAutomator script
Record findings
GOTO 3
Related
If what I ask in the 'Questions' section can't be done, then the rest of this post is moot. Look at that first so you don't waste your time reading the background I provided if it turns out to be impossible.
Questions
My server is an AWS m4.large running headless Ubuntu. As far as I am aware, it does not have a GPU, although I have RDP'd into it in the past in order to do something that needed a GUI. Before anything else, I have a few questions about whether certain things are possible:
It seems to be possible to run an android emulator on a headless linux server, but is it possible to run an app with graphics despite not having a GPU?
(If so) is it possible to get an image file out of what the emulator is currently showing?
(If so) is it possible to emulate mouse functions based on X/Y coordinates despite it being run headlessly?
Work Done So Far
I'm currently trying to create an API for a mobile game that doesn't have one. So far, I have a clunky prototype written in Python (running on my Windows PC) that does the following (When the code starts, the app is open to a scrollable list of users in a "guild"):
Grabs a screenshot of the android emulator running the game
Searches the image for certain predefined "template" images (player names in the list)
Clicks on its location if the template is seen (opens player's stat page)
Uses OCR to read information on the page
Returns to the list and repeats from Step 2
If no templates are found, the program scrolls down and then repeats from Step 2
If all data from the predefined users is collected, the program ends
Issues with my Prototype
Python code must be run manually when the emulator running (and at the right page in the app)
The PC can't be used while the code is running since it uses image parsing of screenshot and mouse functions
It's not practical as an "API"
Next Steps
If the things I mentioned in the 'Questions' section are possible, then the rest should just implementing the code from my prototype, and having it repeat on a schedule.
If anybody has ideas for accomplishing the same thing in an easier way, I'm absolutely open to suggestions.
Thanks for reading!
I'm trying to build a limited-functionality Android system for our device, which needs to boot quickly, but everything we do seems to slow it down.
For example, our device has no camera, no bluetooth, no wifi, but turning them off wholesale in various /system/etc/init/*.rc files seems to actually slow it down, due to the interdependencies of Android. The services that are turned off end up restarting, or causing timeouts in Settings, for example.
(Android is on the device for its' UI, not for its connectivity abilities.)
Do you have any suggestions for how to do this? Surely Android for cars, TVs and tablets have had to deal with these issues before.
You did not specify what you did exactly, but if you tried to not start HAL services on startup they might just be started dynamically later. If you are using Android 8 or newer you could merge multiple HALs in one process. But I doubt that this will give you any significant speed-up.
Android does provide a guide on how to optimize boot times: https://source.android.com/devices/tech/perf/boot-times. However, you will notice that they focus on the bootloader, kernel, file system, SELinux, and parallelizing init. The elephant in the room is Zygote. It takes forever to start because it preloads the whole Android SDK.
From its history, Android did not care too much about startup times, because you typically do not restart Android. Instead, they rely on Suspend-to-RAM.
You should think about what you want to have your user experience early. Example: for Automotive Android, Google needs to support a rear-view camera that is available within two seconds after boot. They achieve that by a second, faster stack that provides first images before the application SDK is started and takes over. See https://source.android.com/devices/automotive/camera-hal
Quick version:
How could I trigger the event related to an screen touch in a given coordinate, regardless of device state?
Longer Version: My Problem:
I have users that are unable to touch the device (they lack body movement, due to cerebral palsy or strokes). I am then in the process of creating a device that monitorates other types of input (for instance muscle contraction, or even throat humming, among others).
The important part is that I have a circuit that emits a single command.
These commands must then be intercepted by the Android device, and execute its associated command, as if the user was normally operating the device.
Note the following: I will not have any Activity running. The purpose of the application is to interface the sensor with the device, and thus, I cannot make use of View elements.
I suppose what I want to perform is to create a mouse-like element for Android.
But I have not come with any way to either have an application be executed inside my own (where I would provide an automated moving "target" for the user to issue a command/click) or a way to perform an MotionEvent or KeyEvent.
While my research so far yielded no response, I would like to ask the following: Am I forgetting any part or directive of the system that could allow me to perform my task?
The final outcome, is a Service, this service is merely waiting for a signal, this is captured by a Receiver... this is where I am stuck.
You are going to have a very hard time injecting Events from your app into any other app, due to security reasons.
However, you might have better luck in native land, C/C++. So hopefully your sensor-wrapper will end up as a .SO lib which can be included in other projects...
Because what you're trying to do kinda sounds like what Espresso can do (it's a JUnit test suite that can inject Motion/Touch/KeyEvents into views)
However, you can compile your own image with some added accessibility apps that might get you there. But your idea is really not going to be applicable to just about any off-the-shelf android device.
I am going to input an answer here, to show alternatives for people that might have similar issues.
From the get go, the device is a stand alone object, that issues GET requests to an internal webserver in the Android device (I am using PAW server as of today, 26/10/15), and I can issue some simple commands.
Likewise, I am planning to to an Activity with a WebView, and a cursor that keeps on moving, and when the signal is received, it uses the onTouchEvent of the focusable object under it (still studying.)
I do understand the security "flaw" from what I am trying to do, but even a USB HID (Universal Serial Bus - Human Interface Device) wont work on what I am planning so far, due to the needs of the user.
Well, you can insert events while testing because Robolectric, espresso and all the others runs simulations. The best way to do the same in a real device would be sandboxing an app inside yours. That way, your app will act as the OS for the others. But that would be costly and the performance would not be good.
Another alternative is doing the same Xposed does. Xposed intercepts system calls to allow modding the OS without flashing anything, so maybe you could use the same hook (or Xposed itself) to add your listening feature. This will require root, but sounds a lot easier than sandboxing every app in the device or building a custom rom.
Have you looked into Android's accessibility features for developers? http://developer.android.com/guide/topics/ui/accessibility/services.html
Also keep in mind that you can use Android as a USB host to external devices, such as homemade trackpads, joysticks, etc (with a bit of hacking probably).
http://developer.android.com/guide/topics/connectivity/usb/host.html
As for what might be available on the OS already, take a look at the Accessibility menu in the Settings. Hope this helps!
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'm trying to develop an app that would normally be considered to be malware, but the customer's demands are very specific and logical. We have around 50-100 cheapset Android phones that are bolted down, plugged in, and the app is supposed to send some of the sensor data via tcp to a remote server. It sounds simple enough, but there are two features that I struggle with (since I'm not an experienced Android developer, and have never rooted a phone):
#1 The app should be always on. If it crashes, server should get the error report (stack trace), and the app should be restarted after 10 minutes one more time before giving up. Also, the OS could theoretically kill the app (although I did my best to minimize the memory usage). I'd like to somehow handle that as well.
#2 It would be great if the app could be remotely updated, or auto-updated, with no user interaction whatsoever (since there is no conventional user).
To implement #1, I see no other solution than to root the phone (AlarmsManager doesn't seem to work as I expected, and adding another application to take care of the first one just feels wrong). Is there anything I'm missing?
I don't know how to approach implementing feature #2 at all. If I put the app on the market and check the "keep this application always up to date" checkbox while installing it, will that work? I fear that the auto-update would not occur while the service is running, and even if it did, that the OS would not restart the service after installing the update (unless feature #1 is implemented). If I programatically download the latest .apk and open it, I still need the user to click the "Install" button. I'm even considering implementing the updateable part in some scripting language.
Is there a solution to these problems within the limits of Android API?
EDIT: Thank you all for your answers, you've been very helpful. It seems that the only way to make Android behave as a non-user piece of hardware is to root it. That's the only way to do silent auto-updates. Always on can then be implemented by enabling cron (AlarmManager apparently doesn't fire the event in case of service termination via crash, but it could be used by another trivial, non-crashable service to keep the first one running).
For #1 you can use an foreground service. I don't know how often you need to get sensor data, but what's the problem with AlarmManager? I don't see how rooting could help with #1 though. You can't really do #2 without rooting or building your firmware. If you install your app as a system app (in /system/app) you can use a hidden PackageManager to silently install the new version. Using Market/Play autoupdate should work as well, but you have no way to control the update schedule. And, yes, it won't restart your service, but if you use AlaramManager, this shouldn't be a issue.
All in all, stock Android is not exactly an embedded system that gives you full control, so depending on how much time/effort you are willing to spend, you might want to customize it somewhat (or find a custom ROM that gets close to your requirements).
Re: question #2, there are a few open-source (licensed under the Apache Software License 2.0) options you may check and see how it works.
https://github.com/lazydroid/auto-update-apk-client is the android client for the auto update service (i'm affiliated with), which is small, easy to implement and supports silent updates on rooted devices.
https://github.com/commonsguy/cwac-updater is written by Mark Murphy, however it might require you to run your own update server and I'm not sure about silent updates.