beeware/briefcase

emulator fail: "Error: Package path is not valid"

Closed this issue · 6 comments

shula commented

Describe the bug

briefcase run android fails;

Otherwise the program running flawlessly.
error log attached

Steps to reproduce

I followed the tutorial;
the only error was at: briefcase run android

Expected behavior

emulator showing up. i saw it 2 years ago running from windows.

Screenshots

No response

Environment

  • Operating System: win11
  • Python version: 3.12
  • Software versions:
    • briefcase: 0.3.19
    • Toga: 0.4.5
  • java: "1.8.0_411"

Logs

log is attached as file due to size
briefcase.2024_07_02-22_11_24.run.log

Additional context

I recreated the environment (deleted everything and reinstalled)
I don't know how to read the logs, or =which "Package path" it referes to.

rmartin16 commented

The call to create the AVD for the emulator is failing because it can't find the requested system image. Normally, Briefcase will check if the system image already exists and if not, downloads it. In this case, Briefcase must be finding what it thinks is a system image....but the call to avdmanager.bat to actually create the AVD cannot find the system image.

What exists at the file path below?

C:\Users\user\AppData\Local\BeeWare\briefcase\Cache\tools\android_sdk\system-images\android-31\default\x86_64
shula commented

EDIT: I managed to hack it and make it work,

but i didn't solve the source problem(s). Here's the way i was walking:

The call to create the AVD for the emulator is failing because it can't find the requested system image. Normally, Briefcase will check if the system image already exists and if not, downloads it. In this case, Briefcase must be finding what it thinks is a system image....but the call to avdmanager.bat to actually create the AVD cannot find the system image.

What exists at the file path below?

C:\Users\user\AppData\Local\BeeWare\briefcase\Cache\tools\android_sdk\system-images\android-31\default\x86_64

it's mostly empty, and contains only a metadata file ".installData":

C:\Users\user\AppData\Local\BeeWare\briefcase\Cache\tools\android_sdk> **dir /s/b system-images**

...\system-images\android-31
...\system-images\android-31\default
...\system-images\android-31\default\x86_64
...\system-images\android-31\default\x86_64\.installer
...\system-images\android-31\default\x86_64\.installer\.installData

and that's it.

Then, I tried to run the failing command manually (as indicated in the log) :

set ANDROID_HOME=C:\Users\user\AppData\Local\BeeWare\briefcase\Cache\tools\android_sdk
(beeware) d:\temp\beeware\myapp> **set ANDROID_HOME=C:\Users\user\AppData\Local\BeeWare\briefcase\Cache\tools\android_sdk**
(beeware) d:\temp\beeware\myapp> **set ANDROID_SDK_ROOT=C:\Users\user\AppData\Local\BeeWare\briefcase\Cache\tools\android_sdk**
(beeware) d:\temp\beeware\myapp> **set JAVA_HOME=C:\Users\user\AppData\Local\BeeWare\briefcase\Cache\tools\java17**
(beeware) d:\temp\beeware\myapp> **set XDG_CONFIG_HOME=None**
(beeware) d:\temp\beeware\myapp> C:\Users\user\AppData\Local\BeeWare\briefcase\Cache\tools\android_sdk\cmdline-tools\12.0\bin\**avdmanager.bat --verbose create avd --name beePhone --abi x86_64 --package "system-images;android-31;default;x86_64" --device pixel**
[=======================================] 100% Fetch remote repository...
Error: Package path is not valid. Valid system image paths are:
null

Trying to investigate:

The error message ("Package path is not valid" or "Valid system image paths are") comes from here:
c:\Users\user\.gradle\caches\jars-9\642868d014c84a68e1c8de9a83f5da5f\sdklib-31.2.1.jar

specifically, withing the jar: "...\AvdManagerCli.class". <-- so it's a dead end.

I googled "Error: Package path is not valid. Valid system image paths are:", and got this S.O. page

Which suggested to get it manually.
I ended up running (with the same ENV):

c:\Users\user\AppData\Local\BeeWare\briefcase\Cache\tools\android_sdk\cmdline-tools\12.0\bin\sdkmanager.bat "system-images;android-31;default;x86_64"

It downloaded 4gb of data into C:\Users\user\AppData\Local\BeeWare\briefcase\Cache\tools\android_sdk\system-images as c:\user\[...]\system-images\android-31\default\x86_64\ *

It's a progress :)

I retried to briefcase run android, but got error; briefcase still didn't recognize the system-images.

I re-tried with the same emulator first:

(beeware) d:\temp\beeware\myapp>briefcase run android
Select device:
  1) Create a new Android emulator

> 1

You need to select a name for your new emulator. This is an identifier that [...] a default name 'beePhone'.

Emulator name [beePhone]:
Creating Android emulator beePhone... errored

Unable to create Android emulator

I then tried to create a new emulator, with a different name ("newemu", instead of "beePhone")

And now the logs show a different error; there's a missing file:

FileNotFoundError: [Errno 2] No such file or directory: 'C:\\Users\\user\\.android\\avd\\newemu.avd\\config.ini'
C:\\Users\\user\\.android\\avd\\newemu.avd\\config.ini

But there's no such file - or even the containing directory (C:/Users/user/.android/avd/ -- doesn't exist!)

searching for "config.ini" anywhere --- AHA !

I found it in the wrong place: d:\temp\android-user\avd\newemu.avd\config.ini

  • So I copied d:\temp\android-user\avd --> C:/Users/user/.android/avd

now the emulator works.

I don't know what to conclude my research, regarding BeeWare's process.
I can only detail my steps and findings.

HTH ?

rmartin16 commented

Yesterday, after I posted my original response, I concluded that the system image download must have failed the first time Briefcase tried to create an AVD. But this failure created the file system layout that Briefcase was looking for so in later Briefcase runs, it is concluding that the system image download must have been previously successful and moved on to attempting to create the AVD. However, the system image doesn't exist and AVD creation fails.

In your investigation above, you said running sdkmanager.bat "system-images;android-31;default;x86_64" was able to successfully download the system image. This is the exact same command that Briefcase runs to download the system image.

So, if my conclusions are correct, there is a hole in Briefcase's logic, either:

  1. Briefcase should ensure the system image directory doesn't exist after a failure occurs during download/install
  2. Briefcase should use an Android SDK-provided method to ensure the system image is actually installed

I'm leaning towards number 2; ideally this method would match what avdmanager does to check for a system image.

If you wanted to check, I would be curious if any of the log files created for your project contain the text:

Error while installing the 'system-images;android-31;default;x86_64' Android system image.

If so, that log file would show an attempt was made at one point to download the system image but it failed....and likely resulted in creating the filesystem layout with just the .installData file.

As for the newemu AVD....I don't really understand what's going on there...what is pointing at d:\temp\android-user??

shula commented

  • I erased and recreated my environment, so no logs (i checked anyway, but "Error while installing the" isn't there).

  • As for failure - I totally forgot: The first time I ran "briefcase run android", I had to disconnect the network, and retried 2 days later. So there was a failed partial attempt, indeed.

  • Yes, I am willing to go throught the same process again if that helps:
    I can completely erase beeware from my system, incl. mysterious D:\temp\android-user, .gridle, , .android, and the venv.

I searched now for environment vars containing either D:\TEMP or ANDROID-USER, but i have neither (in or out the venv).

p.s. i'm going to flip to Linux OS next week,
so i experiements needed on Windows, that's better this weekend.

rmartin16 commented

Yes, I am willing to go throught the same process again if that helps:

It would be good to know if the process works for you only using Briefcase. I created #1895 for the system image issue; it'll be good to confirm there aren't other issues lurking that are preventing this working for you.

freakboy3742 commented

I'm going to close this on the basis that #1895 is (as far as we can establish) the underlying issue here, with a more concise description of the problem. Feel free to provide more details if you believe the issue is more than the "failed download" problem described by that new issue.