Before reading this, note that I'm not talking about capturing the screen.
Motivation
Many times, in order to test apps, we need to go over many activities (including a loading/splash screen) till we reach the one we've just updated in order to test it out.
I want to reduce this time , by capturing the exact state of the app (memory,preferences,activities stack,...) in order to go there again.
Another example : The QA team could show me in which case a bug occurs, without having to show me the whole process till they got there (since it might not be reproducible) and then I could run the app, and know exactly where the exception was thrown and go there directly via the DDMS's logs .
Another example: We work on a game, and the QA team have tested the game for hours and reached a certain stage, and would like to save the current state of the app in order to test it from this point and make multiple tests on it, instead of running the app from the beginning each time , wait for it to load and also finish all of the stages till they reach this stage.
I think there are other scenarios where such a thing could be useful.
The problem
Such a thing is probably possible in the VM world (for example virualBox) , and it's probably possible for android emulators (at least according to this post , but they also say it's "finicky" , not sure what that means in this context) , but not for devices.
The above example, though they might work, they work for the entire OS and not for a specific app, so even if I choose to use them, it takes a long time to use (plus I need to use an emulator which is usually much slower than any device) .
I'm pretty sure that the current API doesn't support such a thing (and it's probably a good thing, for security reasons).
The question
Is it possible to capture&load entire app state by using ROOT ? Maybe by being a system app too?
Maybe there is already an app for this task?
Since it's very usual that an application saves its whole state in SharedPreferences and persistence in DB, in most apps you can backup and restore data and state using adb backup and adb restore, respectively:
Backup:
adb backup -f app.ab com.company.app
Restore:
adb restore app.ab
PS: This feature was introduced in ICS, and it's not required to be root.
More information in this tutorial.
Related
I have a Delphi application and my main form has an onCreate event with code that I only want to run once and the first time the application is opened on a computer.
So let's say I download the app from Google Play Store or Microsoft Store and run it for the first time, then my onCreate code must run. But if I open the app for a second time then the code must not run again.
What would be the best way to do this? I'm looking for a cross-platform solution that will work on all FMX supported platforms.
(I was thinking of simply creating a hidden text file somewhere and if it doesn't exist then it means the app is opened for the first time and thus run the onCreate code. So any other ideas or ways?)
I've concluded that simply creating a text file on the computer and checking if it exists or not would be the easiest and fastest way to see if the user has opened the app before or not.
Someone in the comments did mention about using SharedPreferences on Android and NSUserDefaults on iOS, but I've decided that text files would be the best for my case.
I would like to know if it is possible to have a process that would constantly run on the phone and would track the number of times a user taps on the screen.
For example, the user downloads a game, plays and then quits the app and although he quit the app, this process that got installed together with the app will still run and all that it would do, is that it will increment a value every time the user taps on the screen and then remember the said value, in order to be used the next time the user starts the app.
I don't know if this is a simple question or not but please keep in mind that I am new to Android development and I did not find any related topics on this.
Thank you in advance.
Yes, it is possible. Using certain flags on your service, you can create a system-wide overlay that should allow you to catch all click events systemwide. However, keep in mind that it seems that Google have tightened up security in Android 4.x, so you may have trouble getting this to work on more up-to-date versions of Android.
For specifics about implementing this, see this question: Creating a system overlay window (always on top)
I'm building an app that will be bundled with an equipment. I want to block all access to Android settings, there is not physical button to go back, only touchscreen. So this won't help: startActivity(new Intent(android.provider.Settings.ACTION_DATE_SETTINGS));
I want to change time and date of the device through the Application. I researched a lot and every solution I've found to change time and date programatically in Android seems to be over complicated (putting the app inside system/app or something).
As I've come to know, having superuser access and declaring SET_TIME on AndroidManifest only doesn't help.
The application must display hh:mm dd/mm/yyyy
In my App settings, the user may set the date as being 13/01/2014 (dd-mm-yyyy), but let's say today is 10/01/2013. In my app I would do something like this today+offset (3 days). The same goes for the clock.
I was thinking in creating a thread that keeps track of the current time to update the text field with the current time (+offset defined by the user) every minute and another to update the date (the machine may work for a very long time), where I format it using the offset the user configured in the App. I don't like this solution, however I'm not sure if Android has another more efficient way to do this kind of task.
So the question: Is there a better way to do it other than using threads?
I was thinking in using a thread with postAtTime(), I guess it's more efficient than being inside a loop and checking if the time/date has changed from time to time.
I found out the answer I needed here: Setting system time of ROOTED phone
My Android device is rooted and using CrazyCoder solution worked. Although it will not work on Android emulator, but with rooted device.
I am trying to create a benchmarking app that launches a few apps and measures the load time. Starting a timer and launching an app (via intents) is the easy part. And, if I have source to the child app, I can either have it record the time and pass that back, or I can just have it kill itself completely at some point. But, how do I know when stock apps have finished loading? Or, how can I make them close automatically so that mine is brought to the foreground again to stop the timer? I know the source for stock apps is public, but I don't think it's practical for me to try to modify it. Or is it? I can't tie my benchmarking app to a specific version of Android.
Specifically, I'm interested in measuring load times for the browser, youtube, and mail.
I've looked at using the ActivityManager to get info about running apps, but I think in that case I would have to poll in the background, and I've read that ActivityManager info is not necessarily always up-to-date, anyway.
Any suggestions would be very much appreciated.
I decided to just modify the source and build a version of my app for each version of Android/processor. I won't have to target each device specifically, just processor families (Atom/armV7/etc.)
Getting and compiling Android source is easy
Building a custom version of a stock AOSP app is also not that bad
From there, it's just a matter of using intents to invoke activities and pass information.
Basically i want to perform some database interaction at the time of uninstall
I am sure this is not possible in Android.
Because there is no methods/API exists to program for the uninstallation time.
You can't do this in Android.
De-installation of an application is managed by the operating system, and requested by the user in the device settings. The application itself is not started in any way, and there are no hooks in the manifest that you can use to request that some code is run when the user elects to uninstall.
Is your use case as simple as "do this upon de-installation"? Android will wipe any preferences and databases anyway, so once complete the worst case scenario is that you've created files that are left on the phone or SD card.
Alternatively, is your use case something slightly different (for example, trying to restrict the number of devices your software is installed on)? In which case, if you widen the question to describe what your end goal is, we might be able to help more.