Suppose we have an Android APK file which contains only a single BroadcastReceiver.
Will this form of the APK file be installed on Android devices be installed successfully and can the BR receive intended intents? I thought it will, but my experiment showed it does not. I am not sure why, but the installation of such APK files (with a single BR) seems to fail all the time.
A solution to this problem is to add a dummy Activity to the package. Then the installation succeeds, and the BroadcastReceiver can receive all intended intents!
Please share your opinion on this matter.
I always thanks you all for helps!
Will this form of the APK file be installed on Android devices be installed successfully and can the BR receive intended intents?
No.
I am not sure why, but the installation of such APK files (with a single BR) seems to fail all the time.
No, but the BroadcastReceiver will not receive broadcasts until something has directly invoked one of your components via an explicit Intent (i.e., an Intent that identifies the class). Normally, that will happen by the user launching your LAUNCHER activity. This has been the case since Android 3.1, about three years ago (see "Launch controls on stopped applications" in the Android 3.1 release notes).
You need at least one Activity for landing page in the android app. What are you expecting will happen when the app is launched manually?
Related
we have build Android from sources and it looks good on our device. Currently we need to make own OTA process, but we dont know how.
We try to implement FSLOTa (https://github.com/embest-tech/android_packages_apps_fsl_imx_demo/tree/master/FSLOta) against our http server, but documentation is very poor - so we simply add source to our source and compile it.
Problem is, that we see app in our box, but it doesnt nothing.
Or there is way to modify built in OTA app, when we change server to our server, we get http request at least. But we dont know, how tells http server to box about new version - any manifest file? XML, JSON or? Is there any example?
Or is there another simple way for implements OTA update to AOSP?
Thank you very much
D
I dont know about FSLOTa nor do I know about the device you are working on. But If you want to implement your own OTA process you could try the following (Just a short draft since your question is very broad):
Create a system app that checks from time to time your server for new packages.
if it detects a new package it downloads it to your device.
it copies the downloaded update.zip to /cache/
Then the app creates the following file /cache/recovery/command and writes --update_package=path_to_your_file in it. (For more commands see /bootable/recovery.cpp)
Then it forces a reboot into recovery
recovery installs your ota package.
Update:
I quickly checked the app you linked. I would check these things:
Do you get till the point where RecoverySystem.installPackage() is called ? (https://github.com/embest-tech/android_packages_apps_fsl_imx_demo/blob/master/FSLOta/src/com/fsl/android/ota/OTAServerManager.java#L282)
Do you see a message in logcat from the RecoverySystem that it is going to reboot? (maybe you have a permission problem and your app is not allowed to force "reboot recovery")
Is the path to your update.zip correct? (it should be in /cache/)
i have been developing an OTA updater android application, you should know application send request to backend server and receive a JSON file about the available update. everything iiiiiiiiiiiiiiiiiiiiii anwserd was ok on non/AB devices, but for A/B devices, the android application downloads the OTA package under /data
and installation will not happen in recovery or anything, the changes will apply to the unused slot before REBOOT.
Just starting with android.
I try to create project that will send notification ( some bit for example ) to my FTP server every 3 hours.
I don't know how to create this project because each time i create new android project i must have only project with activity - and i don't need any activity - just need a service that will run when i install it on the device.
each time i create new android project i must have only project with activity
If you are using Eclipse, uncheck the "Create activity" checkbox that tells the new project wizard to create an activity.
If you are using android create project, yes, it will create an activity for you. You can delete the Java class and the manifest <activity> entry if you want.
In reality, you will wind up leaving all of it alone.
just need a service that will run when i install it on the device.
First, a service does not run just because you install it on the device. It only runs if you write code to cause it to run.
Second, while you might think "well, I will just get control at boot time and start the service then", that is possible, but it will not work on Android 3.1+ devices unless the user has run an activity first. This is to prevent "drive-by" malware.
So, I suggest that you leave the activity in there, if you want your app to work.
Moreover, unless this app is only for yourself, your users need the activity, to:
Control the behavior of the service, such as changing the "every 3 hours" setting to something they prefer
Read your license agreement
Read your documentation, including how to get support
Etc.
I'm looking at the description for the Plan B app here: https://play.google.com/store/apps/details?id=com.lookout.labs.planb. It says it will start automatically after installation. How do you configure an app to do this?
Register to receive common intents. One especially suitable for your purpose is:
"android.intent.action.PACKAGE_ADDED"
You might also listen for other intents such as BOOT_COMPLETED, etc.
Edit: According to another Stack Overflow answer, You can't run your own application immediately after it's installed. You must register for other intents as I suggested. Something to note is that you app will require user permission to receive the BOOT_COMPLETED intent.
Update: As pointed out by zapl, post 4.0 you cannot do anything after install now until the user explicitly launches your app.
So, we were coding an Android application in Eclipse, and we couldn't figure out why a class wouldn't delete. We removed it from the application completely, and it was still there. Then we found out that it was actually pulling in the information from another application. Does this usually happen?
EDIT: More information:
The problem only happened when we built on 1 of the three devices, the one that had the App it was pulling information from. On the other 2, it wouldn't run at all. The other App had a different name, signing key, and was a different project.
EDIT 2: It happened again. There is an app called SMS.apk, and the second is called 2012.apk. The class names are different, and the project names are different. There are no references to eachother in the files at all. But it was pulling in code from SMS to 2012. It worked, until we removed SMS, when we realized that it was using that code. At this point, we are a little worried we accidentally stumbled upon Skynet.
No, Eclipse does not do that. The reason this is happening is most likely because its an SMS app, so you're using broadcast receiver. Heres a tidbit from a helpful book:
One interesting characteristic of the BroadcastReceiver is that you
can continue to listen for incoming SMS messages even if the
application is not running; as long as the application is installed on
the device, any incoming SMS messages will be received by the
application
Source. pg. 273
I implemented a BroadcastReceiver for the Android Market INSTALL_REFERRER Intent as
described here:
Get referrer after installing app from Android Market
It works fine for android devices earlier than 3.0 but it never seems to fire on Honeycomb devices. I've checked the logcat output during the install and after the app's first launch and I don't see any of my debug output which leads me to believe that the BroadcastReceiver isn't being run (I do see the output on pre-Honeycomb versions).
Can anyone out there confirm this problem?
Any idea how to make it work?
There's a new flag called FLAG_EXCLUDE_STOPPED_PACKAGES in 3.1:
If set, this intent will not match any components in packages that are currently stopped. If this is not set, then the default behavior is to include such applications in the result.
From the release notes for 3.1:
Note that the system adds FLAG_EXCLUDE_STOPPED_PACKAGES to all broadcast intents.
And also:
Applications are in a stopped state when they are first installed but are not yet launched and when they are manually stopped by the user (in Manage Applications).
Seems like this is breaking the behavior of INSTALL_REFERRER in 3.1+ devices as your app has not yet been launched and so can not receive the broadcast. Sadly I don't know of any way to make this work. Google could probably do something to fix this in their Market app (one way would be to just use FLAG_INCLUDE_STOPPED_PACKAGES though I'm not sure that would be a great idea, given the whole point of these new launch controls).
As i experienced the Broadcast Intent *INSTALL_REFERRER* is fired once before the Application is launched the first time If you don't catch it there, you'll never get it again