New to Android, working on an app for Vuzix M300s. The app needs to access a file that contains the IP address and port of a web server.
I believe I will need to manually place a pre-configured file on the M300s using adb shell, but I cannot figure out where on the device to place it so that the app can find it.
Via Android Studio 3.1.3, I have placed a file in the assets folder which I can open & read, but using adb shell I cannot locate it. (I get permission denied for a lot of actions like ls).
How do I get a file on there? Or is there a better way?
Note that the assets folder in your project only exists on your development machine. The contents of this folder are packaged into the APK file when you build your app. In order to read any of these files, you need to use Context.getAssets() as explained in read file from assets.
Figured it out.
To move/copy a file to the M300s for an application
move the file to the device (in the sdcard folder)
.\adb push C:\temp\file.cfg /sdcard/
move the file from /sdcard/ to the desired location
a) go into the shell
'> .\adb shell
b) change to the application's permissions
$ run-as com.foobar.appname
c) copy the file into the app's 'files' folder
$ cp /sdcard/file.cfg files/
Within my app, I was able to read this with
FileInputStream fin = openFileInput("file.cfg");
InputStreamReader rdr = new InputStreamReader(fin);
char[] inputBuffer = new char[100];
int charsRead = rdr.read(inputBuffer);
String fileContents = new String(inputBuffer);
rdr.close();
Log.i(method, "charsRead: " + charsRead);
Log.i(method, "fileContents: " + fileContents);
Background
So far, I was able to install APK files using root (within the app), via this code:
pm install -t -f fullPathToApkFile
and if I want to (try to) install to sd-card :
pm install -t -s fullPathToApkFile
The problem
Recently, not sure from which Android version (issue exists on Android P beta, at least), the above method fails, showing me this message:
avc: denied { read } for scontext=u:r:system_server:s0 tcontext=u:object_r:sdcardfs:s0 tclass=file permissive=0
System server has no access to read file context u:object_r:sdcardfs:s0 (from path /storage/emulated/0/Download/FDroid.apk, context u:r:system_server:s0)
Error: Unable to open file: /storage/emulated/0/Download/FDroid.apk
Consider using a file under /data/local/tmp/
Error: Can't open file: /storage/emulated/0/Download/FDroid.apk
Exception occurred while executing:
java.lang.IllegalArgumentException: Error: Can't open file: /storage/emulated/0/Download/FDroid.apk
at com.android.server.pm.PackageManagerShellCommand.setParamsSize(PackageManagerShellCommand.java:306)
at com.android.server.pm.PackageManagerShellCommand.runInstall(PackageManagerShellCommand.java:884)
at com.android.server.pm.PackageManagerShellCommand.onCommand(PackageManagerShellCommand.java:138)
at android.os.ShellCommand.exec(ShellCommand.java:103)
at com.android.server.pm.PackageManagerService.onShellCommand(PackageManagerService.java:21125)
at android.os.Binder.shellCommand(Binder.java:634)
at android.os.Binder.onTransact(Binder.java:532)
at android.content.pm.IPackageManager$Stub.onTransact(IPackageManager.java:2806)
at com.android.server.pm.PackageManagerService.onTransact(PackageManagerService.java:3841)
at android.os.Binder.execTransact(Binder.java:731)
This seems to also affect popular apps such as "Titanium backup (pro)", which fails to restore apps.
What I've tried
Looking at what's written, it appears it lacks permission to install APK files that are not in /data/local/tmp/.
So I tried the next things, to see if I can overcome it:
set the access to the file (chmod 777) - didn't help.
grant permissions to my app, of both storage and REQUEST_INSTALL_PACKAGES (using ACTION_MANAGE_UNKNOWN_APP_SOURCES Intent) - didn't help.
create a symlink to the file, so that it will be inside the /data/local/tmp/, using official API:
Os.symlink(fullPathToApkFile, symLinkFilePath)
This didn't do anything.
create a symlink using this :
ln -sf $fullPathToApkFile $symLinkFilePath
This partially worked. The file is there, as I can see it in Total Commander app, but when I try to check if it exists there, and when I try to install the APK from there, it fails.
Copy/move (using cp or mv) the file to the /data/local/tmp/ path, and then install from there. This worked, but it has disadvantages: moving is risky because it temporarily hides the original file, and it changes the timestamp of the original file. Copying is bad because of using extra space just for installing (even temporarily) and because it wastes time in doing so.
Copy the APK file, telling it to avoid actual copy (meaning hard link), using this command (taken from here) :
cp -p -r -l $fullPathToApkFile $tempFileParentPath"
This didn't work. It got me this error:
cp: /data/local/tmp/test.apk: Cross-device link
Checking what happens in other cases of installing apps. When you install via via the IDE, it actually does create the APK file in this special path, but if you install via the Play Store, simple APK install (via Intent) or adb (via PC), it doesn't.
Wrote about this here too: https://issuetracker.google.com/issues/80270303
The questions
Is there any way to overcome the disadvantages of installing the APK using root on this special path? Maybe even avoid handling this path at all?
Why does the OS suddenly require to use this path? Why not use the original path instead, just like in the other methods of installing apps? What do the other methods of installing apps do, that somehow avoids using the spacial path?
One solution, in case you don't mind the moving procedure, is to also save&restore the timestamp of the original file, as such:
val tempFileParentPath = "/data/local/tmp/"
val tempFilePath = tempFileParentPath + File(fullPathToApkFile).name
val apkTimestampTempFile = File(context.cacheDir, "apkTimestamp")
apkTimestampTempFile.delete()
apkTimestampTempFile.mkdirs()
apkTimestampTempFile.createNewFile()
root.runCommands("touch -r $fullPathToApkFile ${apkTimestampTempFile.absolutePath}")
root.runCommands("mv $fullPathToApkFile $tempFileParentPath")
root.runCommands("pm install -t -f $tempFilePath")
root.runCommands("mv $tempFilePath $fullPathToApkFile")
root.runCommands("touch -r ${apkTimestampTempFile.absolutePath} $fullPathToApkFile")
apkTimestampTempFile.delete()
It's still a bit dangerous, but better than copying files...
EDIT: Google has shown me a nice workaround for this (here) :
We don't support installation of APKs from random directories on the device. They either need to be installed directly from the host using 'adb install' or you have to stream the contents to install --
$ cat foo.apk | pm install -S APK_SIZE
While I think this is incorrect that they don't support installing of APK files from random paths (always worked before), the workaround does seem to work. All I needed to change in the code of installing an APK file is as such:
val length = File(fullPathToApkFile ).length()
commands.add("cat $fullPathToApkFile | pm install -S $length")
Thing is, now I have some other questions about it :
Does this workaround avoid the moving/copying of the APK into storage, and without affecting the original file ? - seems it does
Will this support any APK file, even large ones? - seems it succeeds in doing it for an APK that takes 433MB, so I think it's safe to use for all sizes.
This is needed only from Android P, right? - so far seems so.
Why does it need the file size as a parameter ? - No idea, but if I remove it, it won't work
Thanks for the answers! I looked everywhere else as well to get a whole setup for OTA to work for Android 10 and so on. It 100% works on Samsung Galaxy Tab 10.1 running Android 10.
Here is a medium article with the code:
https://medium.com/#jnishu1996/over-the-air-ota-updates-for-android-apps-download-apk-silent-apk-installation-auto-launch-8ee6f342197c
The magic is running this command with root access:
process = Runtime.getRuntime().exec("su");
out = process.getOutputStream();
DataOutputStream dataOutputStream = new DataOutputStream(out);
// Get all file permissions
dataOutputStream.writeBytes("chmod 777 " + file.getPath() + "\n");
// Perform silent installation command, all flags are necessary for some reason, only this works reliably post Android 10
String installCommand = "cat " + file.getAbsolutePath() + "| pm install -d -t -S " + file.length();
// Data to send to the LaunchActivity to the app knows it got updated and performs necessary functions to notify backend
// es stands for extraString
// In LaunchActivity onCreate(), you can get this data by running -> if (getIntent().getStringExtra("OTA").equals("true"))
String launchCommandIntentArguments = "--es OTA true --es messageId " + MyApplication.mLastSQSMessage.receiptHandle();
// Start a background thread to wait for 8 seconds before reopening the app's LaunchActivity, and pass necessary arguments
String launchCommand = "(sleep 8; am start -n co.getpresso.Presso/.activities.LaunchActivity " + launchCommandIntentArguments + ")&";
// The entire command is deployed with a ";" in the middle to launchCommand run after installCommand
String installAndLaunchCommand = installCommand + "; " + launchCommand;
// begins the installation
dataOutputStream.writeBytes(installAndLaunchCommand);
dataOutputStream.flush();
// Close the stream operation
dataOutputStream.close();
out.close();
int value = process.waitFor();
I have spent many hours trying to find/create files for an app I am writing. When I pull the application directory name I get: /data/data/com.example.android.[myapp]/files. I am using File(getFilesDir():
File fileDir = new File(getFilesDir() + File.separator);
Log.i(TAG, "File directory: "+fileDir);
When I try to find this path I find many application folders here: Android/data/com but no /data/data folder under Android. There are many other application folders there but not mine. I see the same results whether I use Android Files app or Windows Explorer over USB. I've also tried to look using Eclipse DDMS tab. I see a data folder with a (+) to the left but when I click, it does not expand.
I have also tried creating the directory and file manually with Windows explorer and my app still can't find neither the Android/data/com.example... nor the Android/data/data/com.example... paths.
Also puzzling to me is when the app creates the path and file and write to it (using MODE_WORLD_WRITEABLE) I get no exceptions thrown but then I am unable to read it back or see it with either of the tools mentioned above. I have set the manifest permissions to WRITE_INTERNAL_STORAGE and WRITE_INTERNAL_STORAGE for the app.
Obviously, I am making a very basic mistake.
I am on Android 4.1.2 (API 16).
Sincerely,
ScratchingMyHead
To get the path of my application directory, Try this code sample
PackageManager m = getPackageManager();
String s = getPackageName();
try {
PackageInfo p = m.getPackageInfo(s, 0);
s = p.applicationInfo.dataDir;
} catch (NameNotFoundException e) {
Log.w("yourtag", "Error Package name not found ", e);
}
When I try to find this path I find many application folders here: Android/data/com but no /data/data folder under Android.
That is because you are looking on external storage, not internal storage where your files are. Use DDMS on an emulator to examine internal storage.
I've also tried to look using Eclipse DDMS tab. I see a data folder with a (+) to the left but when I click, it does not expand.
That would sound like what you will get when testing on hardware, as neither you nor DDMS have access to the contents of /data on production hardware.
I'm trying to test the Expansion Pack Files (OBB) In Android following the guide here:
http://developer.android.com/google/play/expansion-files.html
I'm in the step where I need to test my app on my Nexus 4.
I generated my .obb file with jobb and adb-pushed it in the device in this location:
/mnt/shell/emulated/0/Android/obb/my.package/main.1.my.package.obb
When the app run it doesn't find the file.
Method:
Helpers.doesFileExist(context, fileName, xf.mFileSize, false)
return false for my file.
I debugged and found out it is looking for the file in:
/storage/emulated/0/Android/obb/my.package/main.1.my.package.obb
Specifically this is the path returned by:
Helpers.generateSaveFileName(c, fileName)
The /storage/emulated/0, returned by Environment.getExternalStorageDirectory() doesn't exist browsing the device with adb shell.
But it DOES at runtime, inside the app, I also checked what it contains: it contains almost the same things I found in /mnt/shell/emulated/0, it contains the Android/obb dir, which is empty.
How I found out the path /mnt/shell/emulated/0/Android/obb/my.package/main.1.my.package.obb where I placed my obb file:
$ adb shell
$ ls -ld sdcard
lrwxrwxrwx root root 2013-10-16 17:34 sdcard -> /storage/emulated/legacy
$ ls -ld /storage/emulated/legacy
lrwxrwxrwx root root 2013-10-16 17:34 legacy -> /mnt/shell/emulated/0
And inside that I already found the Android/obb directory, empty.
So the question is: where should I put my obb file for it to be in the right position at runtime?
I did everything said there:
created a draft application in the Market to get the public key
generated a random array of 20 byte (salt)
integrated play_licensing/library and play_apk_expansion/download_library
wrote my Service / Receiver
did the check using the Helpers etc.. exactly like the documentation say.
I suppose everything works but I can't just yet release on Play Store! I need to test locally and I'll have the need to change my obb file pretty often in this initial phase of development.
I can't test on the Emulator because I use 3D and device camera.
Since Android 4.2 multi users support have been added.
To support that Android mount an emulated disk for each users acting as a sandbox layer around the actual filesystem: this let Android handle gracefully either sharing of files between users either personal files.
Long story short:
/storage/emulated
is the emulated filesystem.
if you enter that directory from adb shell you may see a
/storage/emulated/obb
directory. Sometimes it doesn't show up, for some reason (see below for what to do if this happen)
It's not in /Android/obb but that's the right directory where to place your app package / obb file!
If you don't see that directory try looking in:
/mnt/shell/emulated/obb
You should be able to put your file there.
It will be correctly picked up at runtime ending at the
/storage/emulated/0/Android/obb/my.package/main.1.my.package.obb
path.
I think the Android documentation should explain this.
(I answer my own question because I found out how to solve it while writing it.)
For me the correct location is : mnt/sdcard/Android/obb/nameofyourpackage/
NOT "/mnt/shell"
I am developing an app and I know my database *.db will appear in data/data/com.****.***
I can access this file from AVD in Eclipse with help of sqlite manager
But I can't access this file in my Android phone.
I googled it and it says I need to root my phone to do it, but I don't want to do that.
How can I access my data/data/..... directory in my Android phone "without rooting it"?
Can I change user permissions for the directory data/data..... without rooting it?
Accessing the files directly on your phone is difficult, but you may be able to copy them to your computer where you can do anything you want with it.
Without rooting you have 2 options:
If the application is debuggable you can use the run-as command in adb shell
adb shell
run-as com.your.packagename
cp /data/data/com.your.packagename/
Alternatively you can use Android's backup function.
adb backup -noapk com.your.packagename
You will now be prompted to 'unlock your device and confirm the backup operation'. It's best NOT to provide a password, otherwise it becomes more difficult to read the data. Just click on 'backup my data'. The resulting 'backup.ab' file on your computer contains all application data in android backup format. Basically it's a compressed tar file. This page explains how you can use OpenSSL's zlib command to uncompress it.
You can use the adb restore backup.db command to restore the backup.
If you are using Android Studio 3.0 or later version then follow these steps.
Click View > Tool Windows > Device File Explorer.
Expand /data/data/[package-name] nodes.
You can only expand packages which runs in debug mode on non-rooted device.
You could also try fetching the db using root explorer app. And if that does not work then you can try this:
Open cmd
Change your directory and go into 'Platform tools'
Type 'adb shell'
su
Press 'Allow' on device
chmod 777 /data /data/data /data/data/com.application.package /data/data/com.application.package/*
Open DDMS view in Eclipse and from there open 'FileExplorer' to get your desired file
After this you should be able to browse the files on the rooted device.
To do any of the above (i.e. access protected folders from within your phone itself), you still need root. (That includes changing mount-permissions on the /data folder and accessing it)
Without root, accessing the /data directly to read except from within your application via code isn't possible. So you could try copying that file to sdcard or somewhere accessible, and then, you should be able to access it normally.
Rooting won't void your warranty if you have a developer device. I'm sorry, there isn't any other way AFAIK.
The easiest way (just one simple step) to pull a file from your debuggable application folder (let's say /data/data/package.name/databases/file) on an unrooted Android 5.0+ device is by using this command:
adb exec-out run-as package.name cat databases/file > file
Open your command prompt
Change directory to E:\Android\adt-bundle-windows-x86_64-20140702\adt-bundle-windows-x86_64-20140702\sdk\platform-tools
Enter below commands
adb -d shell
run-as com.your.packagename cat databases/database.db > /sdcard/database.db
Change directory to cd /sdcard to make sure database.db is there.
adb pull /sdcard/database.db or simply you can copy database.db from device .
Use File Explorer in eclipse. Select Windows => Show View => Other ... => File Explorer.
An another way is pull the file via adb:
adb pull /system/data/data/<yourpackagename>/databases/<databasename> /sdcard
To backup from Android to Desktop
Open command line cmd and run this:
adb backup -f C:\Intel\xxx.ab -noapk your.app.package.
Do not enter password and click on Backup my data.
Make sure not to save on drive C root. You may be denied.
This is why I saved on C:\Intel.
To extract the *.ab file
Go here and download: https://sourceforge.net/projects/adbextractor/
Extract the downloaded file and navigate to folder where you extracted.
run this with your own file names: java -jar abe.jar unpack c:\Intel\xxx.ab c:\Intel\xxx.tar
I had also the same problem once. There is no way to access directly the file within android devices except adb shell or rooting device.
Beside here are 02 alternatives:
1)
public void exportDatabse(String databaseName)
{
try {
File sd = Environment.getExternalStorageDirectory();
File data = Environment.getDataDirectory();
if (sd.canWrite()) {
String currentDBPath = "//data//"+getPackageName()+"//databases//"+databaseName+"";
String backupDBPath = "backupname.db";
File currentDB = new File(data, currentDBPath);
File backupDB = new File(sd, backupDBPath);
if (currentDB.exists()) {
FileChannel src = new FileInputStream(currentDB).getChannel();
FileChannel dst = new FileOutputStream(backupDB).getChannel();
dst.transferFrom(src, 0, src.size());
src.close();
dst.close();
}
}
} catch (Exception e) {
}
}
2) Try this: https://github.com/sanathp/DatabaseManager_For_Android
On a rooted device, the correct solution is this:
Open cmd
Change your directory and go into 'Platform tools'
Type 'adb shell'
su
Press 'Allow' on device
chmod 777 /data /data/data /data/data/*
Open DDMS view in Eclipse/IntelliJ and from there open 'FileExplorer' to get your desired file
The original solution worked, but the chmod would return unknown directory. Changing the chmod command to /data/data/* gave access to all subfolders in the data directory from DDMS in Intellij. I assume the same solution is true for Eclipse DDMS.
UPDATE
So, what I've found is strange. I'm running a Nexus 6 using DDMS in IntelliJ (Android Device Monitor). I have built a little starter app. Said app saves data to a .csv file in data/data/com.example.myapp/files
When I first started to try to access this file on my Nexus 6, I found that I have to root the device.. I could see the data folder, but trying to open it would not work. As mentioned online in other places, the expand + would vanish then reappear shortly thereafter (note, there are solutions on the web that claim to allow access to these folders without rooting, I didn't find them till too late, and I'm not sure if I prefer not to root anyway ((I'd rather be able to do it manually than rely on an app or command prompt to give me my solutions))). I rooted my 6 and tried DDMS again.
At this point, it showed me the data folder and I could expand the folder and see the com. directories, but I could not open any of them. That is when I discovered the above solution. The initial instructions would not work on this part:
chmod 777 /data /data/data /data/data/com.application.pacakage /data/data/com.application.pacakage/*
That is when I tried the solution I posted:
chmod 777 /data /data/data /data/data/*
That solution seemed to work, but only on certain folders. I now could expand my myapp folder, but could not expand the files directory in it.
At this point, I played around for a while then figured why not just try it on the directory I need rather than trying these wildcard entries.
chmod 777 /data /data/data /data/data/com.example.myapp/*
Followed by:
chmod 777 /data /data/data /data/data/com.example.myapp/files
These commands allowed me to expand and view the files in my app's directory to confirm that the .csv was being saved correctly.
Hope this helps someone. I struggled with this for hours!
(to compound on this a tad further, oddly enough, the permissions did not pass to the .csv file that passed to the files directory. my files directory permissions read drwxrwxrwx and my log.csv file permissions read -rw-rw---- .. just fyi)
may be to access this folder you need administrative rights.
so you have two options:-
root your device and than try to access this folder
use emulator
p.s. : if you are using any of above two options you can access this folder by following these steps
open DDMS perspective -> your device ->(Select File Explorer from
right window options) select package -> data -> data -> package name
->files
and from there you can pull up your file
You can download a sigle file like that:
adb exec-out run-as debuggable.app.package.name cat files/file.mp4 > file.mp4
Before you download you might wan't to have a look at the file structure in your App-Directory. For this do the following steps THelper noticed above:
adb shell
run-as com.your.packagename
cd files
ls -als .
The Android-Studio way Shahidul mentioned (https://stackoverflow.com/a/44089388/1256697) also work. For those who don't see the DeviceFile Explorer Option in the Menu: Be sure, to open the /android-Directory in Android Studio.
E.g. react-native users have this inside of their Project-Folder right on the same Level as the /ios-Directory.
adb backup didn't work for me, so here's what I did (Xiaomi Redmi Note 4X, Android 6.0):
1. Go to Settings > Additional Settings > Backup & reset > Local backups.
2. Tap 'Back up' on the bottom of the screen.
3. Uncheck 'System' and 'Apps' checkmarks.
4. Tap detail disclosure button on the right of the 'Apps' cell to navigate to app selection screen.
5. Select the desired app and tap OK.
6. After the backup was completed, the actual file need to be located somehow. Mine could be found at /MIUI/backup/AllBackup/_FOLDER_NAMED_AFTER_BACKUP_CREATION_DATE_.
7. Then I followed the steps from this answer by RonTLV to actually convert the backup file (.bak in my case) to tar (duplicating from the original answer):
"
a) Go here and download: https://sourceforge.net/projects/adbextractor/
b) Extract the downloaded file and navigate to folder where you extracted.
c) run this with your own file names: java -jar abe.jar unpack c:\Intel\xxx.ab c:\Intel\xxx.tar
"
Simple answer is NO. On upcoming Android 13, you can't access anything in
/storage/emulated/0/Android/*
directory without Rooting your device or hooking up to a PC, certainly not in Pixel devices.
Read Android Source page for such App data access using ADB here:
https://developer.android.com/training/data-storage/manage-all-files
One of the simple way is to create your database on SD-Card. Because you cannot get access to your phone's data folder in internal memory, unless you root your phone. So why not simply create your database on SD-Card.
Moreover, if you want, you may write some file copying-code to copy your existing database file (from internal memory) to external memory without requiring any root.
you can copy this db file to somewhere in eclipse explorer (eg:sdcard or PC),and you can use sqlite to access and update this db file .
You can also try copying the file to the SD Card folder, which is a public folder, then you can copy the file to your PC where you can use sqlite to access it.
Here is some code you can use to copy the file from data/data to a public storage folder:
private void copyFile(final Context context) {
try {
File sd = Environment.getExternalStorageDirectory();
File data = Environment.getDataDirectory();
if (sd.canWrite()) {
String currentDBPath =
context.getDatabasePath(DATABASE_NAME).getAbsolutePath();
String backupDBPath = "data.db";
File currentDB = new File(currentDBPath);
File backupDB = new File(sd, backupDBPath);
if (currentDB.exists()) {
FileChannel src = new FileInputStream(currentDB).getChannel();
FileChannel dst = new FileOutputStream(backupDB).getChannel();
dst.transferFrom(src, 0, src.size());
src.close();
dst.close();
}
}
} catch (Exception e) {
e.printStackTrace();
}
}
Manifest:
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.WRITE_INTERNAL_STORAGE" />
<uses-permission android:name="android.permission.READ_INTERNAL_STORAGE" />
SQLlite database is store on user's Phone and it's hidding under path:
/Data/Data/com.companyname.AppName/File/
you have 2 options here:
you can root your phone so that you get access to view your hidding
db3 file
this is not a solution but a work around. Why not just create test
page that display your database table in it using 'select' statment.