Alright, so I'm trying to implement Data Backup into my application, and have been following this guide. I've implemented my BackupAgentHelper using a SharedPreferencesBackupHelper. I don't get any errors, and I'm being sure to call dataChanged() after all preference changes, but when I test the backup (`adb shell bmgr run) I get this information in LogCat:
07-07 12:29:00.258: V/BackupManagerService(291): Scheduling immediate backup pass
07-07 12:29:00.258: V/BackupManagerService(291): Running a backup pass
07-07 12:29:00.258: V/BackupManagerService(291): clearing pending backups
07-07 12:29:00.258: V/PerformBackupTask(291): Beginning backup of 1 targets
07-07 12:29:00.289: V/BackupServiceBinder(291): doBackup() invoked
07-07 12:29:00.289: D/PerformBackupTask(291): invokeAgentForBackup on #pm#
07-07 12:29:00.297: I/PerformBackupTask(291): no backup data written; not calling transport
So for reference, in my manifest I've added:
<application
android:allowBackup="true"
android:backupAgent="com.kcoppock.sudoku.SudokuBackupAgent"
as well as
<meta-data
android:name="com.google.android.backup.api_key"
android:value="my_key_goes_here" />
and my BackupAgentHelper is implemented like so:
public class SudokuBackupAgent extends BackupAgentHelper {
static final String SCORES = "SCORES";
static final String BACKUP_ID = "sudoku_backup";
#Override
public void onCreate() {
SharedPreferencesBackupHelper backupHelper =
new SharedPreferencesBackupHelper(this, SCORES);
addHelper(BACKUP_ID, backupHelper);
}
}
and finally, in my main activity, I call for a data backup like this:
edit.putString(id + "_values", valueCache.toString());
edit.putString(id + "_hints", hintCache.toString());
edit.commit();
BackupManager backup = new BackupManager(this);
backup.dataChanged();
I've tried debugging, and it seems my onCreate() in SudokuBackupAgent is never called. Or at least it's never reached from the debugger. It seems it isn't finding any updated data, and I have double checked to ENSURE there is data to be backed up. Is there something I'm missing here?
EDIT: I should add, I'm testing on a device (Galaxy Nexus), and I've even tried using an exported release APK for testing purposes.
1) Put Log.i() into your onCreate, to see if it's called.
2) Logcat indicates that your function didn't write anything. Check if you have shared_prefs/SCORES file in your app's private folder (assumes using appropriate file manager on rooted device). This is the file you're attempting to have in backup.
Probably your preferences file is something else than this file, in such case fix your String SCORES to reflect real preferences file.
3) I tried to debug BackupAgentHelper.onCreate in my app, and it can be debugged after invoking adb shell bmgt... so it is possible to step here in debugger.
I had the same problem today with Android SDK 4.1. Using 2.3.3 versions, however, helped:
07-15 13:59:56.459: V/LocalTransport(61): performBackup() pkg=com........
07-15 13:59:56.469: V/LocalTransport(61): Got change set key=filehelper:../databases/database.db size=8208 key64=ZmlsZWhlbHBlcjouLi8kYXRhYmFzZXMvZXhwZW5zZXIuZGI=
07-15 13:59:56.469: V/LocalTransport(61): data size 8208
07-15 13:59:56.469: V/LocalTransport(61): finishBackup()
If you do not change your preferences data it will just back up once but not subsequently.
https://developer.android.com/reference/android/app/backup/SharedPreferencesBackupHelper.html
"Whenever a backup is performed, it will back up all named shared preferences that have changed since the last backup operation."
As other poster said make sure to have a log statement in your onCreate.
You can force a backup by:
// bmgr wipe TRANSPORT PACKAGE
bmgr wipe com.google.android.backup/.BackupTransportService com.kcoppock.sudoku
bmgr run
The default is com.google.android.backup/.BackupTransportService, but best to check for yourself with bmgr list transports.
You'll be much happier running against the local transport, not the default Google Transport. Check the dev docs on this.
Related
The Android open source code contains code such as this. Can anyone explain why and under which circumstances it is necessary to do SELinux.restorecon(File)?
// If Encrypted file systems is enabled or disabled, this call will return the
// correct directory.
mBaseStateDir = new File(Environment.getSecureDataDirectory(), "backup");
mBaseStateDir.mkdirs();
if (!SELinux.restorecon(mBaseStateDir)) {
Slog.e(TAG, "SELinux restorecon failed on " + mBaseStateDir);
}
Can we do it too often?
SELinux restorecon is used to restore the default security contexts on some files/dir.
The thing (which is not obvious) is that we also use it to apply context changes, and/or to ensure that the file contexts are as you expect.
Usually, we define/override default security contexts using semanage-fcontext, and then run restorecon to relabel files according to these new defaults.
Here the code tries to relabel mBaseStateDir but fails to do so. It could be that :
there is no policy supporting the default context associated to that directory (given it's path)
mBaseStateDir is mislabeled (context type is not apllicable)
user/process running that code doesn't have the sufficient permission to relabel the directory (even it just created it).
For my Android Project I tried to follow and implement Android Developers Data Backup Guidelines ( http://developer.android.com/guide/topics/data/backup.html ), but Data Backup and Restore doesn't work. Can someone help with examples?
With further investigation I figured out the steps to implement Android Data Backup and Restore. They are:
Add in Manifest xml file the following:
a. android:allowBackup="true" (This enables Android’s Data Backup Service)
b. meta-data android:name="com.google.android.backup.api_key"
android:value=”{Your unique Registration Key for Android Backup Service}” (You must register your application package name with a backup service. To generate a key, go to http://developer.android.com/google/backup/signup.html )
c. android:backupAgent=”.MyBackupAgent” (This is the name of class that implement’s your declared backup agent class). Note1: The first character of the name is a period for the purpose of a shorthand to locate your “com.example.project.MyBackupAgent”. Note2: If a run time Exception occurs (this may or may not happen depending on your project stucture) such as: java.lang.ClassNotFoundException: Didn’t find class “com.example.project.MyBackupAgent” then I suggest you Decompile your apk (Upload your apk package in http://www.decompileandroid.com/ ) and search for the absolute path to your MyBackupAgent and insert this path for android:backupAgent=”{absolute path}.MyBackupAgent”
Here’s an example of a Manifest xml file with Backup support:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.project">
<application android:allowBackup="true" android:backupAgent="md5f576d3976d691fac04b078d1718cab3.MyBackupAgent">
<meta-data android:name="com.google.android.backup.api_key" >android:value="{Your unique Registration Key}" />
</application>
Add in project your MyBackupAgent class. The BackupAgentHelper class provides a convenient wrapper around the BackupAgent class, which minimizes the amount of code you need to write. In your BackupAgentHelper, you must use one or more "helper" objects, which automatically backup and restore certain types of data, so that you do not need to implement onBackup() and onRestore().
Note: Android currently provides backup helpers that will backup and restore complete files from SharedPreferences and internal storage.
Here’s a Java SharedPreferenceBackupHelper example for MyBackupAgent class:
import android.app.backup.BackupAgentHelper;
import android.app.backup.SharedPreferencesBackupHelper;
import android.util.Log;
public class MyBackupAgent extends BackupAgentHelper{
static final String PREFS = "myprefs";
static final String PREFS_BACKUP_KEY = "myprefs";
#Override
public void onCreate() {
Log.i("MyFileBackupAgent", "****** Enter BACKUP CLASS *******");
SharedPreferencesBackupHelper helper = new SharedPreferencesBackupHelper(this, PREFS);
addHelper(PREFS_BACKUP_KEY, helper);
Log.i("MyFileBackupAgent", "****** Exit BACKUP CLASS ********");
}
}
Here’s a C# Xamarin FileBackupHelper example for MyBackupAgent class:
public class MyBackupAgent: BackupAgentHelper
{
string myProtectData = "File.bin";
string myPersistentData = "Data.bin";
string myDBase = "Database.db";
public override void OnCreate()
{
Console.WriteLine ("****** Enter Backup Files Helpers *********");
base.OnCreate ();
try
{
FileBackupHelper dbkh = new FileBackupHelper (this, myProtectData);
this.AddHelper ("PROTECT_backup", dbkh);
FileBackupHelper persisth = new FileBackupHelper (this, myPersistentData);
this.AddHelper ("PERSIST_backup", persisth);
FileBackupHelper dbh = new FileBackupHelper (this, myDBase);
this.AddHelper ("DATABASE_backup", dbh);
Console.WriteLine ("********* All 3 files backuped *********");
}
catch {
Console.WriteLine ("******* Backup AddHelper Exception ERROR *********");
}
Console.WriteLine ("******** Exit Backup Files Helpers ********");
}
public override void OnBackup(ParcelFileDescriptor oldState, BackupDataOutput data, ParcelFileDescriptor newState)
{
Console.WriteLine ("****** Override OnBackup called ******");
base.OnBackup(oldState, data, newState);
}
public override void OnRestore (BackupDataInput data, int appVersionCode, ParcelFileDescriptor newState)
{
Console.WriteLine ("****** Override OnRestore called ******");
base.OnRestore(data, appVersionCode, newState);
}
}
To perform a backup, your code should make a backup request by calling the dataChanged(). A backup request does not result in an immediate call to your onBackup() method. Instead, the Backup Manager waits for an appropriate time*, then performs backup for all applications that have requested a backup since the last backup was performed. Note, The Backup Manager Service responds every hour as long as at least one DataChanged() was called in-between the hour since the last data backup request.
For test purposes, an immediate backup can be performed with the Android SDK Command Prompt Tool. Try these commands:
To ensure Data Backup Enabled:
adb shell bmgr enable true
To request a Data Backup:
adb shell bmgr backup
To initiate a Data Backup:
adb shell bmgr run
To uninstall your App:
adb uninstall
Then install your App:
adb install
What about your phone device Backup settings? Make sure a WiFi connection is established. Also, under device Settings, make sure "Back up my data" and "Automatic restore" are checked and you have entered in a valid Backup Account email id.
Lastly, to track your Backup upload time stamps, use www.google.com/settings/dashboard (this is your personal google account that matches your google account in your Android phone device Backup settings)
I wrote a very simple Android Activity:
import android.os.Bundle;
import android.app.Activity;
import android.util.Log;
public class MainActivity extends Activity {
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
Log.d("TAG", "onCreate() Log call 1");
Log.d("SMS", "onCreate() Log call 2");
Log.d("TEST", "onCreate() Log call 3");
finish();
}
#Override
protected void onDestroy() {
Log.d("TAG", "onDestroy() Log call 1");
Log.d("SMS", "onDestroy() Log call 2");
Log.d("TEST", "onDestroy() Log call 3");
super.onDestroy();
}
}
I would expect this to generate 6 log messages (3 from onCreate(), 3 from onDestroy()). Here is the logcat:
04-14 17:31:58.363: D/TAG(18084): onCreate() Log call 1
04-14 17:31:58.363: D/TEST(18084): onCreate() Log call 3
04-14 17:31:59.905: D/TAG(18084): onDestroy() Log call 1
04-14 17:31:59.905: D/TEST(18084): onDestroy() Log call 3
As can be seen, the lines with the tag "SMS" don't get through. This is not, as far as I can tell a documented thing. The question is, why?
EDIT: More details on the answer.
A rather good answer is given below by Matthew Burke. In short, on the basis of the source code for logd_write.c, it seems that:
Log requests with the following tags are automatically redirected to the radio log:
HTC_RIL
tags starting with RIL
AT
GSM
STK
CDMA
PHONE
SMS
No Log requests are redirected to the events log (or the system log, see also http://elinux.org/Android_Logging_System)
All other Log requests go to the main log, the one that is usually monitored.
I should have read the documentation for logcat before I started hunting through source. According to logcat's documentation:
The Android logging system keeps multiple circular buffers for log messages, and not all of the log messages are sent to the default circular buffer.
Messages with a tag of SMS are sent to the radio buffer, not the main buffer. Hence you won't see them unless you go out of your way to do so. If you run the command:
adb logcat -b radio
you should see your missing log messages. The above information can be found in https://developer.android.com/tools/debugging/debugging-log.html.
Now, for those of you interested in code spelunking, below is my original answer:
The methods in the Log class are all wrappers around println_native which is a JNI method.
println_native performs some validation of its parameters and then calls __android_log_buf_write.
Now this latter method compares the tag parameter (from the original Log.d call) against several hard-coded strings (with the tag SMS being one of this list) and if it finds a match, winds up writing the log message to a different file!
By the way, other tags that get rerouted are GSM, STK, PHONE, CDMA, and a few others.
Relevant source can be read in
http://www.java2s.com/Open-Source/Android/android-core/platform-frameworks-base/android/util/Log.java.htm
https://pdroid.googlecode.com/svn/android-2.3.4_r1/trunk/frameworks/base/core/jni/android_util_Log.cpp
https://in-the-box.googlecode.com/svn-history/r4/trunk/InTheBoxSim/liblog/logd_write.c
http://www.takatan.net/lxr/source/drivers/staging/android/logger.h#L33
These aren't the official links and may disappear at some point. I'll try and track down the official links and edit this later this evening.
EDIT Ignore this, I'm apparently quite off base according to this.
So I thought this was interesting, and after digging through the source, I ended up finding out about Log.isLoggable():
Checks to see whether or not a log for the specified tag is loggable
at the specified level. The default level of any tag is set to INFO.
This means that any level above and including INFO will be logged.
Before you make any calls to a logging method you should check to see
if your tag should be logged. You can change the default level by
setting a system property: 'setprop log.tag. '
Where level is either VERBOSE, DEBUG, INFO, WARN, ERROR, ASSERT, or
SUPPRESS. SUPPRESS will turn off all logging for your tag. You can
also create a local.prop file that with the following in it:
'log.tag.=' and place that in /data/local.prop.
Parameters
tag
The tag to check. level The level to check. Returns
Whether or not that this is allowed to be logged.
Apparently some tags are not allowed at certain log levels, seemingly defined in /data/local.prop, but there must be some system level properties file I haven't found yet. You can check against it using something like this, though:
boolean isLoggableV = Log.isLoggable("SMS", Log.VERBOSE);
boolean isLoggableD = Log.isLoggable("SMS", Log.DEBUG);
boolean isLoggableI = Log.isLoggable("SMS", Log.INFO);
boolean isLoggableW = Log.isLoggable("SMS", Log.WARN);
boolean isLoggableE = Log.isLoggable("SMS", Log.ERROR);
boolean isLoggableA = Log.isLoggable("SMS", Log.ASSERT);
Log.v("LogTest", String.format("Verbose: %b Debug: %b Info: %b Warn: %b Error: %b Assert: %b", isLoggableV, isLoggableD, isLoggableI, isLoggableW, isLoggableE, isLoggableA));
Which for me returned the following:
Verbose: false Debug: false Info: true Warn: true Error: true Assert: true
So you can log the tag SMS at a log level of INFO and above, but not VERBOSE or DEBUG.
I have to assume this is to prevent applications from accidentally logging personal information, but it seems like a fairly crude way of doing so.
I'm dealing with a random problem which related to camera usage. Before I call camera intent - I generate UUID to store file with this name. I store this UUID in private variable like so:
private String requestedFileName;
When camera done - I'm processing this file, looks something like this:
public void onPictureTaken(int index)
{
//First of all - remember picture in database for reference.
FileData.InsertFile(mContext, UUID.fromString(requestedFileName));
//Reduce taken picture if needed, otherwise let it be original.
if (Preferences.getImageSize(mContext) > 0)
{
Imaging.scaleImageFile(mContext, requestedFileName, Preferences.getImageSize(mContext));
}
I see users report issue exception that boils down to requestedFileName == null when onPictureTaken called
Caused by: java.lang.NullPointerException
at java.util.UUID.fromString(UUID.java:210)
at com.idatt.views.FourImagesView.onPictureTaken(FourImagesView.java:151)
at com.idatt.views.TrailerUnitView.onPictureTaken(TrailerUnitView.java:233)
Everything works good on my phone (Nexus S) and in emulator. But users report this exception and I'm not sure why this is happening..
I've seen this happen on the Nexus phones, and some others. If you use DDMS to watch what is going on, I bet you'll see that your process is actually being terminated and then restarted. Thus your local state is being lost. You need to persist it, since Android can basically kill your process and restart it whenever it wants if you switch to a new task (and most of the camera capture intents set the NEWTASK flag).
If your class is an Activity you can use onSaveInstanceState() to store your filename, then read it back out of the Bundle you get in onCreate().
If you are not an Activity you can use the SharedPreferences store as a temporary place to save the filename:
private static void saveTempFileName(Context context, String filename) {
SharedPreferences settings = context.getSharedPreferences("whatever", 0);
SharedPreferences.Editor editor = settings.edit();
editor.putString("com.yourstuff.whatever", filename);
editor.commit();
}
As #jeffamaphone noted you are probably having issues with app configuration changes. Application configuration change happens when something happens that affects the runtime environment of your app. Most notably this are: orientation change or keyboard hide/show.
Try this: start your app, invoke the Camera app (via your app action), change orientation, return to your app (via appropriate action). Does this sequence produce the error? Then you have issues with configuration change - when orientation changes usually (depending on your app settings) Android system restarts (kills and creates new instance) your Activity, which probably creates all new Views (without UUID set).
See handling configuration changes.
I've researched and followed how to get my android app to backup the data to google backup so if user loses phone or upgrades to a new phone, they don't lose their data. However, when I test it out (by using the app myself, then uninstalling and reinstalling), no data is restored. Here's what I've done. Perhaps someone can figure out what is wrong.
Applied for a backup key from google
Placed following code in Manifest File (in place of key I did add the key value and for packageName I used my app package name)
android:backupAgent="packageName.MyPrefsBackup">
<meta-data android:name="com.google.android.backup.api_key" android:value="key" />
Created class MyPrefsBackup with following code. The name of the sharedpreference file I want to backup is called UserDB. As far as the PREFS_BACKIP_KEY, I just called it prefs. From what I understand, this is not the same key as the one that goes in the manifest file.
Code:
package packageName;
import android.app.backup.BackupAgentHelper;
import android.app.backup.SharedPreferencesBackupHelper;
public class MyPrefsBackup extends BackupAgentHelper {
// The name of the SharedPreferences file
static final String PREFS = "UserDB";
// A key to uniquely identify the set of backup data
static final String PREFS_BACKUP_KEY = "prefs";
// Allocate a helper and add it to the backup agent
public void onCreate() {
SharedPreferencesBackupHelper helper = new SharedPreferencesBackupHelper(this, PREFS);
addHelper(PREFS_BACKUP_KEY, helper);
}
}
Added BackupManager mBackupManager = new BackupManager(this); in my main class where I call the backup manager in next step
Lastly, in my main program I call the backupHelper when data is changed by the following line:
mBackupManager.dataChanged();
Any help is much appreciated.
try new BackupManager(this).dataChanged()
If you are testing this from AVD - you'll need to enable backups - AVD are disabled for backups by default.
adb shell bmgr enable true
Then you can actually debug it to see if the onCreate is called after running
adb shell bmgr run