Android Studio stores lots of data in the Windows user’s profile directory, i.e. directly in %USERPROFILE% (e.g. c:\users\me), which is wrong in my opinion.
If you use Windows roaming user profiles with folder redirection (which should be the default setting in a company), huge folders like .gradle or .AndroidStudio2.2 are always copied between server and local disk on Windows logon or logoff. You might have to wait 15 – 20 minutes to get your Windows profile fully loaded.
Meanwhile, at least some of the folders went to better locations. E.g. the Android SDK is now under %LOCALAPPDATA% (c:\users\me\appdata\local), which means it will be ignored by the user profile service and not be copied. If you explicitely want it to be copied, move it e.g. to your %APPDATA% folder (could be \\server\profiles\me\appdata). In your project settings file “local.properties” you can modify the SDK directory.
Unfortunately, two huge folders still reside in under %USERPROFILE% by default: .gradle and .AndroidStudioX.X
I recommend to also move these folders to %LOCALAPPDATA%. Then recreate a junction point (mklink) for them:
move %USERPROFILE%\.gradle %LOCALAPPDATA%
move %USERPROFILE%\.AndroidStudio3.4 %LOCALAPPDATA%
move %USERPROFILE%\.android %LOCALAPPDATA%
mklink /j %USERPROFILE%\.gradle %LOCALAPPDATA%\.gradle
mklink /j %USERPROFILE%\.AndroidStudio3.4 %LOCALAPPDATA%\.AndroidStudio3.4
mklink /j %USERPROFILE%\.android %LOCALAPPDATA%\.android
So your huge directories are moved to a non-synced place and Android Studio can still find it in the default location.
If I tried to run mklink without running Command Prompt as an admin, I got a “permission denied” error, so even though my regular user account isn’t an administrator, I had to run Command Prompt as an admin, authenticate using my regular user account (!), and then use the “mklink /d” command. That creates symbolic links to directories, which may be relative to the current directory, e.g.:
cd /d %USERPROFILE%
move .android AppData\Local
mklink /d .android AppData\Local\.android
Note that I vaguely recall tinkering (via GPO or local policy) with the behavior of links on Windows, which may explain why I had to explicitly request symlinkd’s instead of whatever you’re creating (junctions?).
I updated the post. Using the /j parameter, it works for directories and you do not need elevated permissions.