As the title suggests, is there a difference between installing an app from an .apk file from local storage (i.e. SD Card) and installing the same file through adb? I'm noticing different behavior based on these methods on installation. Any help would be greatly appreciated!
EDIT: In case someone stumbles upon this in the future, I want to provide an update as to what was causing the issue. I was experiencing the same issue as outlined in this question: How to prevent multiple instances of an activity when it is launched with different intents. I was able to pick up the issue by using the following command while my app was running:
adb shell dumpsys activity <package-name>.
This allowed me to view the back stack and I noticed that when I resumed the app after hitting the home button, new instances of the activities were being created, but the old instances were in the back stack.
When you use adb you are invoking the debugger too. It resets the whole package's variables and data each time you run it.
But if you just run it like a released software you may not be releasing or resetting everything and have things that persist between using your app.
Related
I'm looking to build an app that will restart my device at a specified time, then open up a couple 3rd party apps in sequence and run their feature/s.
For example: I would like to automatically restart my phone at 5am. Then have it open an antivirus app of my choice and run the scan. Then close that app and open up another app and run it's cleaner function.
I have experience coding, but I'm just starting to take a peak into android app development. So, I was wondering if this is something feasible to do.
Any advice would be appreciated!
I am not sure about the starting phone at the desired time, but I am sure you can start applications on boot using "init". Linux systems support that, and android does as well. But it completely depends on your kernel.
Read here about init.d.
Check if your phone's kernel supports init.d. Check here if your phone doesn't have init.d support.
Check Here for running a script at boot. It is quite useful for custom scripts.
Check Here for running scripts/application the application at boot
Create a script according to your needs and I think you would be able to achieve what you are looking for. <- Custom Rules
I would have commented but apparently I can not since I am new here.
I hope I was of some help. Will look into the android starting part and get back to you.
Cheers.
STEPS-TAKEN: Not sure what the source of the problem is, but the quick description of the bug is that:
I install all required software, SDKs, configs,
Then create two new projects each using the tabbed-window template, each of which support deployment to Android.
Then I run one project via Titanium Studio's Run option, let the Android Emulator load, and confirm it's the app is installed an working.
Then I closed the emulator, and then run the other project the same way as the last, though when the app is shown on the screen it has the name of the first app, not the app run.
FIXES-TRIED: I've attempt executing "Project >> Clean" for all projects before the second run, and still get the same "bug".
SETUP: To my knowledge all of my configs are correct, and clearly the build "works" though it is very possible there is something wrong with my installation build chain to get to the point I'm running the app in Titanium Studio via the Android Emulator.
ERRORS: I've reviewed the console output for FastDev, AppInstall, Android-Emulator, etc and have seen no error messages that jump out; meaning I have seen no error messages, except for build.py error after the first script runs saying it didn't find the script running on a port when it attempt to kill it; given the request is to kill itself, and it's not found, I just assume this is a confusing way of saying the script did what it was suppose to do.
Current build: is on Windows-XP-SP3 using TiStudio 2.0.1 build, JavaSDK 1.6, r18-Android, and Android-2.2
Recent emulators have persistent state, so your second launch probably gets back the system you were running before.
You should not have to resort to this on a regular basis unless something is broken in the workflow, but deleting the AVD and making a new one should get you a clean slate.
I believe there is also a startup flag to the emulator which tells it not to use the checkpoint from a previous run, but start from scratch - you could try to change your configuration to use that flag.
A downside to either deleting or forgoing checkpoints is that the emulator will take longer to start up.
Really though, you are supposed to be able to re-install or launch a given application, or install a completely different one, all within the same running of an emulator. You aren't supposed to need a new emulator, any more than you need to go buy a new device (or perform a factory reset on it). So something is not right in the setup, and the best solution for long term productivity is to identify and fix that. Short term of course, you might need to wipe the slate clean if that helps you meet today's deadline.
I have a suspicion that this might be due to my running a custom rom... but I figured I should at least come by and ask here.
I'm working on an app that uses some SharedPreferences. Everything in that aspect works fine, but after completely uninstalling and then installing again, I found that my SharedPreferences values were still being picked up. I ended up uninstalling and then pulling up an adb shell and found that indeed... under /dbdata/databases/mypackagename/shared_prefs/ there were still files there. I would assume that they should have been removed...
I'm using a Samsung Captivate running the Serendipity rom... Again, I can only imagine that that has something to do with it, but I'm not certain.
Edit - I just completely wiped clean and put on the Firefly Rom and tested this out, experiencing the same thing. Is this possibly a Froyo bug (both have been 2.2 Roms)?
Try this on a stock ROM, I've never heard of this problem before.
It is probably the custom ROM. When an application is removed or the Clear Data is clicked in the settings, it not only removes the the application, but also the data that is specific to it.
A custom ROM will not always do it, it would remove the application but store the files.
For the most part, the reason is accessibility, in the sense that when you say uninstall an app (i.e. Game) because of frustration, when you come back, you data is still available for use.
As developers this may get annoying but may users tend to like the ability to reinstalling an app and having the same information.
while i compile my application on sdk and on my phone i see the same application 3 times over the phone. Only 1 of them works and the other 2 throws exeption. this is the printscreen of the problem.
That sounds very much like you've marked all the activities in your application with categor android.intent.category.LAUNCHER --- that's what makes the activities show up in the launcher. Naturally, if one of your activities gets launched when it's not expecting to be, it'll likely crash. But you'll have to post more info (like a stack trace) to tell for sure.
When working on an emulator, you can choose to wipe all user data on boot from the AVD manager. You might want to give that a try.
Also, as Kartik said, if you changed the package name of the application, it will install alongside the previous versions as Android sees it as a new application and not as an upgrade.
So, I have found a bug in a specific sdk that causes it to fail on some Android phones after re-installing a new version of an app which uses the sdk (via adb install -r, and presumably when a user gets an update that has been pushed to the Android market). Is there any way to force an application's data to automatically be cleared upon update of the app? I realize there are different ways that data could be stored, but I just need to essentially simulate an invocation of the "Clear Data" button that'd you find when browsing to the application in the "Manage Applications" section of the Settings (i.e. I just want all data gone).
I am an Android noob and am doing minimal Java coding on this project, so I am basically looking for the simplest solution here. I suppose I could settle on storing a "currentVersion" to disk and then checking it upon launch every time to see if the real current version matches the version that was written to disk on the last launch. Is that the only real way to do this? If so, what's the simplest way to do so?
Thanks!
Is there any way to force an application's data to automatically be cleared upon update of the app?
No, at least for my definition of "automatic".
I suppose I could settle on storing a "currentVersion" to disk and then checking it upon launch every time to see if the real current version matches the version that was written to disk on the last launch. Is that the only real way to do this?
I'd name it lastKnownVersion, but otherwise this approach seems sound and probably is your only viable option.
If so, what's the simplest way to do so?
Ummm...do exactly what you said. Use Java I/O (storing the file somewhere inside of getFilesDir()), or SharedPreferences.
Bear in mind, though, that your users may get rather frustrated if you blow away their data on an app update. Personally, I'd rather we find a better solution to your original problem ("I have found a bug in a specific sdk that causes it to fail on some Android phones after re-installing a new version of an app which uses the sdk").