Status Update
No update yet.
Comments
fl...@google.com
kr...@gmail.com
Maybe I have located the problem. It's in the method com.android.ant.AaptExecTask.execute in the file com.android.ant.AaptExecTask.java.
So can I just use a fix as below (add a check for the package name) ?
@Override
public void execute() throws BuildException {
...
// execute it.
task.execute();
// now if the project has libraries, R needs to be created for each libraries
// but only if the project is not a library.
try {
if (!mNonConstantId && libPkgProp != null && !libPkgProp.isEmpty()) {
File rFile = new File(mBinFolder, SdkConstants.FN_RESOURCE_TEXT);
if (rFile.isFile()) {
SymbolLoader symbolValues = new SymbolLoader(rFile);
symbolValues.load();
// we have two props which contains list of items. Both items represent
// 2 data of a single property.
// Don't want to use guava's splitter because it doesn't provide a list of the
// result. but we know the list starts with a ; so strip it.
if (libPkgProp.startsWith(";")) {
libPkgProp = libPkgProp.substring(1).trim();
}
String[] packages = libPkgProp.split(";");
String[] rFiles = libRFileProp.list();
if (packages.length != rFiles.length) {
throw new BuildException(String.format(
"%1$s and %2$s must contain the same number of items.",
mLibraryPackagesRefid, mLibraryRFileRefid));
}
for (int i = 0 ; i < packages.length ; i++) {
File libRFile = new File(rFiles[i]);
if (libRFile.isFile()) {
SymbolLoader symbols = new SymbolLoader(libRFile);
symbols.load();
if (! "the packageName in the AndroidManifest.xml of the current project".equals(packages[i])) { // add a check here before the write so it will prevent the overwrite of the R.java generated at some point before it arrives here
SymbolWriter writer = new SymbolWriter(mRFolder, packages[i],
symbols, symbolValues);
writer.write();
}
}
}
}
}
} catch (IOException e) {
throw new BuildException(e);
}
}
kr...@gmail.com
Is it OK to make that fix? Or will you fix the bug in the next release (e.g. r22)?
go...@stijnvandewater.nl
be...@gmail.com
be...@gmail.com
in hope that someone can pay attention about this.
lo...@gmail.com
be...@gmail.com
By the way, there is another issue pending your fix. It's about the parse for xxhdpi of AndroidManifest.xml. Maybe you have already fix it but not update that issue
ks...@google.com
I'd appreciate it if someone can please tell me, when will this Fix be released? Will this be part of a SDK Revision 22?
Thanks
lo...@gmail.com
This works fine if there are 2+ libraries. If there is a single library and its package is the same as the app this will still fail. I'll fix this for 21.1. The other cases (more than one lib, some or all with the same packages) will go live with 21.0.1 which is due any time now.
be...@gmail.com
As noted above, if you have a single library that shares the app package name, and you build with Ant it will still fails. A workaround is to create a no-op empty 2nd library with the same package name. This will be fixed in the next release.
go...@stijnvandewater.nl
The relation of our projects is like below:
(project type : package name)
app project : app (depends on lib1 and lib2)
lib1 project : lib (depends on lib3)
lib2 project : lib (depends on lib3)
lib3 project : lib (depends on libx)
libx project : libx
During the process of "-code-gen", aapt will generate error messages like...
--------
The following packages have been found to be used by two or more libraries:
lib
No libraries must share the same package, unless all libraries share the same packages.
--------
According to the
Any workaround?
ks...@google.com
libK
libA
libB
libC (depends libA, libB)
libD (depends libC, libK)
libE (depends libD)
App (depends libE)
libK has packagename com.foo.bar, while every other lib and the app has packagename com.fizz.buzz
---
The following packages have been found to be used by two or more libraries:
com.fizz.buzz
No libraries must share the same package, unless all libraries share the same packages.
---
be...@gmail.com
Also got the same issue than #12, any idea for a workaround?
Thanks
Benoît
kr...@gmail.com
I am facing an issue where the R.java file generated for the library in the dependent app is not consistent with the R.java generated in the library itself.
An example:
Library generated com.example.lib.R.java:
package com.example.lib;
public final class R {
...
public static final class id {
public static int eula_accept=0x7f090001;
public static int eula_decline=0x7f090002;
public static int eula_webview=0x7f090000;
public static int mainlayout=0x7f090003;
}
...
}
Where as the com.example.lib.R.java generated in the com.example dependent app is:
package com.example.lib;
public final class R {
...
public static final class id {
public static int mainlayout=0x7f090003;
}
...
}
Three IDs completely missing. This is true for layouts colors, etc. There are resource references not making it. This seems like a bug.
be...@gmail.com
That must be some really intense testing as we are 10 days later and still nothing on sight. I don't want to be a P2 issue if that's what a P1 is.
ga...@chargepoint.com
[Deleted User] <[Deleted User]>
kr...@gmail.com
be...@gmail.com
My bet is that Google still targets API 32 (or even lower) internally so they don't care and didn't even saw the issue before our report.
[Deleted User] <[Deleted User]>
ks...@google.com
This issue is fixed. The fix has been rolled out via GMSCore and will also require using the latest com.google.android.gms:play-services-wearable:18.0.0 release.
Note that you don’t need to add BIND_LISTENER manually, it has been deprecated for a long time and it continue to remain so (read more at
Appreciate all the feedback and patience.
ru...@gmail.com
be...@gmail.com
Hey @com.google.android.gms:play-services-wearable:18.0.0.
After 4 months of testing, it looks like it's broken.
kr...@gmail.com
be...@gmail.com
Well that's possible but I've tested things carefully and targetting API 32 immediately fixes the behavior so I'm confident this is the root cause of the issue
lo...@gmail.com
Can you share the configuration code you have for the affected service from your AndroidManifest.xml file?
be...@gmail.com
lo...@gmail.com
Are you 100% sure that the apk deployed was not an old one with the
old library version for example?
Since there's been some issues with that in past Android Studio versions
and AGP, and since I'm not sure if it's fully fixed and which versions did,
I'd try to run the clean Gradle task, and then run the install task from
command line, and also make sure you're not trying the wrong
buildType/variant.
Please keep us updated.
On Sun, Oct 23, 2022 at 3:56 PM <buganizer-system@google.com> wrote:
be...@gmail.com
I don't think it's that, it was installed from PlayStore so it's a release one built from command line with a version bump
Maybe there was something wrong but all I did between this build and the new one is roll back to targeting API 32 and things worked immediately so it's strange to me.
to...@gmail.com
As a reminder the fix require an update to Play Services on the device too.
be...@gmail.com
Indeed I can see PlayServices aren't updated on my device, like on a lot of Android devices right now auto-update of apps is broken.
I'll try again with up to date services and I'll let you know.
But that means it's far from production ready as we can't expect all of our users to be up to date right now so I'm glad I rollbacked to API 32 for now.
lo...@gmail.com
Which Play Services version is supposed to fix it? We might add a check using PackageManager APIs to direct users to perform the update.
sw...@gmail.com
li...@gmail.com
Have you taken into account the situation of Chinese devices? It's hard for them to upgrade the Play Service and there are no official solutions about this issue.
ol...@gmail.com
ol...@gmail.com
=======
"Status
You won't be able to release app updates (11 days away)
Date sent
Aug 10, 2023
Deadline
Aug 30, 2023
Violation
App must target Android 13 (API level 33) or higher"
[Deleted User] <[Deleted User]>
Issue is not yet solved, as we face the exact same problem still.
- Using
targetSdk=31andcom.google.android.gms:play-services-wearable:18.1.0: OK - Using
targetSdk=33andcom.google.android.gms:play-services-wearable:18.1.0: NOT OK
When using targetSdk 33, messages are no longer sent from the wearable to the phone (e.g. WearableListenerService.onMessageReceived()) is no longer called.
ja...@gmail.com
com.google.android.gms:play-services-wearable:18.1.0
ha...@gmail.com
yf...@gmail.com
You do not have the Arabic language. I am not fluent in English
ch...@gmail.com
da...@gmail.com
1.1.5.2.5.2.5.1.5.4.4.2
Description
Sample app:
Install both the phone and watch app then open the phone app. In the Logcat of the phone app you should see "test" outputted. If the target SDK is set to 32, you will see the message.
Phone Bug Report:
Watch Bug report:
This has been tested on:
Pixel 5
Android 13 Beta 3.
WearOS 2.34
WearOS System Version: H M2