I am trying to find out the maximum length of both the android:versionName and android:versionCode attributes of the android manifest file?
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.xxxx.xxxx"
android:versionCode="185" <--- THIS ATTRIBUTE
android:versionName="1.0.185"> <--- AND THIS ATTRIBUTE
Is there a maximum value or will it pretty much allow anything if there is no maximum are there certain rules in place?
Based on android documentation:
android:versionCode — An integer value that represents the version of the application code, relative to other versions.
Edit - Android documentation explicitly states -
Warning: The greatest possible value for android:versionCode is MAXINT
(2147483647). However, if you upload an app with this value, your app
can't ever be updated.
Based on oracle documentation:
By default, the int data type is a 32-bit signed two's complement integer, which has a minimum value of -2^31 and a maximum value of (2^31)-1. In Java SE 8 and later, you can use the int data type to represent an unsigned 32-bit integer, which has a minimum value of 0 and a maximum value of (2^32)-1.
android:versionName — A string value that represents the release version of the application code, as it should be shown to users.
Regarding String max length, this SO question may help you.
Update 08/11/2016 (UTC):
The docs has been updated. Not the old MAX_INT value or the 2000000000.
Warning: The greatest value Google Play allows for versionCode is 2100000000.
Cross-post for visibility here.
It seems there was a recent change in Google, making the maximum versionCode up to 2000000000 only.
Reference post: Google Play Developer Console error: The version code of your APK is high and you risk not being able to update your APK
PS: For those who are planning to provide reference to the official documentation where the mentioned max value is 2147483647, please read the answer first in the post I referenced. It mentions that as of current date (08/10/2016), its still not updated.
Let's look at the website.
versionCode is an integer
versionName is a String
android:versionCode — An integer value that represents the version of the application code, relative to other versions.
The value is an integer so that other applications can programmatically evaluate it, for example to check an upgrade or downgrade relationship. You can set the value to any integer you want, however you should make sure that each successive release of your application uses a greater value. The system does not enforce this behavior, but increasing the value with successive releases is normative.
Typically, you would release the first version of your application with versionCode set to 1, then monotonically increase the value with each release, regardless whether the release constitutes a major or minor release. This means that the android:versionCode value does not necessarily have a strong resemblance to the application release version that is visible to the user (see android:versionName, below). Applications and publishing services should not display this version value to users.
So the version code is an integer. It doesn't specify the signage or the number of bits, but we can assume that it can't be negative, and guess 32 bits. So we can guess that it can be between 0 and 2^32. Java by default has signed 32 bit integers, so that would provide values from -2^31 to 2^31. Of course, if it was a 64 bit integer, then it would be between 0 and 2^64.
android:versionName — A string value that represents the release version of the application code, as it should be shown to users.
The value is a string so that you can describe the application version as a .. string, or as any other type of absolute or relative version identifier.
As with android:versionCode, the system does not use this value for any internal purpose, other than to enable applications to display it to users. Publishing services may also extract the android:versionName value for display to users.
This one is a String, so it has no maximum value.
I have an app which version string and code is formatted as yy.mmmm.hhnn, so, now, Jun 28, 19:50 generates the version 20.0728.1950. I never had any problem with this versioning system in both Android and iOS, so versions until 20.9999.9999 are OK.
For Android, the documentation clearly states that the max version code is 2100000000 (21.0000.0000), so PANIK! =)
For my new versions, I'm considering in using this version system: yy.1ddd.hhnn, where ddd is the day of the year (from 1 to 366). Since I cannot use any major version other then 20, my version will be the 1 before the day of year (and I'll be able only to update the app for more 9 years).
So, be careful in your version choosing, otherwise, you won't be able to update the app anymore (at least without changing the app id, but that would be a completely new app and you'll lose everything (reviews, etc.))
Related
My code
paint.setColor(0xFFFFFFFF);
was successfully running before upgrading to Android 10. Now it throws an error:
Wrapped java.lang.IllegalArgumentException: Invalid ID, must be in the
range [0..16)
(Looks like the error message is trimmed)
Nevertheless,
paint.setARGB(255,255,255,255);
works fine.
I've read that starting API 29, setColor also accepts long color values, I tried explicitly putting
paint.setColor(parseInt(0xFFFFFFFF));
or
paint.setColor(valueOf(0xFFFFFFFF));
but none of them worked...
Any solutions in how to use setColor? ARGB doesn't always work for me (e.g. cannot create gradient by specifying ARGB).
You can fix this with a cast:
paint.setColor((int)0xFFFFFFFF);
...although I'm unable to reproduce this behavior on my own machine... 0xFFFFFFFF is always interpreted as an int (even though it's out of range, strictly speaking). Not sure why your compiler is choosing the setColor(long) override.
Maybe you should try this.
paint.setColor(ContextCompat.getColor(YourActivity.this,R.color.colorPrimary));
Parameter value is treated as long number so it cant calculate the color space. There are two different functions, valueOf(int) and valueOf(long). Just cast to int to get working with standard int value.
valueOf(0xFFFFFFFF.toInt())
I wish to check if a user's Java version is at least 1.8.0_171. I mean that specific iteration or higher, meaning 1.8.0_151, for instance, would not work.
I planned to originally use org.apache.commons.lang3.SystemUtils' isJavaVersionAtLeast(JavaVersion requiredVersion) method, but it seems that you cannot specify the iteration number.
Based on this and Java's changing way of representing version numbers in Java (e.g. 1.8 then 9), what is the best way to check the Java version of the user in the Java program?
Edit:
This was marked as a duplicate of this question; however, I think it is different in that it asks how to compare the java version with a certain version given the changes in format of how the java version is shown.
Even with the versioning change, I think the solution is still as simple as using the following boolean expression:
"1.8.0_171".compareTo(System.getProperty("java.version")) <= 0
If the user's java.version property is any less than 1.8.0_171, then the above expression returns false, and vice versa. This works for using "9" or "10" in place of the java.version property as well.
I was under the impression that the UUID spec required a guaranteed, true, globally unique result, not unique 99.99999999999% of the time, but truly 100% of the time. From the spec:
A UUID is 128 bits long, and can guarantee
uniqueness across space and time.
It looks like java only support V3 and V4 of the UUID spec. V4 isn't truly unique. With the V3 implementation using nameUUIDFromBytes, the following results in duplicates, because the computer is too fast (edit: looping to 10 and called new Date().getTime() will produce duplicates because the computer loops faster than new Date().getTime() can produce a different value on each iteration):
String seed;
for (int i = 0; i < 10; i++) {
seed = "<hostname>" + new Date().getTime();
System.out.println(java.util.UUID.nameUUIDFromBytes(seed.getBytes()));
}
Am I mistaken in assuming that a UUID is 100% unique, and that it is only practically unique but not perfectly so? Is there anyway to do this in Java?
There are different methods of UUID generation. The kind you're using is behaving exactly as it should. You're using nameUUIDFromBytes, a "Static factory to retrieve a type 3 (name based) UUID based on the specified byte array."
This generates the same UUID if given the same name. As you've discovered, your loop is passing-in the same name every time, so you get the same UUID.
Have a look at Gabe's advice here: Which UUID version to use?
He recommends you use V4, which as others have pointed out is good enough for any realistic use case.
Because your entropy is limited to your memory, you can never ensure a UUID is "guaranteed, true, globally unique result". However, 99.99999999999% is already pretty good.
If you want to ensure unique values in your database, you could use a simple integer that's incremented to be sure it's unique. If you want to use UUIDs and be really sure they're unique, you just have to check that upon creation. If there's a duplicate, just create another one until it's unique.
Duplicates can happen, but IIRC, part of them is created dependent on your current time, so if you're just creating one every 5 minutes, you should be safe.
As others have pointed out, the type-4 UUID returned by UUID.randomUUID() is likely to be unique enough for any practical application. Cases where it's not are likely to be pathological: for example, rolling back a VM to a live snapshot, without restarting the Java process, so that the random-number generator goes back to an exact prior state.
By contrast, a type-3 or type-5 UUID is only as unique as what you put into it.
A type-1 UUID (time-based) should be very slightly "more" unique, under certain constraints. The Java platform does not include support for generating a type-1 UUID, but I've written code (possibly not published) to call a UUID generating library via JNI. It was 18 lines of C and 11 lines of Java.
The documentation at this page states that
Any value may be set using the corresponding set<Value> method.
However, I am not sure how to interpret this statement. I have tried the following but none of them compile, and nor did I expect them to.
certificate.set3();
certificate.setThree();
serverCertificate.set<3>();
What is the correct method call to set the version number explicitly?
You can not. It explicitely says:
This class represents a X.509 version 3 certificate, as specified by
ISO/IEC and ANSI X9.
Update:
Seems that you can not actually set the version. It "configures" itself the proper version depending on which extensions you use. In V1 there were no extensions and in V2 just few.
The version number per default is set to 1 indicating a Version 1
certificate. When including subjectUniqueID or issuerUniqueID, the
version automatically will be set to 2, and when adding an extension
increased to 3.
Please explain the detailed meaning of VALUE used in the GC option :
-XX:AdaptiveSizeThroughPutPolicy
By default value given is 0.
Does this VALUE imply - the number of steps to use heuristics before real data is used?. What are implications of using a high(eg: 50 or 100) or low value (eg: 0)
The best way I know to understand those arcane options is going directly to the source:
psAdaptiveSizePolicy.cpp
It seems that 1 and !=1 are the only valid choices.
-XX:AdaptiveSizeThroughPutPolicy=1 is used in coordination with -XX:AdaptiveSizePolicyInitializingSteps=VALUE.