I have a doubt, how I can delete a folder on Android 11 (or 10)?
Have much answers here on Stack how to do it, but nothing of worked.
This code worked for me on Android 5:
public static boolean deleteDir(File dir) {
if (dir.isDirectory()) {
String[] children = dir.list();
for (int i=0; i<children.length; i++) {
boolean success = deleteDir(new File(dir, children[i]));
if (!success) {
return false;
}
}
}
// The directory is now empty so delete it
return dir.delete();
}
On newest versions of Android it not work. I noticed that there are applications that can to do this, so I imagine it is possible. Any answer about it?
Android has done much to change its permission models around file access since Android 10 and 11. The preferred approach is to use Scoped Storage APIs.
Many of the old file read/write permissions are on life support and will no longer work. If they do continue to work, then must justify to Google why you need them, and then go through a security approval by Google. You will only be granted approval if you app is classified as a file browser application, or the like.
Basically, the new model is to use Android's file browsers to gain access to read/write/update a particular file that the user selects, and defer the rest of the file management to Google's first-party applications. The access you get is based on what the user selected in the first-party file browser. You are then handed a URI back to your application with the proper permissions to perform the intended action, such as read/write/etc...
You may find this video useful:
https://www.youtube.com/watch?v=RjyYCUW-9tY
Have you tried Context.deleteFile() ?
getApplicationContext().deleteFile(filename);
Related
since Enviroment.getExternalStorageDirectory() is deprecated I have a little Problem. I have 2 applications (a lite and a pro version of an app). These apps have a database which I could export and import. When switching from lite to pro app, the user could import the "old" database into the new app. The database was stored under a folder inside his "sdcard". But now on Android 12 devices we no longer have access to that External Storage.
So how could I solve the problem?
Cause I think, context.getExternalFilesDir((Environment.DIRECTORY_DOCUMENTS)
doesn't work cause the namespace of both apps are different. And I guess it will not work to open a file which is not located under the namespace of the app the file is requested.
Yes, sharing the app's shared memory with another one is not possible.
Other options are using a external server / Firbase to create profile for users and store there data in it.
The easiest way is not to have two apps. Make the single app work for both modes, and gate features at runtime based on the type of license. You can even make the upgrade an in app purchase.
I found a solution by myself, but if someone else is looking for a solution it might be helpful.
I ask the user to specify a file location via
Intent intent = new Intent(Intent.ACTION_CREATE_DOCUMENT);
intent.addCategory(Intent.CATEGORY_OPENABLE);
intent.setType("application/db");
intent.putExtra(Intent.EXTRA_TITLE, "xyz.db");
mCreateNewDatabaseFile.launch(intent);
then in the mCreateNewDatabaseFile
private final ActivityResultLauncher<Intent> mCreateNewDatabaseFile = registerForActivityResult(new ActivityResultContracts.StartActivityForResult(), result -> {
if (result.getResultCode() == RESULT_OK) {
if (result.getData() != null && result.getData().getData() != null) {
Uri path = result.getData().getData();
getContentResolver().takePersistableUriPermission(path, Intent.FLAG_GRANT_WRITE_URI_PERMISSION);
getContentResolver().takePersistableUriPermission(path, Intent.FLAG_GRANT_READ_URI_PERMISSION);
mPreferences.edit().putString(PREF_KEY_DATABASE_EXPORT_PATH, path.toString()).apply();
}
}
});
So even with another process I can read and write the file.
So in the lite Version I can create the db file and in the pro version I can let the user choose this file for import.
I hope it will help others with similar questions.
You can (should) use a ContentProvider to have other apps query your database using accessible methods of your ContentProvider :
you can configure a content provider to allow other applications to
securely access and modify your app data
(this will enforce Single-responsibility principle)
I've been trying to get my app to be able to delete an audio file. However, after trying many possible solutions, I couldn't really find one that works.
Here is my solution so far:
public static void deleteFiles(List<Track> tracks, Context context,
final MutableLiveData<IntentSender> deletionIntentSenderLD){
final Uri AUDIO_URI = MediaStore.Audio.Media.EXTERNAL_CONTENT_URI;
for(Track t : tracks){
try {
context.getContentResolver().delete(ContentUris
.withAppendedId(AUDIO_URI, t.getUriId()), null, null);
}catch (SecurityException securityException) {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {
if (securityException instanceof RecoverableSecurityException) {
deletionIntentSenderLD
.postValue(((RecoverableSecurityException) securityException)
.getUserAction().getActionIntent().getIntentSender());
} else
throw securityException;
} else
throw securityException;
}
}
}
When the try block fails a SecurityException is catch then the IntentSender is passed to the live data that is observed in a fragment:
audioViewModel.getDeletionIntentSenderLD().observe(getViewLifecycleOwner(),
intentSender -> {
try {
startIntentSenderForResult(intentSender, DELETE_PERMISSION_REQUEST,
null, 0 ,0, 0,
null);
} catch (IntentSender.SendIntentException e) {
e.printStackTrace();
}
});
I've tried implementing the onRequestPermissionResult() method but that doesn't do anything. I've also tried deleting the files using File file = new File(), however, due to the changes made to Android 10, I didn't expect it to work.
So after many Google searches, I've come to the conclusion that the best approach (to my knowledge) is to simply turn off scoped storage for Android Q (10).
Here, I'll provide two solutions. The first is the one where I turn it off and the second is the one where scope storage is still enable. However, a thing you should note is that the second solution is a little buggy, at times it actually does delete both the actual media file and updates the Media Store, but most times it simply deletes from the Media Store only. Obviously, this isn't a very good solution as on reboot your application would then load those files back in because the Media Store would scan for them.
Solution 1 - Turn off Scoped Storage
For this solution you can still target Android 11. All you have to do is go to the build.gradle file at the Module Level and set the compileSdkVersion and targetSdkVersion to 30.
After that, you go into the AndroidManifest.xml and have the uses-permission and application tag set up like this:
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>
<uses-permission
android:name="android.permission.WRITE_EXTERNAL_STORAGE"
android:maxSdkVersion="29"
tools:ignore="ScopedStorage"/>
<application
android:requestLegacyExternalStorage="true"
...
After having done that, you could use the Content Resolver to delete the media file (and update the Media Store) and you do not have to worry about catching a security exception like its said in the Android docs. Your implementation for Android 11s delete operation should not be affected.
Solution-ish 2 - Turn on Scoped Storage
Firstly, in your manifest ensure that the WRITE_EXTERNAL_STORAGE permissions maxSdkVersion is set to 28. Also ensure that requestLegacyExternalStorage is set to false (don't think this is required). Then simply copy the code in my original post. You do not require a Live Data if you are doing the delete operation from your activity/fragment. But you should note that startIntentSenderForResult() requires an activity.
But as I mentioned before, I did experience some bugs with this. The most frustrating thing about this solution though is that it does not delete the actual file but instead deletes the entry from the Media Store. Maybe this has something to do with the fact that #blackapps mentioned, which is that you cannot bulk delete and I might have implemented it slightly wrong. Nevertheless, this is horrible for user experience if bulk deletion is impossible in Android 10.
The tutorials I followed for this are:
https://developer.android.com/training/data-storage/shared/media#remove-item
https://www.raywenderlich.com/9577211-scoped-storage-in-android-10-getting-started#toc-anchor-007
https://www.solutionanalysts.com/blog/scoped-storage-in-android-10/
Side Note - Delete on Android 11
To delete on Android 11 you just need to call createDeleteRequest() which should return a PendingIntent. From this PendingIntent you could get the IntentSender by using getIntentSender. Pass this intent sender to the activity/fragment then call startIntentSenderForResult() in your activity/fragment. This pops up a dialog to the user asking them if the application can delete a file. If the user gives permission the system goes ahead and deletes the file and updates the Media Store.
Side Side Note - Scoped Storage, Android 10 and Future
From everything I've seen, it seems to suggest that scoped storage is only enforced in Android 11 but I'm not entirely sure if the legacy option would still be available in Android 10 indefinitely. But I would have to do more research on this...
I have created an application which is working as a launcher. In that application I have opening various other apps. In that app I want to clear all the data(i.e login details, search history) of other application to be removed on click of a button.
PackageManager pm = getPackageManager();
Method[] methods = pm.getClass().getDeclaredMethods();
for (Method m:methods){
if(m.getName().equals("freeStorage")){
try{
long desiredFreeStorage = Long.MAX_VALUE;
m.invoke(pm,desiredFreeStorage,null);
} catch (Exception e) {
e.printStackTrace();
}
break;
}
}
Using the above code, I am able to delete the cache but not able to delete the data of other apps.
Please provide me a solution for that.
Sorry for my bad english.
Its normal behavior. you can't delete data that belongs to other Apps via your app. Files that contain data are private and only accessible by Apps that own them or shared by App.
For example, most of the Apps use SharedPreference as private files to save data for later use. So, its senseless if other Apps are allowed to delete that data.
Using liferay 6.2 api to insert images in document library. The code also moves images from one folder to another folder
But After moving the images their folders do not get guest view permissions and images can't be viewed.
I have two groups (sites) -
GroupA
GroupB
GroupA user creates folders, inserts files and also moves files.
GroupB user should be able to see the files.
All the folders and files are created under Global scope in document library.
public void moveFilesToFolder(final HttpServletRequest request, final List<DLFileEntry> filesToMove, final DLFolder toFolder)
throws Exception {
final ServiceContext sc = ServiceContextFactory.getInstance(request);
sc.setWorkflowAction(WorkflowConstants.STATUS_APPROVED);
sc.setAddGuestPermissions(true);
sc.setAddGroupPermissions(true);
for (final DLFileEntry file : filesToMove) {
DLAppServiceUtil.moveFileEntry(file.getFileEntryId(), toFolder.getFolderId(), sc)
}
// update folders to have guest permissions
DLAppLocalServiceUtil.updateFolder(toFolder.getFolderId(), toFolder.getParentFolderId(), toFolder.getName(),
toFolder.getDescription(), sc);
}
This doesn't seem to work and guest permissions are not set for all the users. The weird behavior is that when the user who performed the move operation looks at the permissions from UI, gues view permission is checked but for any other user the permission is not checked.
As per suggestions below I have used DLAppServiceUtil to move files. But It doesnt change status of file to approved from draft.
Also what is the correct method to use to copy files? There is no method in DLAppServiceUtil to copy files from one folder to another
Anybody knows how to solve this issue?
Using DLAppLocalServiceUtil and DLFileEntryServiceUtil is not the right way. Thery bypass permissions updating and right repository managment.
Use DLAppServiceUtil instead to move and to update.
I would like to ascertain at run-time inside an Android app whether it is running within the BlueStacks Android emulator. This is so I can modify the way the app runs when running inside BlueStacks.
BlueStacks does not support multi-touch so I want to implement an alternative to the standard pinch-to-zoom functionality my current app has.
E.g.
If (appIsRunningInBlueStacks){
mySurfaceView.enableMultiTouchAlternatives();
} else{
mySurfaceView.enableMultiTouchFeatures();
}
What is a reliable way of ascertaining the value of appIsRunningInBlueStacks?
EDIT Summary of answers to comments on question:
Ben, Taras, thanks for the suggestions. The Build.MODEL etc. values for BlueStacks are:
Model: "GT-I9100"
Manufacturer: "samsung"
Device: "GT-I9100"
Product: "GT-I9100"
This is the same model number as the Samsung Galaxy SII so it would not be ideal to use this for fear of treating all users with SIIs the same as those on BlueStacks.
CommonsWare, the app continues to run in BlueStacks even with the < uses-feature> for multitouch in the manifest. In fact (also answering iagreen's question)...
packageManager.hasSystemFeature(PackageManager.FEATURE_TOUCHSCREEN_MULTITOUCH_DISTINCT);
... returns true! This is to be expected I suppose as the emulator is convinced it is a Samsung Galaxy SII!
Therefore we are still without a way of reliably detecting whether an app is running on BlueStacks without also throwing all Samsung Galaxy SII users in the same bucket. Any other ideas?
All the above methods are not working on BlueStacks 5. The correct way to do is checking if the path of /mnt/windows/BstSharedFolder exists. It is working fine on both BlueStacks 4 and 5.
fun checkFilesExist(files: Array<String>): Boolean {
files.forEach {
val file = File(it)
if (file.exists()) {
return true
}
}
return false
}
fun isBlueStacks(): Boolean {
val BLUE_STACKS_FILES = arrayOf(
"/mnt/windows/BstSharedFolder"
)
return checkFilesExist(BLUE_STACKS_FILES)
}
You can check that the Bluestacks shared folder exist
/sdcard/windows/BstSharedFolder
Boolean onBlueStacks()
{
File sharedFolder = new File(Environment
.getExternalStorageDirectory().toString()
+ File.separatorChar
+ "windows"
+ File.separatorChar
+ "BstSharedFolder");
if (sharedFolder.exists())
{
return true;
}
return false;
}
After trying all the suggested solutions available online we found the Google's SafetyNet Attestation API is the only solution for detecting VMs like BlueStack(any version) and NoxPlayer.
Apps that care about content piracy (and other security issues) can filter their availability on the Google Play like Netflix filters devices on the PlayStore.
The new “device catalog” section of the console includes an option
called “SafetyNet exclusion,” which can be used to prevent “devices
that fail integrity tests or those that are uncertified by Google,”
from downloading a specific app: among these would be rooted devices
and those running custom ROMs.
But there is a catch user will still find the APK from cross-sharing or other distribution systems, so the client must implement SafetyNet Attestation API on the app level.
How does it work?
SafetyNet examines software and hardware information on the device
where your app is installed to create a profile of that device. The
service then attempts to find this same profile within a list of
device models that have passed Android compatibility testing. The API
also uses this software and hardware information to help you assess
the basic integrity of the device, as well as the APK information of
the calling app. This attestation helps you to determine whether or
not the particular device has been tampered with or otherwise
modified.
It's an (easy to implement) paid API from the Google which allows 10,000 free hits per day as of now :\
If anyone is interested in detecting VMs by them self, these are the good papers available suggesting heuristic approaches :
Evading Android Runtime Analysis via Sandbox Detection
Rage Against the Virtual Machine:
Hindering Dynamic Analysis of Android Malware
My version of BlueStacks is reporting my Build.Model as GT-N7100.
Using: android.opengl.GLES20.glGetString(android.opengl.GLES20.GL_RENDERER) I get Bluestacks.
It maybe too late but for the sake of others who have the same problem :
public boolean isRunningOnEmulator() {
return Build.FINGERPRINT.startsWith("generic")
|| Build.FINGERPRINT.startsWith("unknown")
|| Build.MODEL.contains("google_sdk")
|| Build.MODEL.contains("Emulator")
|| Build.MODEL.contains("Android SDK built for x86")
|| Build.MANUFACTURER.contains("Genymotion")
|| (Build.BRAND.startsWith("generic") && Build.DEVICE.startsWith("generic"))
|| "google_sdk".equals(Build.PRODUCT)
|| Build.PRODUCT.contains("vbox86p")
|| Build.DEVICE.contains("vbox86p")
|| Build.HARDWARE.contains("vbox86");
}
Based on Mr. Regis' answer, you can detect it when the shared folder is present. However in Bluestacks 4, using file.exists() will only return false. This is because the shared folder has no permissions (000 or ----------). But listing files in the directory will detect the folder.
String path = Environment.getExternalStorageDirectory().toString();
Log.d("FILES", "Path: " + path);
File directory = new File(path);
File[] files = directory.listFiles();
for (File file : files) {
if (file.getName().contains("windows")) {
Log.d("FILES", "windows file exists, it's a bluestacks emu");
}
}
This Will be unique.
There is no bluetooth device in Bluestack.
So try to get The Bluetooth Address string which is always 'null' on Bluestack or Any emulator.Make sure you are adding Bluetooth permission on your project manifest.
BluetoothAdapter m_BluetoothAdapter = BluetoothAdapter.getDefaultAdapter();
String m_bluetoothAdd = m_BluetoothAdapter.getAddress();