I have in my application Android manifest:
android:allowBackup="true"
But in spite of using an Android 8 device the backup does not work until I manually put in the console:
adb shell bmgr backup #pm# && adb shell bmgr run
and...
adb shell bmgr fullbackup <PACKAGE>
as says the Android developers guide to test a backup.
I have tested so many devices and when I put this in console it starts to work fine and I can uninstall and install the application from Google Play without losing the SharedPreferences. But if I don't write this in my Android Studio console with the device connected, the backup doesn't work.
It's strange because many other applications restore their data, so I think that the device settings are ok and I am missing something in the code.
This are my build.gradle sdk specifications
def valueMinSdkVersion = 15
def valueTargetSdkVersion = 28
Thank you so much.
Mauricio Güell
use these 2 in your manifest:
android:allowBackup="true"
android:fullBackupOnly="true"
why we use fullBackuoOnly?
Android versions before Marshmallow had a backup system that required a significant developer effort to implement. If you implemented that system, but you want your app to use the new backup system on devices where it's available, you can set this flag to disable the old backup system only on devices where the new system is available. This is better than removing your implementation of the old backup system, because older devices will continue to back up with the old system. If you didn't implement the old backup system, or will remove it from your app, you don't need this flag.
Related
With the backup command you could make a complete backup of android smartphones, now that I know only the pull command remains but it is not like the backup command, are there alternatives?
The adb backup command may be able to make a complete backup of an Android smartphone, but nowadays it becomes more and more useless:
adb backup can only backup apps that allow backup at all (an app has to declare allowBackup=true in it's AndroidManifest.xml or don't have such an entry at all). If it sets allowBackup=false then adb backup can not get any data on this app.
Cryptographic keys stored in AndroidKeystore can not be extracted, they are bound to the phone hardware. https://developer.android.com/training/articles/keystore
adb backup fails on recent apps that have targetSDK level to 31 or higher (if the abb is a production and not a debuggable app). adb backup was marked deprecated years ago, seems like Google wants to finally cut it off. https://developer.android.com/about/versions/12/behavior-changes-12#adb-backup-restrictions
I am developing an Android Wear application. As per my understanding I must use Android Wear (mobile app) and install through it to watch. For this we need to build the apk each time and save it in mobile, and install it through the mobile app, so is there a better way to install the apk in the watch or is it the standard process?
You can install Wear apk in the exact same way as normal Android application.
First, attach Wear device to your computer and allow USB debugging. Alternatively, download and start Wear emulator through Android Studio.
Next, run your app through Android Studio - you can use run or debug modes.
That's it! :)
For distribution, the process is slightly different, depending on whether you want to support Wear 1.0 or only Wear 2.0, and whether companion app is needed on the phone. For Wear 2.0, you don't need mobile app anymore, it can be distributed directly, but of course depending on functionality you might want mobile app as well.
Provided you have root privilege on your Android watch:
1.Use adb shell to connect the watch and switch to su
2.Assume your watch app is called watchapp with com.watchapp so file
chmod +777 /data
chmod 777 /data/data
chmod 777 -R /data/data/com.watchapp
#There might also be other files with suffix
chmod 777 -R /data/app-lib/com.watchapp-1
3.
#adb push your new compiled so file to overwrite that file in your watch
adb push YOURNEWSOFILEPATHONEDISK /data/app-lib/com.test-1
I have this development board Open-Q 820
It is running an Android 7.0 based on some sources from CodeAurora (that seem based on AOSP sources). Seems it uses proprietary bootloader that can not be changed. I need to access GPIO (/system/class/gpio) from my android app to control an external device. Problem is I can not do this from android app - seems only root can access this files.
I can call "adb root" command from PC and then call from "adb shell" something like
echo 0 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio0/direction
echo 1 > /sys/class/gpio/gpio0/value
and it is working. But I need to do the same from my android app. I know how to access terminal and su from android app. I just dont know how to root custom device. I tried to install SuperSU.apk app and its corresponding su native app manually. It starts and says it need to update su binaries. After installing binaries and reboot the system then it becomes broken - infinite android logo. If I not install binaries update then SuperSU can grant permissions to my app but actully app still can not use su (I dont know why - I use this library inside my app: https://github.com/Chrisplus/RootManager). And after reboot SuperSU not working longer.
So may be you know some SuperSU alternatives (Knigroot not working too) or steps how to correctly install some superuser management app. Or may be I can use su directly (I tried but my app has not rights to access /system/xbin/su). Or may be I can make /sys/class/gpio accessible by android apps somehow (I tried chmod 777 on it - not works). May be some SElinux rights, but I have no experience with this.
Thank you
Magisk helped me. Since it is have option to patch custom boot image. I used this option and now root access works.
I have added "android.permission.WRITE_SECURE_SETTINGS" in the Manifest. But still i get an error message saying - required "WRITE_SECURE_SETTINGS".
I have seen a lot of talks about this, and that this setting is prevented for third party software.
It is any other way that i can add my application can gain this permission?
I have see this adb command, but i not so familiar how to use this to add my application to my device, is below command is require root my device before it can be use because it failed to copy by Read-only file system?
adb remount
adb push app.apk /system/app/
I would like to add that WRITE_SECURE_SETTINGS permission can be granted over adb and this approach does NOT require root. Here is a command:
adb shell pm grant your.package.name android.permission.WRITE_SECURE_SETTINGS
Firstly, as you have read before, WRITE_SECURE_SETTINGS is NOT available to applications! So you cannot use this permission regardless whether you are on rooted or production builds.
So, if you wish to enable this setting, create your own firmware that does what you need and load that firmware on whatever devices you wish. Or, contribute your changes to existing firmware mods (e.g., Cyanogen).
Some other applications use techniques like Reflection using Java to gain access to functions not exposed via API, you can probably try the same.
Secondly, adb remount does not work as is with production builds unless the phone is rooted or firmware enables it by default.
I recently struggled with this very thing. My client wanted an app that would turn NFC off when the device was charging (wireless charger) and then on when it was removed from the charger. I was running KitKat on my Nexus 7, and even though I had WRITE_SECURE_SETTINGS in the Manifest, and the app in /system/app/, it would not work.
Turns out, that in 4.4 they added additional security. In 4.3 however, it works if three things are true:
Manifest has WRITE_SECURE_SETTINGS
App is in /system/app/
The package is signed by a key (any key)
I rooted the device using the awesome Nexus Root Toolkit (NRT) from http://www.wugfresh.com/nrt/ then installed BusyBox and system app mover from:
https://play.google.com/store/apps/details?id=stericson.busybox
https://play.google.com/store/apps/details?id=de.j4velin.systemappmover
I installed my custom signed APK and moved it into place using system app mover, which then restarted the device. It worked perfectly. Hope this helps.
For the api that I used, which required WRITE_SECURE_SETTINGS privileges, I had to include this in the manifest:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
...
coreApp="true"
android:sharedUserId="android.uid.system">
<uses-permission android:name="android.permission.WRITE_SECURE_SETTINGS"/>
...
ref: https://github.com/android/platform_packages_apps_settings/blob/master/AndroidManifest.xml
I also had to run the application as a system app (under: /system/app).
Here is an how to: http://www.addictivetips.com/mobile/how-to-install-any-app-as-system-app-on-android/
I met this situation too,and then i follow the rules below:
1.add WRITE_SECURE_SETTINGS in manifest
2.make my own firmware
3.add LOCAL_CERTIRICATE := platform
Try this,
adb shell pm grant your.package.name android.permission.WRITE_SECURE_SETTINGS
I was able to fix this problem by enabling notification access.
go to settings
click on sound and notification
scroll down
click on notification access
I have rooted my NexusOne. I can get 'adb shell and su'.
But when I deploy and run my android app on NexusOne and start my application. Under DDMS (connected to the phone of course), I DO NOT see my application. I see some apps but not mine.
How can I make my application visible under DDMS so that I can debug my application using eclipse on a rooted NexusOne?
Thank you.
Since you can see some apps but not yours, I assume you have adb working and your phone configured properly.
The next thing you'd need to check is to make sure that the "debuggable" flag is set in your application manifest. In AndroidManifest.xml, add android:debuggable="true" to the element.
See the official docs for more. You do not need a rooted device to debug apps.
On ubuntu I have to run the following commands for adb to properly recognise my devices:
cd <android sdk root >/tools/ (or platform-tools/ for newer SDK's)
sudo ./adb kill-server
sudo ./adb devices
This then gives adb the right permissions to access the devices.
Then in Eclipse looking in the DDMS perspective, you select the device you want to debug (on the left) and then look in logcat (not the terminal) to see the log.
Not a solution but useful to know, Log Collector is a free app on the market which sends logs to any e-mail address and is often useful for debugging.