Enhancement: AnkiDroid should not use Storage permission (Deadline November 2021)

saleemrashid commented 5 years ago

Reproduction Steps

Start AnkiDroid for the first time
Click "Deny" on the "Allow AnkiDroid to access photos, media and files on your device?" dialog

Expected Result

AnkiDroid should default to a directory that doesn't require WRITE_EXTERNAL_STORAGE. For example, /data/data/com.ichi2.anki/files/ (Context.getFilesDir()) or /sdcard/Android/data/com.ichi2.anki/ (Context.getExternalFilesDirs(null)).

Actual Result

AnkiDroid defaults to /sdcard/AnkiDroid and exits with "AnkiDroid directory is inaccessible".

Research

[x] I have read the support page and am reporting a bug or enhancement request specific to AnkiDroid
[x] I have checked the manual and the FAQ and could not find a solution to my issue
[x] I have searched for similar existing issues here and on the user forum

mikehardy commented 5 years ago

I don't disagree. Please feel free to propose a PR, it must be backwards compatible with existing installs

MonikaJethani commented 5 years ago

@mikehardy Is this done?Or Can I work on this?

mikehardy commented 5 years ago

This is not done - and no one is working on it that I am aware of. I'm unsure of the requirements for acceptance - I mentioned "backwards-compatible with existing installs" but I have not thought through what that means. @timrae was thinking about this before and likely has ideas - Tim do you have any specific thoughts?

And @MonikaJethani I will say that since this affects the app very deeply - it is where people have their beloved collections stored :-) - probably best to post your detailed implementation idea here before starting work, or if you use code to flesh out the idea propose a PR but prepared for the whole approach to be questioned at the idea level until we're sure it will work.

But hopefully that doesn't sound too discouraging, it would be great for AnkiDroid to use the system directory access APIs and not require special permission, and a PR that did that would be great in my opinion

saleemrashid commented 5 years ago

@mikehardy I would implement it thusly:

Add a new preference named along the lines of "Use internal storage". On existing installations, it should be disabled, but on new installations it should default to enabled.
If it is enabled, the "AnkiDroid directory" preference should be disabled and its value overridden with Context.getFilesDir().
If it is disabled, then use the value of "AnkiDroid directory" and prompt for Storage permissions if necessary.

Using the new preference should have the same semantics as changing the "AnkiDroid directory" preference which, as far as I know, just initializes the new directory and doesn't touch the old directory.

In the long run, the "AnkiDroid directory" preference will become obsolete because apps targeting Android Q will not be able to access external storage (they will be given a sandboxed view and must use specific APIs which is a huge privacy improvement).

mikehardy commented 5 years ago

Solid start - interesting, I try to read the preview API changes but haven't had time for Q as of yet.

I have read it now though, and I have a slightly different take on Q's changes though - 2 big things:

With regard to internal vs external - https://developer.android.com/reference/android/content/Context.html#getExternalFilesDir(java.lang.String) will be a viable route to external storage. This is a big deal. You're discussing "internal storage", but note the enhancement is to drop the "Storage permission". They are separate things. I submit we should target dropping the permission and becoming Q-sandbox compliant as a criteria for any PR here, but that's still separate from internal vs external. I do not want to enforce or set a default for internal storage as the collections many people use are large. So external storage should be default, but to meet the drop-permission and Q-sandbox criteria, using Context#getExternalFilesDir() seems best. I support the idea of internal storage as an option (again through the Q-sandbox compliant Context API) but I would not default to internal.

With regard to access on existing /sdcard/AnkiDroid - I quote from your link:

An app that has a sandboxed view always has access to the files that it creates, both 
inside and outside its app-specific directory.

as well as:

File management and media creation apps typically manage groups of files in a 
directory hierarchy. These apps can invoke the ACTION_OPEN_DOCUMENT_TREE intent to 
allow the user to grant access to an entire directory tree. Such an app would be able 
to edit any file in the selected directory, as well as any of its sub-directories.

Using this interface, users can access files from any installed instance of 
DocumentsProvider, which any locally-backed or cloud-based solution can support.

This makes me think that we could continue to access /sdcard/AnkiDroid even after Q, because we know the locations. We'd have to test whether we can just maintain access since we created the files originally or whether we need to obtain permission in Q-sandbox mode With an intent and a conversion to a DocumentsProvider but it should be possible? Not ideal, but "external, legacy mode" does not appear to be forbidden even in the scoped-storage Q-sandbox, just irritating.

So I would propose a slightly different idea -

have a 3-state drop-down for where to store things -- "external, legacy mode" visible in and default only for existing installs that still have data in /sdcard/AnkiDroid. if selected, there is a preference for setting the directory to use, defaults to /sdcard/AnkiDroid. For new installs does not exist -- "external" as default for new installs, option for others, if selected, uses Context#getExernalFilesDir() -- "internal" as option for others, uses Context#getFilesDir()

This would get us to a place where we were able to work in either of the three areas - a big step and functional / usable at this point. But it would just initialize the directory, as you say.

Then - and most important for the future I think - we have code that performs migrations between the locations when the user changes storage location. A dialog indicating what will happen and that it may take a while for large collections, then an AsyncTask doing the work with a modal dialog showing progress (all very very similar to the database check code). Implementation should be just closing the database, calling filesystem moves on the directory, and restarting the activity with an intent that has extra info indicating what we did so we can show a success or fail dialog to the user.

This part is vital or if I understand the scoped-storage Q-sandbox we may have to implement DocumentsProvider access and the DOCUMENT_TREE intent thing just to keep accessing /sdcard/AnkiDroid or we will orphan the data of a 1.3 million active user installed base (!)

Finally, I note this warning on the Q link, which is I think talking about the year 2020 R platform:

Scoped storage will be required in next year's major platform release for all apps, 
independent of target SDK level. Therefore, you should ensure that your app works 
with scoped storage well in advance. To do so, make sure that the behavior is enabled 
on Android Q devices running your app.

So that gives us around a year to get this done and have it rolled out long enough to migrate people, which leads to the final step:

Finally on version upgrades in the startup show dialogs code flow, we start pushing people with a popup explaining the need to migrate, the deadline, and offering the choice to go the migrate preference that does it, so we can move people from external legacy to external and move towards sandboxed Q compliance

What do you think? Not especially different for the first step I think, but a little twist there (prefer external), but the 2nd (migration) and 3rd (popup to push migration) are big differences. ?

timrae commented 5 years ago

Add a new preference named along the lines of "Use internal storage". On existing installations, it should be disabled, but on new installations it should default to enabled.

We used to have a setting for this, which nobody used. We can't make it the default location as many people have collections on the order of hundreds of megabytes. This is not an approach that I would be willing to take.

timrae commented 5 years ago

Ideally I'd like to avoid add a preference for this. We should just migrate to the new APIs as needed. Most likely that means increasing the minimum SDK, so we'll need to discuss the best way to handle that.

timrae commented 5 years ago

From an implementation perspective, I think this issue is the same as #3106. It's not a small job, but if you have the time and patience to see it through to the end then I'd be very happy to start a design discussion.

mikehardy commented 5 years ago

Ideally I'd like to avoid add a preference for this. We should just migrate to the new APIs as needed. Most likely that means increasing the minimum SDK, so we'll need to discuss the best way to handle that.

No preference - fine by me. I can imagine that being very simplifying

As for the API mention, the only necessary API I think is https://developer.android.com/reference/android/content/Context#getExternalFilesDir(java.lang.String) which is API8

If we had to DocumentsProvider for some reason (which we would not, assuming we moved inside of Context#getExternalFilesDir, if I understand correctly), that's API19 / KitKat / 4.4 and represents about 11,000 active users out of about 1,127,000 according to the play store just now. Easily a 2.10 bump and justifiable for 2.9 this moment if it opened things up for this work to proceed cleanly, IMHO

saleemrashid commented 5 years ago

We used to have a setting for this, which nobody used. We can't make it the default location as many people have collections on the order of hundreds of megabytes. This is not an approach that I would be willing to take.

@timrae All devices that AnkiDroid supports should use the same underlying storage for internal storage and external storage. If users are using a microSD card, that is not the same as the path returned by Context#getExternalStorageDirectory. Therefore, there's little to no point in supporting both Context#getFilesDir and Context#getExternalStorageDirectory

timrae commented 5 years ago

As far as I know, that's incorrect. Most devices have a separate partition on the internal SD card with root only permissions, and this is where the applications and application data (Context#getFilesDir) gets stored. This partition is much smaller than the non-root partition, so you can't store large files there.

mikehardy commented 5 years ago

I was thinking the same thing but wanted to back it up with docs or a test and didn't have time - I do believe they have differences though, just wanted proof

saleemrashid commented 5 years ago

@timrae Most devices that ship with Android 4 and above (which is the minimum API level supported by AnkiDroid) use a single partition, and a FUSE filesystem to emulate the SD card.

The only devices that support AnkiDroid and use a separate partition will be devices that shipped with an old version of Android and are running a custom ROM or a few low-end exceptions.

timrae commented 5 years ago

Hmm, I'm away from my computer ATM, but I found someone's df output which seems to agree with what you're saying

https://android.stackexchange.com/a/119072

It seems like a dangerous and unnecessary assumption to make though, since it's entirely up to the manufacturer what limitations they place on the size of the /data virtual partition.

On Sat., 25 May 2019, 5:42 pm Saleem Rashid, notifications@github.com wrote:

@timrae https://github.com/timrae Most devices that ship with Android 4 and above (which is the minimum API level supported by AnkiDroid) use a single partition, and a FUSE filesystem to emulate the SD card.

The only devices that support AnkiDroid and use a separate partition will be devices running a custom ROM or a few low-end exceptions.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ankidroid/Anki-Android/issues/5304?email_source=notifications&email_token=AAVQBYX334LKL2MACWYXEITPXD3XXA5CNFSM4HMI2STKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWHKOAA#issuecomment-495888128, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVQBYU4NONQ5LHUBOIUV5LPXD3XXANCNFSM4HMI2STA .

On Sat., 25 May 2019, 5:42 pm Saleem Rashid, notifications@github.com wrote:

@timrae https://github.com/timrae Most devices that ship with Android 4 and above (which is the minimum API level supported by AnkiDroid) use a single partition, and a FUSE filesystem to emulate the SD card.

The only devices that support AnkiDroid and use a separate partition will be devices running a custom ROM or a few low-end exceptions.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ankidroid/Anki-Android/issues/5304?email_source=notifications&email_token=AAVQBYX334LKL2MACWYXEITPXD3XXA5CNFSM4HMI2STKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWHKOAA#issuecomment-495888128, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVQBYU4NONQ5LHUBOIUV5LPXD3XXANCNFSM4HMI2STA .

Konotorious commented 5 years ago

I'm not so familiar with storage and permission management on Android and so I can't say for sure whether I got it all correctly, but from my understanding my issue (which I was hesitant to open a new thread for) is related to the above.

I have an Android 6.0.1 and the latest Ankidroid app installed. I have an SD card to which I moved the Anki app via the application manager, since it has more storage capacity than my phone's internal storage. However––– all the media (and backups) are still on the internal storage. The application manager shows that AnkiDroid uses 22.88MB of (external) storage, including "364KB of data". My naive understanding therefore is that Android doesn't treat the collection.media as part of the AnkiDroid app, but simply as any other files which AnkiDroid simply happens to manipulate. By itself it would not be a problem, it would even be an advantage, if only it was possible (as the end user) to dictate AnkiDroid the path to the media directory, but I'm not aware that this is possible. As it is now, I have Anki's (indeed a few hundreds of MBs of) media dir stored in an immovable manner, which is a problem given the precious real estate value of the internal phone's storage.

timrae commented 5 years ago

Hi sorry I accidentally pressed the close button. Your assessment that Ankidroid does not treat the flashcard and media databases as part of the app is correct. We do not officially support using external SD cards. However there is a workaround available to get this working if you wish to s do it anyway. Please read the FAQ for more info on this.

github-actions[bot] commented 4 years ago

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

mikehardy commented 4 years ago

I had some recent experience with this where if you use the directories provided as getExternalStorage I think you can actually drop the permission. Problem being that we don't use that directory currently. Either way this is a popular request, I'll leave it open

david-allison commented 3 years ago

Failure to open the app on API 29 without enabling legacy storage in the manifest.

This is high priority, as we have a hard deadline of roughly a year before we need to move to API 30.

2020-10-04 11:59:49.419 7380-7380/com.ichi2.anki I/DeckPicker: User has permissions to access collection
2020-10-04 11:59:49.420 7380-7380/com.ichi2.anki E/CollectionHelper: Could not initialize AnkiDroid directory
    com.ichi2.anki.exception.StorageAccessException: Failed to create AnkiDroid directory /storage/emulated/0/AnkiDroid
        at com.ichi2.anki.CollectionHelper.initializeAnkiDroidDirectory(CollectionHelper.java:197)
        at com.ichi2.anki.CollectionHelper.getCol(CollectionHelper.java:121)
        at com.ichi2.anki.CollectionHelper.getCol(CollectionHelper.java:111)
        at com.ichi2.anki.CollectionHelper.getColSafe(CollectionHelper.java:152)
        at com.ichi2.anki.DeckPicker.firstCollectionOpen(DeckPicker.java:578)
        at com.ichi2.anki.DeckPicker.onCreate(DeckPicker.java:435)
        at android.app.Activity.performCreate(Activity.java:7802)
        at android.app.Activity.performCreate(Activity.java:7791)
        at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1299)
        at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3245)
        at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3409)
        at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:83)
        at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)
        at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2016)
        at android.os.Handler.dispatchMessage(Handler.java:107)
        at android.os.Looper.loop(Looper.java:214)
        at android.app.ActivityThread.main(ActivityThread.java:7356)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)

mikehardy commented 3 years ago

Yep - no argument it's high priority as it's a big change and we need design thinking first which is something we are not well practiced in (though we execute designs quite well...)

Just to note that we do have legacy storage enabled now though so we should have bought ourselves that year of time without crashing I believe?

mikehardy commented 3 years ago

Updated title to reflect the official deadline:

Starting November 2021, all app updates will be required to target API level 30 (Android 11)

arianneorpilla commented 3 years ago

I'm a developer of a third-party application that makes use of AnkiDroid and its card creation API. My app has YouTube features and for this reason I have no reason or incentive to upload my app to the Google Play Store or keep up with its policies.

I was just troubleshooting some issues in regards to storage in general (trying to get my Flutter app to be able to write to an external storage directory where the user could point the AnkiDroid directory to), then I came across this specific issue.

It is my understanding that after this change, AnkiDroid would now default into a scoped storage directory that is inaccessible by my application. I was just wondering if it would be left as an option for the user to use external storage or leave the AnkiDroid directory exposed where I have permissions to write to the media collection? Will the current functionality still work, although non-default behavior? This is highly concerning to me.

If this is not the case, I would like to inquire if there are any alternatives I can use to continue to write to the media collection, i.e. a new AnkiDroid API helper function that will allow me to add files anywhere where the current directory is set.

david-allison commented 3 years ago

Hi, the following change should have added "insert media" to our API. Is this sufficient for your use case?

https://github.com/ankidroid/Anki-Android/pull/6641

arianneorpilla commented 3 years ago

Hi, the following change should have added "insert media" to our API. Is this sufficient for your use case?

6641

What Gradle implementation version am I supposed to use to get that method? I am trying to use 1.1.0alpha6 and 1.1.0 to no avail, I can't seem to compile in order to use addMediaFromUri, the documentation for the API still uses 1.1.0alpha6 and I believe that one is at least a two year old version. Thanks.

dependencies {
    implementation 'com.ichi2.anki:api:1.1.0alpha6'
}

mikehardy commented 3 years ago

:thinking:

According to commit on linked PR https://github.com/ankidroid/Anki-Android/commit/4d2cf42b053065f3eafdff9611d1fe9221a0ecff

it's in api-v1.1.0

Our publishing on the API module is not great, c.f. https://github.com/ankidroid/Anki-Android/issues/7929

However it appears from that issue that if you add jitpack to your maven repo URL list in gradle files, you should be able to resolve the api 1.1.0 coordinates from jitpack and get the artifact ?

https://jitpack.io/com/github/ankidroid/Anki-Android/api-v1.1.0/

arianneorpilla commented 3 years ago

@mikehardy Thanks, this finally allowed me to use the method.

Let me explain what I'm trying to do though, I have a user that wants to be able to export cards from my app which involves adding a note and exporting an audio and video file. They run out of internal storage very easily, and I know other users will be faced with this issue so I deeply care about addressing it.

So, as it stands, I am actually able to use the addMediaFromUri and this works when the directory I use is the default, storage/emulated/0/AnkiDroid, but addMediaFromUri doesn't seem to work for when I set the AnkiDroid directory to storage/emulated/0/Android/data/com.ichi2.anki/AnkiDroid or storage/XXXX-XXXX/Android/data/com.ichi2.anki/AnkiDroid for the SD card directory.

The note is added, which leads me to believe that there isn't a permission issue involved in writing the note to wherever the directory is. But, I am unable to move those files with addMediaFromUri and no files are moved and the card comes up with blank image and audio if I set the directory to storage/emulated/0/Android/data/com.ichi2.anki/AnkiDroid or storage/XXXX-XXXX/Android/data/com.ichi2.anki/AnkiDroid.

This tells me that the addMediaFromUri method doesn't seem to be compatible for use if the directory is anywhere Android/data/com.ichi2.anki, regardless of whether it is in internal or external storage. Is there a workaround I can use to write media files when this enhancement has been implemented? I am greatly concerned about this.

I understand this is third-party stuff I'm doing and that it may be out of scope for the team, so I really appreciate the responses so far.

Now, I have no idea what I'm talking about given that I am just developing for my own app and have no idea how AnkiDroid operates, but if I'm able to pass note information and have the permissions to write to the database in the internal or external storage, then intuitively if file transfers themselves won't work, I believe a method that passes a file's base64 in text to the API for it to rewrite and reproduce the file in the media collection should suffice with the same permissions. Don't know if I'm making any sense though.

mikehardy commented 3 years ago

Accessing storage raw is going away We will be using the apis for android that request external scoped storage for the space scarcity reasons you describe If you pull current dev version of ankidroid now and set a constant for scoped storage in a file (check the pr for scoped storage that just went in) you can check your use case for the future state once it's exposed to users

Should work?

arianneorpilla commented 3 years ago

Would the latest pre-release include that PR? I tried to download it and mimic the behavior shown in the PR by denying storage access but it doesn't seem to work on my Android 10 test device, it just shows a message and then forces you to switch the permission on refusing to move on until it's set.

On the latest pre-release, I can't seem to use the addMediaFromUri function with any success (no media files are successfully moved but cards can be added) if the directory is set to the internal or external scoped directory, or use scoped storage without storage permissions as described in the PR. Do I have to compile from master to test the new functionality? Sorry if I'm being difficult or anything.

arianneorpilla commented 3 years ago

Please ignore my last messages. I have figured out how to properly use the method and have found success exporting to external scoped storage. Might I ask, is it intentional that the exported media filenames end with .null? Kind of esoteric to view the folder with a file manager, but it works. I'm guessing this would also work when synced to desktop?

It seems my trouble was not changing and providing the returned filenames to the card when exporting it, as well as having to move where I put the files before moving them (I placed them in my own scoped storage, but now I put it in my own application's folder in storage/emulated/0/DCIM, I'm guessing I would have trouble with using this on Android 11 devices?)

Thanks for helping me out with the API stuff, I think the documentation could use some changes so I've gone ahead and added those changes to the wiki (I really had trouble with this as the links say implementation 'com.github.ankidroid.Anki-Android:api-v1.1.0' where it should have been implementation 'com.github.ankidroid:Anki-Android:api-v1.1.0' which made me go crazy a bit).

mikehardy commented 3 years ago

is it intentional that the exported media filenames end with .null

This looks like a bug! I'm guessing string concatenation for the file extension with either the extension not provided or an undetectable file type? Is there any combination of API usage arguments that results in a correct extension?

Thanks a bunch for helping with the documentation, to be honest we don't get a lot of feedback from API consumers so we're not sure where the pain points are, we just do our best to keep it working and hope it's working. A back and forth with a real API consumer that's actually integrating it and testing it is valuable

arianneorpilla commented 3 years ago

No, unfortunately. I do export "image" and "audio", I just pass the file URI and my preferred name, not really sure why it acts like that, didn't really take a good look at the API function for it since it ends up working and the media files I export to AnkiDroid are shown just fine.

Here is the commit on my app which made this work, if it happens to be of any interest and of any help on tracking the issue. Just happy to have found something and this thing working in general. Some of my users were excited to hear they could get sentence mining on their external SD cards. Cheers, AnkiDroid team.

Arthus commented 2 years ago

Hello there :)

Is there some kind of overview of outstanding issues/To-Dos in regards to the scoped storage migration? I guess the PR with "NF:" all belong into this category? I there only the one PR #10571 left?

mikehardy commented 2 years ago

Hey @Arthus - I think there is discussion on Discord of the overall plan, @david-allison has it documented somewhere I think? Might be good to keep it as a wiki page - overall design, general remaining task breakdown

There's quite a bit of work left alas. The "make it possible to move files safely" work is I think mostly done, initial user prompts are done I think, but it then needs to be orchestrated into an actual "if user agrees to migrate, start the migration and handle progress notification for user"

Arthur-Milchior commented 2 years ago

Actually, "NF:" means "non-functional", so we usually start commit that makes no change visible to the user with it. Usually cleaning. Sometime speed improvements. The reason is that it's easier to review NF since we only need to check that the code quality is improved, and we don't need to discuss whether the PR improve the user experience.

On discord, this is discussed under #scoped-storage. I fear that since David is really the one dealing with it, the documentation is kind of lacking. While we would be really happy to get help, it is hard to cut this feature into small issues we can give to new contributors as we try to do with many other issues

nzarbayezid commented 2 years ago

for god's sake why is nobody fixing it, the app is unusable if you have over 100MB data cuz of the slow download problem

mikehardy commented 2 years ago

Wow @nzarbayezid, your sense of entitlement is mind-blowing, in comparison to your contributions here. Please examine the massive wall of PRs merged against this issue and kindly be patient or help. Cheers

nzarbayezid commented 2 years ago

@mikehardy I'm sorry I was kinda harsh cuz English is not my native language, and I still don't get it is said that this bug is reported on May 11, 2019, why is it not been fixed? should we wait much longer? cuz my Anki data is 3 gigabytes and I have to be honest it takes a whole day if not two just to sync it with my mobile, it's not usable man

mikehardy commented 2 years ago

@mikehardy I'm sorry I was kinda harsh cuz English is not my native language, and I still don't get it is said that this bug is reported on May 11, 2019, why is it not been fixed? should we wait much longer? cuz my Anki data is 3 gigabytes and I have to be honest it takes a whole day if not two just to sync it with my mobile, it's not usable man

I was looking for the pull requests from you where you fixed it or helped fix it. Couldn't find them that's your answer

nzarbayezid commented 2 years ago

I was looking for the pull requests from you where you fixed it or helped fix it. Couldn't find them that's your answer

if I were a developer I would do that but I'm not a developer, could you please tell me which one of the old versions does not have this bug I want to download them

mikehardy commented 2 years ago

@nzarbayezid none do. It's a policy change by google, and their enforcement of it creates a performance penalty for apps that have no updated to new storage access styles yet. There is a workaround as mentioned in the issue you opened, already linked for you https://github.com/ankidroid/Anki-Android/issues/8925#issuecomment-976337268 - how did it go when you tried it?

nzarbayezid commented 2 years ago

already linked for you #8925 (comment) - how did it go when you tried it?

I tried it and it worked like a charm, but the problem is I would like to keep my Anki data on the SD Card like most of the other apps that I use, do you think the team will be able to fix it in this month?

mikehardy commented 2 years ago

Glad that worked for you. Open Source means there are no real employees so there are no enforceable deadlines. To give one out is to learn disappointment. I'm not sure when the work will be complete, I can only say that it is one of our highest priorities and it is in active development.

nzarbayezid commented 2 years ago

I think this issue is never gonna be solve

mikehardy commented 2 years ago

@nzarbayezid why would you say such a thing? Are you personally working hard on it and it seems intractable? Or have you just lost patience? It's a tough task. But it blocks us completely from releasing new versions. Do you think we would participate in google summer of code, and average 3 PRs merged per day on an app that would essentially die because we could never officially release it again? Please don't be silly. Please be patient.

nzarbayezid commented 2 years ago

@mikehardy I'm just out of patient, it's been 2 month I come to this Issue everyday in hope of seeing it closed, but I think I have to stick to the PC version because the Android version is not usable for me

mikehardy commented 2 years ago

I'm unaware of any reason it's not usable. In fact, you don't even need to wait if you want to use the current version, just hit the releases page https://github.com/ankidroid/Anki-Android/releases - calling it "unusable" is an exaggeration. There is no reason at all you can't just grant storage permission now and get on with the important thing: memorizing stuff. Coming here every day is also quite a bit silly. Just hit the subscribe button up at the top right. In the meantime, the software keeps working just fine.

nzarbayezid commented 2 years ago

The V im using is 2.16alpha58, the newest version does allowing me to sync fast? Cuz im saying unstable because it's so slow that it needs hours for 1Gb to sync, you told me last time that when this issue is closed that means the problem is fixed, and there is no change log with the alphas to see what have been changed and fixed. Please tell me if the problem is fixed in the alpha versions?

mikehardy commented 2 years ago

Ah, I see. You have slow syncing. The thing is, slow sync should only happen until the first sync is completed. Stated differently: once you are in sync once, all future syncs should be fast. If that is not the case something is going on, and even when this is closed that will not fix it. Yes, righ tnow, that first full sync can take multiple attempts, and hours perhaps for 1GB, but it's a one time effort while the media is downloaded. I cannot determine from your comment if you have ever stuck with it (tried multiple times) until all media files were truly in sync, or not.

AndreHero007 commented 1 year ago

Ah, I see. You have slow syncing. The thing is, slow sync should only happen until the first sync is completed. Stated differently: once you are in sync once, all future syncs should be fast. If that is not the case something is going on, and even when this is closed that will not fix it. Yes, righ tnow, that first full sync can take multiple attempts, and hours perhaps for 1GB, but it's a one time effort while the media is downloaded. I cannot determine from your comment if you have ever stuck with it (tried multiple times) until all media files were truly in sync, or not.

Hello, can you tell me if the Alpha Version are better than Play Store version? Do you think I should upgrade to an Alpha version or continue using the Google Play version?

mikehardy commented 1 year ago

@AndreHero007 it depends. Do you want the V3 scheduler? Alpha is the only way. Are you willing to accept some instability that could disrupt your studies and/or create the need to reinstall AnkiDroid, redownload everything? Then the Alpha is a terrible idea. Need some specific new mathjax thing? Alpha is the only way right now. Are not comfortable with reporting app crashes, helping fix problems? Alpha is a terrible idea.

I can't recommend anything to anyone, it depends on use case and person

ankidroid / Anki-Android